What is a Cookie
This page is from WIKIPEDIA. (The links listed may or may not work due to they are linked to WIKIPEDIA. If WIKIPEDIA modifies the page, the links may get broken)
A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is usually a small piece of data sent from a website and stored in a user's web browser while a user is browsing a website. When the user browses the same website in the future, the data stored in the cookie can be retrieved by the website to notify the website of the user's previous activity.[1] Cookies were designed to be a reliable mechanism for websites to remember the state of the website or activity the user had taken in the past. This can include clicking particular buttons, logging in, or a record of which pages were visited by the user even months or years ago.
Although cookies cannot carry viruses, and cannot install malware on the host computer,[2] tracking cookies and especially third-party tracking cookies are commonly used as ways to compile long-term records of individuals' browsing histories — a major privacy concern that prompted European and US law makers to take action in 2011.[3][4]
Other kinds of cookies perform essential functions in the modern Web. Perhaps most importantly, authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in under. Without such a mechanism, the site would not know whether to send a page containing sensitive information, or require the user to authenticate himself by logging in. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website which the cookie belongs to, see cross-site scripting and cross-site request forgery for examples.[5]
The term "cookie" was derived from "magic cookie", which is the packet of data a program receives and sends again unchanged. Magic cookies were already used in computing when computer programmer Lou Montulli had the idea of using them in Web communications in June 1994.[6] At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for a customer. The customer was MCI and the application was the "MCI Mall". Vint Cerf and John Klensin represented MCI in technical discussions with Netscape Communications. Not wanting the MCI Mall servers to have to retain partial transaction states led to MCI's request to Netscape to find a way to store that state in each user's computer. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart.[7][8]
Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on October 13, 1994,[9][10] supported cookies. The first use of cookies (out of the labs) was checking whether visitors to the Netscape website had already visited the site. Montulli applied for a patent for the cookie technology in 1995, and US 5774670was granted in 1998. Support for cookies was integrated in Internet Explorer in version 2, released in October 1995.[11]
The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of the presence of cookies. The general public learned about them after the Financial Times published an article about them on February 12, 1996[citation needed]. In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997.
The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the IETF was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by Brian Behlendorf and David Kristol respectively, but the group, headed by Kristol himself and Aron Afatsuom, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default.
At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000.
A definitive specification for cookies as used in the real world was published as RFC 6265 in April 2011.
Terminology
A user's session cookie[12] (also known as an in-memory cookie or transient cookie) for a website exists in temporary memory only while the user is reading and navigating the website. When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.[13][14]
A persistent cookie[12] will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason persistent cookies are also called tracking cookies.
A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping.
The HttpOnly cookie is supported by most modern browsers.[15][16] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via cross-site scripting (XSS).[17] This feature applies only to session-management cookies, and not other browser cookies.
First-party cookies are cookies set with the same domain (or its subdomain) in your browser's address bar. Third-party cookies are cookies being set with different domains from the one shown on the address bar (i.e. the web pages on that domain may feature content from a third-party domain - e.g. an advertisement run by www.advexample.com showing advert banners). (Privacy setting options in most modern browsers allow you to block third-party tracking cookies).
For example: Suppose a user visits
www.example1.com,
which sets a cookie with the domain
ad.foxytracking.com.
When the user later visits
www.example2.com, another
cookie is set with the domain
ad.foxytracking.com.
Eventually, both of these cookies will be sent to the advertiser
when loading their ads or visiting their website. The advertiser can
then use these cookies to build up a browsing history of the user
across all the websites this advertiser has footprints on.
A "supercookie" is a
cookie with a public suffix domain, like
.com,
.co.uk or
k12.ca.us.[18]
Most browsers, by default, allow first-party
cookies—a cookie with domain to be the same or sub-domain of the
requesting host. For example, a user visiting
www.example.com
can have a cookie set with domain
www.example.com
or .example.com, but
not .co.uk.[19]
A supercookie with domain
.com would be blocked by
browsers; otherwise, a malicious website, like
attacker.com,
could set a supercookie with domain
.com
and potentially disrupt or impersonate legitimate user requests to
example.com.
The
Public Suffix List is a cross-vendor initiative to provide an
accurate list of domain name suffixes changing.[20]
Older versions of browsers may not have the most up-to-date list,
and will therefore be vulnerable to certain supercookies.
The term "supercookies" is sometimes used for tracking technologies that do not rely on HTTP cookies. Two such "supercookie" mechanisms were found on Microsoft websites: cookie syncing that respawned MUID cookies, and ETag cookies.[21] Due to media attention, Microsoft later disabled this code:
In response to recent attention on "supercookies" in the media, we wanted to share more detail on the immediate action we took to address this issue, as well as affirm our commitment to the privacy of our customers. According to researchers, including Jonathan Mayer at Stanford University, "supercookies" are capable of re-creating users' cookies or other identifiers after people deleted regular cookies. Mr. Mayer identified Microsoft as one among others that had this code, and when he brought his findings to our attention we promptly investigated. We determined that the cookie behavior he observed was occurring under certain circumstances as a result of older code that was used only on our own sites, and was already scheduled to be discontinued. We accelerated this process and quickly disabled this code. At no time did this functionality cause Microsoft cookie identifiers or data associated with those identifiers to be shared outside of Microsoft.—Mike Hintze[22]
Some cookies are automatically recreated after a user has deleted them; these are called zombie cookies. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie's absence is detected.
For further information, please visit WIKIPEDIA
Companies use cookies for Behavioral Targeting.