HTTP cookie: Difference between revisions

Revision as of 17:24, 29 May 2011

Revision as of 07:55, 2 June 2011

Line 1:

{{HTTP}}

A '''cookie''', also known as a '''HTTP cookie''', '''web cookie''', or '''browser cookie''', is aused piecefor ofan [[textorigin string|text]]website storedto onsend state information to a [[User (computing)|user]]'s computerbrowser byand theirfor [[webthe browser]] to return the state information to the origin site<ref>{{cite web | url = http://tools.ietf.org/html/rfc6265#section-3 | work=IETF | title= HTTP State Management Mechanism - Overview |date=2011-04}}</ref>. The Astate cookieinformation can be used for [[authentication]], storingidentification siteof a user [[http session|session]], user's preferences, [[Shopping cart software|shopping cart]] contents, the identifier for a server-based [[http session|session]], or anything else that can be accomplished through storing text data.

As text, cookies are not [[executable]]. Because they are not executed, they cannot replicate themselves and are not [[Computer virus|viruses]]. However, they can be used by [[spyware]] to track user's browsing activities - a major privacy concern that prompted stricter laws<ref name=eulaw>{{cite news | url = http://www.bbc.co.uk/news/technology-12668552 | work= BBC | title=New net rules set to make cookies crumble | date=2011-03-08}}</ref>. Cookies could also be stolen by [[Hacker_(computer_security)|hackers]] to gain access to a victim's web account<ref>{{cite web|url= http://news.cnet.com/8301-10789_3-9918582-57.html |first=Robert |last=Vamosi | title=Gmail cookie stolen via Google Spreadsheets |date=2008-04-14}}</ref>.

A cookie consists of one or more [[Attribute-value pair|name-value pairs]] containing bits of information, which may be [[Encryption|encrypted]] for [[information privacy]] and [[data security]] purposes. The cookie is sent as a [[List of HTTP header fields|field in the header]] of the [[Hypertext Transfer Protocol|HTTP response]] by a [[web server]] to a [[web browser]] and then sent back unchanged by the browser each time it accesses that server.

Cookies may be set by the server with or without an expiration date. Cookies without an expiration date exist until the browser terminates, while cookies with an expiration date may be stored by the browser until the expiration date passes. Users may also manually delete cookies in order to save space or to address privacy issues.

As text, cookies are not [[executable]]. Because they are not executed, they cannot replicate themselves and are not [[Computer virus|viruses]]. However, due to the browser mechanism to set and read cookies, they can be used as [[spyware]] (see [[zombie cookie]] and [[evercookie]] for more details). Anti-spyware products may warn users about some cookies because cookies can be used to track computer activity—a privacy concern, later causing possible [[malware]].

Most modern browsers allow users to decide whether to accept cookies, and the time frame to keep them, but rejecting cookies makes some websites unusable.{{Citation needed|date=April 2011}}

== History ==

Line 50 ⟶ 44:

=== Zombie cookie ===

{{main|Zombie cookie}}

A zombie cookie is any cookie that is automatically recreated after a user has deleted it. This is accomplished by a script storing the content of the cookie in some other ___locationlocations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating itthe cookie from the backup stores when the cookie's absence is detected.

== Uses ==

Line 359 ⟶ 353:

=== HTTP authentication ===

The HTTP protocol includes the [[basic access authentication]] and the [[digest access authentication]] protocols, which allow access to a Web page only when the user has provided the correct username and password. If the server requires such credentials for granting access to a web page, the browser requests them from the user and, once obtained, the browser stores and sends them in every subsequent page request. This information can be used to track the user.

=== Adobe Flash Local Shared Objects ===

If a browser includes the [[Adobe Flash|Adobe Flash Player]] [[Plug-in (computing)|plugin]] (formerly developed by [[Macromedia]]), the [[Local Shared Object]]s (“flash cookies”) functionality can be used in a way very similar to cookies. Local Shared Objects may be an attractive choice to web developers because a majority of [[Microsoft Windows|Windows]] users have Flash Player installed, the default size limit is 100 kB, and the security controls are distinct from the user controls for cookies, so Local Stored Objects may be enabled when cookies are not.

In some cases, web sites have created Flash LSOs that behave differently than what a user specifies for his http cookies, which has raised concern that web sites need to specify a consistent privacy policy across different types of cookies.<ref>{{cite web|url=http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1446862 |title=SSRN.com |publisher=Papers.ssrn.com |date= |accessdate=2010-05-22}}</ref>

The major drawback with this approach is the same as every platform/vendor-specific approach: it breaks the web's global [[Web accessibility|accessibility]] and [[Web Interoperability|interoperability]], tying up web development to a specific client's platform, excluding users who use [[Web standards|standards-compliant]] web [[user agent]]s and instead forcing them to use platform/vendor-specific web agents, which perpetuates [[vendor lock-in]].

HTML5, which has many of the same functionalities as Flash and which is gradually being implemented on the web, fixes some of the long-standing problems with the Flash platform by making many aspects of Flash functionality available via standard web interfaces.

=== Client-side persistence ===

Some web browsers support a script-based persistence mechanism that allows the page to store information locally for later retrieval. Internet Explorer, for example, supports persisting information in the browser's history, in favorites, in an XML store, or directly within a Web page saved to disk.<ref>[http://msdn.microsoft.com/en-us/library/ms531066(VS.85).aspx Introduction to Persistence], [[MSDN]]</ref> With [[HTML 5]] there will be a [[DOM storage|DOM Storage (localStorage)]] method, currently supported by only some browsers. For [[Internet Explorer]] 5+ there is a userdata method<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms531424.aspx |title=Microsoft.com |publisher=Msdn.microsoft.com |date= |accessdate=2010-05-22}}</ref> available through ''DHTML Behaviours''.

A different mechanism relies on browsers normally caching (holding in memory instead of reloading) JavaScript programs used in web pages. As an example, a page may contain a link such as <code><nowiki><script type="text/javascript" src="example.js"></nowiki></code>. The first time this page is loaded, the program <code>example.js</code> is loaded as well. At this point, the program remains cached and is not reloaded the second time the page is visited. As a result, if this program contains a statement such as <code>id=3243242</code> (global variable), this identifier remains valid and can be exploited by other JavaScript code the next times the page is loaded, or another page linking the same program is loaded.<!--comment out page not found link<ref>Mukund Sivaraman, [http://www.mukund.org/blog/2006/09/11/clearing-cookies-is-not-enough-to-save-your-privacy/ Clearing cookies is not enough to save your privacy] September 11, 2006</ref>-->{{Citation needed|date=March 2009}} The major drawback of this method is that the global JavaScript variable must be final, meaning that it cannot be changed or deleted persistently like a cookie.

== See also ==