Talk:HTTP cookie/Archive 4
From Wikipedia, the free encyclopedia
 | This is an archive of past discussions about HTTP cookie. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 | Archive 3 | Archive 4 |
Semi-protected edit request on 26 October 2020
 | This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
I want to edit. 96.232.83.69 (talk) 12:26, 26 October 2020 (UTC)
- You can request specific changes here on this talk page on the form "Please change X to Y", citing reliable sources. – Thjarkur (talk) 12:36, 26 October 2020 (UTC)
Semi-protected edit request on 31 January 2021
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
2601:586:500:8800:9C45:87FE:372A:9811 (talk) 02:51, 31 January 2021 (UTC)
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Pupsterlove02 talk • contribs 03:59, 31 January 2021 (UTC)
Semi-protected edit request on 24 March 2021
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
Change "For obvious security reasons" to "For security reasons" in the Domain and path subsection, as the "obvious" is unhelpfully exclusionary Wlycdgr (talk) 16:09, 24 March 2021 (UTC)
Semi-protected edit request on 24 March 2021 (2)
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
Update third party cookie discussion to reflect recent developments: Firefox now blocks third party cookies by default[1], and the Chrome team has announced plans to do so by 2022[2] Wlycdgr (talk) 16:26, 24 March 2021 (UTC)
Already done - these claims already appear in the article. Thank you! A S U K I T E 19:54, 24 March 2021 (UTC)
Semi-protected edit request on 8 June 2021
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
Please remove the sentence "Google Project Zero researcher Jann Horn describes ways cookies can be read by intermediaries, like Wi-Fi hotspot providers. He recommends using the browser in incognito mode in such circumstances". The reason is:
- This doesn't belong in this article at all. It gives un-due focus to an unimportant blog post. That cookies may be stolen is alredy mentioned in the section "Cookie theft and session hijacking", that blog posts does not make a significant contribution over that.
- The source is just a minor demonstration at the author's personal blog. It's hardly a recommendation.
- The recommendation is misleading to readers.
--157.157.113.183 (talk) 10:45, 8 June 2021 (UTC)
Done ScottishFinnishRadish (talk) 11:22, 8 June 2021 (UTC)
terrible cringe taxonomy
tracking cookies are not a thing there are literally infinite ways to track a browser session, cookies being one of them please rewrite the entire article
is there even a reference here to the original cookie spec? this entire article is written for american retards who are paranoid about being tracked and want to learn how precisely a cookie can "violate their privacy", the irony being that the idiots browsing and writing this article are unaware as a method so simple as tracking IP addresses — Preceding unsigned comment added by 198.91.180.20 (talk • contribs) 16:33, 28 September 2021 (UTC)
P3P discontinued by W3C, removed from MS browsers since Windows 10.
| This edit request has been answered. Set the |answered= parameter to no to reactivate your request. |
Please delete the line:
- By default, Internet Explorer allows third-party cookies only if they are accompanied by a P3P "CP" (Compact Policy) field.[60]
and change:
- The P3P specification offers a possibility for a server to state a privacy policy using an HTTP header field, which specifies which kind of information it collects and for which purpose. These policies include (but are not limited to) the use of information gathered using cookies. According to the P3P specification, a browser can accept or reject cookies by comparing the privacy policy with the stored user preferences or ask the user, presenting them the privacy policy as declared by the server. However, the P3P specification was criticized by web developers for its complexity. Some websites do not correctly implement it. For example, Facebook jokingly used "HONK" as its P3P header field for a period.[83] Only Internet Explorer provides adequate support for the specification.
to (updated, and shorter since the unsupported spec is now less relevant, and because the linked page has all the necessary information about the current status of the P3P's demise):
- A W3C specification called P3P was proposed for servers to communicate their privacy policy to browsers, allowing automatic, user-configurable handling. However, few websites implement the specification, no major browsers support it, and the W3C has discontinued work on the specification.
This should bring this page's reporting of P3P current with the P3P page: it's currently several years out of date. 207.191.44.146 (talk) 15:24, 12 October 2021 (UTC)
- Done Parrotapocalypse (hello) 02:26, 15 October 2021 (UTC)
Suggested change to Same-Site cookie section, last paragraph
There have been some changes to browser implementations of SameSite cookies since May 2020 that are not shown in this paragraph.
I suggest this replacement paragraph, most importantly to note that the Chrome rollout was actually completed in 2020.
- As of 2022, Chrome, Firefox, Safari and Edge have all added support for SameSite cookies. An important part of the rollout of this feature is the treatment of existing cookies without the SameSite attribute defined. Chrome began by treating those existing cookies as if SameSite=None, to keep all websites/applications behaving as before. Chrome changed that default to SameSite=Lax in 2020, to increase users' security. The change would break those applications/websites that rely on third-party/cross-site cookies, that were not updated to use the SameSite attribute. Given the extensive changes for web developers and COVID-19 circumstances, Google temporarily rolled back the SameSite cookie change, but completed the rollout later in 2020. . Other browsers have added support at different times.
Also, could we please remove the hyphen, as "SameSite" is the common usage, not "Same-Site". Both forms are used in the original specification, so it's not wrong, but "SameSite" is what the wider web development community typically uses. Bhforbróir (talk) 21:59, 10 January 2023 (UTC)
Semi-protected edit request on 20 July 2023
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
103.171.165.169 (talk) 08:18, 20 July 2023 (UTC)
X500
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Cannolis (talk) 08:46, 20 July 2023 (UTC)
Invention of the tracking cookie in 1995
It's not my place to edit this into the HTTP cookie page, so I'm leaving a note here. My name is Gary Robinson, and I'm the original inventor of the tracking cookie, and the coiner of that term. (The tracking cookie was independently invented a few months later at DoubleClick.) I am the sole inventor listed for patent 5,918,014 with priority date Dec 27, 1995.[1]
The term "tracking cookie" is coined in that patent at column 10, line 9. The technical mechanism is described starting at column 9, line 38.
Google eventually came to own the patent, which has now expired. It also describes mechanisms for privacy and user control of their data. I do already have a wikipedia page,[2] and it seems like the tracking cookie section of the HTTP Cookie page should link to it. But I leave that for other people to decide about and do, if it is judged to be appropriate.
In any case my suggestion is to edit the Tracking part of the Uses section to refer to the patent and to me. I'd do it myself, but my understanding is that it would be inappropriate for me to edit something about me.
[1] https://patentimages.storage.googleapis.com/c3/d4/40/239073914fa7fc/US5918014.pdf
[2] Gary Robinson Garyrob (talk) 14:06, 30 August 2023 (UTC)
Requested move 16 October 2023
- The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
The result of the move request was: not moved. Per consensus, not primary topic. (closed by non-admin page mover) – robertsky (talk) 23:02, 22 October 2023 (UTC)
HTTP cookie → CookiesCookies – First, WP:COMMONNAME. "HTTP cookie" is not a very common name for cookies on the Internet — in fact, I don't think I had heard of them being called that until I found this article. The Google Ngram Viewer shows a dramatic drop in usage after 2005, when it spiked and never recovered. This article is currently buried near the very bottom of Cookie (disambiguation) and took me a while to find because CookiesCookies redirects to Cookie (the food). Per WP:SMALLDETAILS, the plural form should be sufficient to distinguish Internet cookies from edible ones, plus there is clear evidence that Internet cookies are the WP:PRIMARYTOPIC for the term "cookies". HTTP cookie actually dwarfs Cookie in terms of pageviews, but obviously the food is the long-term primary topic for "cookie". For the plural form "cookies", however, this is clearly the one most people are and will be looking for. InfiniteNexus (talk) 00:34, 16 October 2023 (UTC)
- Oppose. The baked good should remain the WP:PRIMARYREDIRECT for "cookies". Rreagan007 (talk) 02:16, 16 October 2023 (UTC)
- Could you please elaborate? Primary redirects are a thing, but WP:PLURALPT permits a plural redirect to redirect to another article if there is a different primary topic for the plural form. For example, Windows vs. Window, Snickers vs. Snicker, Queens vs. Queen, etc. InfiniteNexus (talk) 02:24, 16 October 2023 (UTC)
- "Windows is an operating system", "Snickers is a candy bar", "Queens is a county in New York State": these are all singular nouns. "Cookies are stored on your hard drive": plural. Your analogy is invalid. "Cookie" the unit of stored data, just as "cookie" the baked good, is subject to the same rules regarding singular and plural usage in article titles. And how would it be a valid disambiguation? If we had Cookie and Cookies, how wouldn't anyone know in advance which is about the baked good and which is about the computer topic? Largoplazo (talk) 02:38, 16 October 2023 (UTC)
- Well, let's play a game (no cheating). 1984 and Nineteen Eighty-Four do not point to the same page. Without clicking or hovering on either article, can you tell in advance which is which? InfiniteNexus (talk) 03:05, 16 October 2023 (UTC)
- "Windows is an operating system", "Snickers is a candy bar", "Queens is a county in New York State": these are all singular nouns. "Cookies are stored on your hard drive": plural. Your analogy is invalid. "Cookie" the unit of stored data, just as "cookie" the baked good, is subject to the same rules regarding singular and plural usage in article titles. And how would it be a valid disambiguation? If we had Cookie and Cookies, how wouldn't anyone know in advance which is about the baked good and which is about the computer topic? Largoplazo (talk) 02:38, 16 October 2023 (UTC)
- Could you please elaborate? Primary redirects are a thing, but WP:PLURALPT permits a plural redirect to redirect to another article if there is a different primary topic for the plural form. For example, Windows vs. Window, Snickers vs. Snicker, Queens vs. Queen, etc. InfiniteNexus (talk) 02:24, 16 October 2023 (UTC)
- Oppose. A cookie can be plural too, and is certainly the primary topic for cookies. 162 etc. (talk) 02:27, 16 October 2023 (UTC)
- Commment I agree that the current title could be improved upon. I wonder, though, if a better rename would be something like Cookie (HTTP) or Cookie (internet). I'm not necessarily in support of the positions of @Rreagan007 or @162 etc. but the distinction between Cookie and Cookies is not so clear, so people will have to look at the short description to figure out what they want.Oblivy (talk) 02:39, 16 October 2023 (UTC)
- Oppose How is the HTTP cookie (or web cookie) the primary topic for "cookie"? And there is no rhyme or reason to assigning singular to the baked good and plural to the unit of web storage. The baked good is a cookie. The unit of storage is a cookie. Both can be pluralized. Both can be considered individually.The only thing the Ngram tells you is that "HTTP cookie(s)" fell in usage by about 50% between 2005 and 2013 (and has risen since then) as a proportion out of all of the literature in those years. It tells us nothing about its frequency relative to references to the baked good at any given time. Largoplazo (talk) 02:47, 16 October 2023 (UTC)
- (edit conflict) Because cookies on the Internet are rarely referred to in singular form. "This website uses cookies." "Accept all cookies." "Clear cookies." "Block third-party cookies." InfiniteNexus (talk) 02:52, 16 October 2023 (UTC)
- Oppose move. The primary topic for "cookies", plural, is obviously the baked goods. O.N.R. (talk) 03:45, 16 October 2023 (UTC)
- Oppose. Not only is the block of data not the primary meaning of "cookies", but I see no evidence that people only identify such blocks using the plural form. A quick glance at Google shows that reliable sources often say things like, "a cookie is information that a website puts on a user's computer", or "the most common use of a cookie is to store a user ID", or similar singular constructions. ╠╣uw [talk] 10:50, 16 October 2023 (UTC)
- Oppose not primary for the plural form and may not pass WP:PLURAL anyway but I'm not sure. Crouch, Swale (talk) 18:47, 16 October 2023 (UTC)
- Oppose. Per everything above, but also, Cookie ([[Cookie]]) and Cookies ([[Cookie]]s) will both lead to the same page, but if this page moves as proposed, Cookies ([[Cookie]]s) and Cookies ([[Cookies]]) won't and that is just bad user experience (and tools such as AWB will obviously not be able to handle it). Gonnym (talk) 19:04, 16 October 2023 (UTC)
- Oppose this move. I agree that "HTTP cookie" is perhaps a rare term that this sort of natural disambiguation isn't best, perhaps, and something like "Cookie (web)" or "Cookie (Internet)" could be better. I also think that the disambiguation page should have both cookie and HTTP cookie linked from the top of the page in some style, which is done when there are two topics much more common than others (which is true in this case). I may try to do that sometime when I can think exactly how if no one else beats me to it. Skynxnex (talk) 19:43, 17 October 2023 (UTC)
- As I indicated above, I agree with @InfiniteNexus the current title is not great.
- Cookie (Internet) would be fine. I suggested Cookie (HTTP). Cookie (Web) is as good or better.
- Since this RFC seems doomed to fail as 100% - nominator oppose, should this be opened as a new RFC to see if a different change is going to be acceptable? If not, what's the next move? Oblivy (talk) 02:38, 18 October 2023 (UTC)
- Let it... Randy Kryn (talk) 03:35, 18 October 2023 (UTC)
RFC - move to Cookie (Internet)
A previous RFC to move to "cookies" failed (as IMHO it should have, for reasons given above). However, there was some support to change to Cookie (Internet) or similar and I don't think that got serious consideration.
The term "cookie" is deeply embedded in modern parlance, in a way that HTTP Cookie is not, and this would aid searchers without creating confusion about the baked good.
I'd be OK with Cookie (HTTP) or Cookie (Web) as well. Oblivy (talk) 02:04, 12 April 2024 (UTC)
- I've given this nearly a week and no comments. Unless someone raises their hand to object I'll do the page move shortly. Oblivy (talk) 02:59, 18 April 2024 (UTC)
- That wasn't an RFC, it was a move request, and you ought to post a formal move request too. (FYI, this isn't an RFC either: submitting an RFC involves more than including the letters "RFC" in the title of a discussion.) See the procedure at WP:Requested moves. Largoplazo (talk) 09:37, 18 April 2024 (UTC)
Semi-protected edit request on 21 May 2024
- REDIRECT Target page name
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
176.54.176.219 (talk) 11:15, 21 May 2024 (UTC)
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Charliehdb (talk) 11:33, 21 May 2024 (UTC)
Semi-protected edit request on 18 June 2024
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
41.155.4.4 (talk) 15:29, 18 June 2024 (UTC)
Allow cookies
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Annh07 (talk) 15:33, 18 June 2024 (UTC)
Semi-protected edit request on 15 August 2024
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
The information about supercookies is partially incorrect. Supercookies are not exactly cookies with an origin of a TLD or public suffix. They are more accurately described as tracking mechanisms that can be stored in various ways, such as in HTTP headers, flash cookies, or even in more obscure locations like ETags, rather than being restricted to standard HTTP cookies. The security concern with supercookies mostly lies in their ability to persist across different domains or be more difficult to delete, rather than their ability to maliciously alter requests. This can lead to tracking users across different websites without their knowledge.
I'd propose that the article about Evercookies (the most popular implementation of supercookies) is linked, rather than explaining the concept here again. If a specific explanation is needed here, i'd propose something along the lines of the following: A supercookie is a tracking mechanism that can persist across different domains or even remain stored in non-traditional locations like HTTP headers or browser cache, making it harder to delete compared to ordinary cookies. Unlike regular cookies that are associated with a specific domain (e.g., example.com), supercookies can potentially track users across multiple sites and evade traditional cookie management practices.
Supercookies pose significant privacy and security concerns. For instance, an attacker could potentially exploit a supercookie to track users across multiple websites or reconstruct deleted cookies, thus undermining user privacy. Web browsers and privacy tools typically implement measures to block or delete supercookies, but some older versions or improperly configured browsers may still be vulnerable.
The Public Suffix List helps mitigate some of the risks associated with domain-level cookies by ensuring that cookies cannot be set at inappropriate domain levels, such as top-level domains or public suffixes (e.g., .co.uk). However, the risk posed by supercookies often extends beyond what the PSL can prevent, involving more advanced tracking techniques that require more comprehensive privacy protections. KleinKalve (talk) 09:53, 15 August 2024 (UTC)
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. M.Bitton (talk) 00:15, 17 August 2024 (UTC)
"Created by a web server" in the first paragraph may not always be correct
Current first paragraph: "HTTP cookie [...] is a small block of data created by a web server while a user is browsing a website [...]"
Problem: "created by a web server" may not always be correct and could potentially be misleading, especially if it's in the first paragraph.
As mentioned later down in the article: "Although cookies are usually set by the web server, they can also be set by the client using a scripting language such as JavaScript".
That is, it may be more correct to say something along the lines of "usually created by a web server or browser-side script" ("usually", since we could in theory consider cases like manually adding a cookie to browser's SQLite database, or curl's cookies.txt file, etc.). UkuSormus (talk) 05:38, 10 April 2025 (UTC)
"user's web browser" v.s. other types of client
Current first paragraph: "HTTP cookie [...] is a small block of data [...] placed on the user's computer or other device by the user's web browser [...]"
The current wording explicitly uses "user's web browser".
Should we consider non-browser clients such as curl to be mentioned in the article? (see, e.g., curl - HTTP cookies)
If so, should we also consider modifying the first paragraph to use something like "by the client, usually the user's web browser", or it could get too abstract for the intro? UkuSormus (talk) 05:40, 10 April 2025 (UTC)
New browser-side CookieStore API
In the current version of the article, only the document.cookie browser API is mentioned for manipulating cookies. Nowadays, there's also the new CookieStore API (see MDN), supported by Chromium-based browsers and soon in Firefox. UkuSormus (talk) 05:41, 10 April 2025 (UTC)
"Alternatives to cookies" should be split out into a separate article
The section "Alternatives to cookies" list various identifiers and cache records stored by the client (and metadata like IP). These things can be used for tracking (one application of cookies), but they don't actually substitute cookies in general. Also, this list is missing a few entries, like:
- - favicon cache:
- - HSTS tracking, see
- - redirect tracking, see
Also see: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Redirect_tracking_protection#what_data_is_cleared — Preceding unsigned comment added by Anton.bersh (talk • contribs) 21:06, 8 March 2021 (UTC)
Semi-protected edit request on 3 April 2025
| This edit request to HTTP cookie has been answered. Set the |answered= parameter to no to reactivate your request. |
In the Browser fingerprint paragraph, it would be nice to specify that "While the collection of fingerprinting data occurs client-side, the analysis and identification of users based on this data are performed server-side." Please, see the resource here: https://www.researchgate.net/publication/365268626_A_Survey_of_Browser_Fingerprint_Research_and_Application
Also, according to Wikipedia's Guidelines, an example could be done. Here is my attempy: "A well-known application of browser fingerprinting is in online banking systems. This technology enables the creation of unique identifiers for customers' devices during the login phase to detect suspicious activities, such as attempts to access accounts from unrecognized or potentially fraudulent devices."
Thanks! Ate Keurentjes (talk) 08:41, 3 April 2025 (UTC)
Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details. twisted. (user | talk | contribs) 14:37, 14 April 2025 (UTC)
