HTTP cookie

from Wikipedia, the free encyclopedia

A cookie ([ ˈkʊki ]; English "biscuit") is a piece of text information that can be stored in the browser on the viewer's computer for a visited website ( web server , server). The cookie is either sent from the web server to the browser or generated in the browser by a script ( JavaScript ). The web server can read out this cookie information directly from the server when you visit this page again later or transfer the cookie information to the server via a script on the website. These cookies are used, for example, to identify the surfer ( session ID ), to save a login to a web application such as Wikipedia, Facebook, etc. or to save a shopping cart with an online retailer . A frequent use is the web tracking of users with specially prepared pages. In data protection, the term cookie is also used as a synonym for data extraction, data storage, data use, data processing, data transfer and data misuse, regardless of whether a physical cookie is actually used or other techniques are used.

construction

A cookie consists of a name and a value. When defining a cookie, one or more attributes can or must also be specified. 

"Set-Cookie:" Name "=" Wert *( ";" Attribut)
"Cookie:" Name "=" Wert *( ";" Name "=" Wert)

Nameand Wertare sequences of printable US-ASCII characters, excluding some characters. The syntax of Nameuses a restricted character set, as it is also used for other HTTP headers in RFC 2616 . For Wertare semicolon , comma , space characters and backslash excluded. To any data as cookie value to store a code how can Base64 or URL encoding to %xxbe used.

The HttpOnlyattribute is intended to prevent access to cookies using JavaScript. Cookies that have the attribute HttpOnlycannot be accessed via JavaScript. This represents a possible protection against cross-site scripting , provided that the browser used supports this attribute.

specification

According to RFC 6265 , a browser should support the following minimum sizes:

  • A cookie should be able to contain at least 4096 bytes.
  • It should be possible to store at least 50 cookies per domain.
  • A total of at least 3000 cookies should be able to be stored.

The minimum sizes must be guaranteed by all participating browsers and servers. The specification allows larger cookies or a larger number of cookies.

functionality

There are two options for the transmission, assignment and evaluation of cookies by a website:

  1. Transmission in the header (the header ) requests and responses via HTTP . Cookies are created in the client when, when accessing a web server, a line of cookies is also transmitted in addition to other HTTP headers in the server's response (see structure ).
  2. A cookie can also be generated locally using JavaScript or other scripting languages. The script can be found on the website transmitted by the server.

The local cookies from the same domain - i.e. not from other websites  - can be read, used and changed. For example, JavaScript can be used to incorporate information about local user activities that occurred in the session without further server contact. The next time you contact the website, they are also transferred there in the HTTP headers.

Cookie information is stored locally in the browser, usually in a cookie text file . When the web server is subsequently accessed, the client browser searches for all cookies from this domain that match the web server and the directory path of the current call. This cookie data is transferred in the header of the HTTP access so that the cookies can only be sent back to the web server from which they once came.

A cookie can contain any text, so in addition to a pure identification it can also save any settings locally, but its length should not exceed 4 kilobytes (4 · 1024  bytes ) in order to remain compatible with all browsers. The cookies are transmitted with every file transmitted, including image files or any other file type; this applies in particular to embedded elements such as advertising banners that are integrated by servers other than the origin of a displayed HTML file. A single website can lead to multiple cookies that come from different servers and are sent back to them.

Cookies are only managed by the client. In this way, the client decides whether, for example, a cookie is saved or deleted after the service life desired by the web server. However, corresponding information can also be stored on the server, for example to generate statistics on the number of visits to websites.

example

Scenario: A website offers a search function that can remember the search term last entered, even if the user quits the browser in the meantime. This search term cannot be saved on the server, as the server would have to uniquely identify the visitor to do this, and that is not possible with pure HTTP. Therefore, the last search term entered should be saved by the visitor's browser (in a cookie).

When the visitor calls the search function for the first time (here with the search term "cookie structure"), he sends the following request to the server: 

GET /cgi/suche.py?q=cookie+aufbau HTTP/1.0

The server replies with the search result and asks the browser to remember the last search term using the "Set-Cookie" field: 

 HTTP/1.0 200 OK
 Set-Cookie: letzteSuche=Y29va2llIGF1ZmJhdQ==;
             expires=Tue, 29-Mar-2014 19:30:42 GMT;
             Max-Age=2592000;
             Path=/cgi/suche.py

(Usually all the components of the cookie are on a single line. However, for better readability, there is only one attribute per line.)

The cookie has the following components:

  • User data (last search): Since the user data may contain characters that are not permitted (spaces in "cookie structure"), the server returns it here encoded with Base64 .
  • Expiration date (expires): The cookie is only sent in requests made before March 29, 2014.
  • Maximum age (Max-Age): The cookie is only sent for the following 30 days, not later.
  • Part of the website (Path): The cookie is only sent to the search engine ( /cgi/suche.py), as all other parts of the website do not need the information.

Applications

HTTP is a stateless protocol, so the page views are independent of each other for the web server. A web application, the interaction of which with the user continues over several page views, has to work with tricks in order to be able to identify the participant over several visits. For this purpose, a unique session identifier can be stored in a cookie by the server in order to recognize precisely this client when it is called again. For security reasons, electronic banking tends to use a one-time token per page view.

Online shops can use cookies to collect goods in virtual shopping baskets. The customer can use it to put items in the shopping basket and continue browsing the website in order to then buy the items together. The identification of the shopping cart or the user's session is stored in the cookie, and the article IDs are assigned to this shopping cart or the user's session on the web server. This information is only evaluated on the server when the order is placed.

Cookies can be used for intermediate storage so that user actions and inputs intended for the server are not lost in web applications when the connection to the server is interrupted (for example in cellular networks ). When the connection is reestablished, they are queried by the server. The web application recognizes the order in which the cookies were generated and marks cookies that have already been processed or deletes their content. Because many cookies may be generated with this use, which are deleted at the earliest when the browser is closed, but the memory space of the browser for cookies is limited, the web application must take precautions against a cookie overflow .

Security and Hazards

Tracking

The possibility of clear identification can be abused. Cookies are used, among other things, to create user profiles about a user's surfing behavior. For example, an online shop can link this data with the name of the customer and send target group-oriented advertising emails.

However, the online shop can only track surfing behavior within its own website. In order to obtain information about the surfing behavior of its customers, the online shop has to use a third party, a tracking provider. The tracking provider offers the online shop as well as other online shops tracking components that integrate them into their websites. These are scripts, linked scripts or linked components (websites, images, banners, tracking pixels , fonts) that are loaded when the online shops are called up and that generate server requests to the tracking provider, which in turn set cookies with the information received in the browser . These cookies created by third parties are called third-party cookies (English for cookies from third parties). If these cookies are used for tracking, they are also known as " tracking cookies ". The tracking provider registers visits to the online shops connected to it and can therefore assign these visits to individual users. If the tracking provider makes this information available to the online shop, the latter can infer the interests of the visitor and adapt (“personalize”) his online shop accordingly.

There are also reputable third-party services that collect tracking information for technical reasons. Third-party cookies are helpful for successful tracking, but not absolutely necessary. The identity information collected through other identity identification processes, such as fingerprinting , does not require cookies. Even more perfidious, the information to be transmitted is transmitted via parameters with the linked components. However, what all tracking techniques have in common is the integration of tracking components into the website code. Switching off cookies in the browser does not necessarily prevent tracking; other techniques are then used. The most effective protection against tracking is to only access websites that do not use tracking techniques.

It is not uncommon for popular websites to incorporate multiple data collectors. In 2011, a study by the University of Berkeley found 5675 cookies when surfing the TOP100 websites (without logins or orders). Of these, 4914 cookies were set by third parties, i.e. not by the website being accessed. The data was transmitted to more than 600 servers. The front runner among the data collectors is Google. 97% of popular websites use Google cookies.

More and more tracking services are moving to setting cookies in the first-party context, as cookies from third parties can be blocked quite easily.

  • An empirical study by the University of Leuven in 2014 showed that at that time 44 tracking services were able to track more than 40% of surfing behavior, even if you block cookies for third-party sites and only allow first-party cookies.
  • One example is the tracking service WebTrekk, which uses DNS aliases as a subdomain of the monitored website to obtain first-party status on websites such as heise.de, zeit.de or zalando.de in order to set its tracking cookies (2013).
  • Google has been combining the Analytics service with AdWords tracking since 2017. For Google Analytics, the webmaster integrates tracking code directly on the website, which receives first-party status and also sets the cookies for AdWord tracking.
  • Microsofts followed in January 2018 and implemented a solution that sets the cookie with the Microsoft Click ID for conversation tracking in the first-party context. The Microsoft Tracking ID is transmitted as a URL parameter and then written to a cookie using Javascript.
  • Facebook followed the example of Google and Microsoft in autumn 2018 after Mozilla announced that it would make tracking more difficult via third-party cookies in Firefox, based on the Safari model. As with Microsoft, the tracking ID is transmitted in a URL parameter and then written to a first-party cookie using Javascript.

The tracking cookies are also used by the NSA and GCHQ as part of global monitoring. The secret services monitor the data stream on the Internet and identify surfers using long-lived tracking cookies. Target persons are tracked using these cookies and, if necessary, attacked with Foxit Acid if identification is stable for two weeks.

Danger with public internet access

In environments in which several users share the same computer, for example in schools or Internet cafés, there is a risk that a still valid session cookie will be used by the next user of the computer to continue the session of its predecessor. This can be prevented by generally deleting all cookies before closing the browser or by using a corresponding browser setting.

Decision of the Federal Court of Justice

In May 2020, the Süddeutsche Zeitung reported on a decision by the Federal Court of Justice that users must actively give their consent to cookies. This means that many current cookie banners are not permitted in Germany. In their decision, the BGH judges largely followed the argumentation of a ruling by the European Court of Justice (ECJ) from October 2019. This ruled that pre-filled cookie banners were not compatible with European law. So far, many German websites had invoked the German Telemedia Act (TMG) after users had to actively object to cookie tracking.

Security settings in the browser

Common browsers allow the user to more or less define how cookies are to be used, e.g. B .:

  • Do not accept cookies, with the option of creating a whitelist for exceptions.
  • Accept cookies from the server of the accessed page, with the option of creating a blacklist for exceptions.
  • Cookies from third-party servers such as B. for advertising banners:
    • Here you can choose between Always allow , Only allow third-party providers that are visited or Never allow .
  • Ask the user for each cookie:
    • Here you can usually choose between allow (remains), allow for this session (is always accepted, but deleted after closing the browser) and reject (do not accept), whereby the selected option is saved.
  • Keep cookies:
    • Here you can choose between until they are no longer valid or until the browser is closed ("session cookie").

In addition, the browsers allow administrative actions during a session such as:

  • View data in the cookie.
  • Delete individual or all cookies.
  • Change, empty or delete the content of cookies.

The server application can only recognize whether a cookie has been accepted or rejected with further HTTP requests, as the storage of cookies is not reported by the client.

In view of the advantages and disadvantages of cookies, it is advisable to configure your browser in such a way that persistent cookies are not allowed (or only upon request) (which makes the creation of user profiles more difficult) and only session cookies are automatically allowed (e.g. for Web purchases or passwords). Most browsers also offer the option of selectively allowing or blocking cookies for certain domains or automatically deleting them after surfing (as happens automatically with session cookies). Non-server cookies (through which a third party, such as an advertising partner of the website, could record their own behavior across several servers) can be automatically rejected.

Web browsers often offer the option of retrofitting functions using browser extensions . With Firefox, for example, it is possible with a certain extension to click a button to allow websites to save cookies or even to manipulate the content of the cookies yourself. This means that cookies can generally be deactivated and exceptionally allowed if the website does not work properly without cookies or if you want to log into an online service . Other extensions offer a compromise between the browser option of deleting all cookies when exiting the browser or not deleting them by only keeping cookies from certain Internet domains via whitelist , but deleting all others when exiting the web browser. In this way, on the one hand, undesired tracking and, on the other hand, the loss of information that is to be permanently stored can be prevented.

Development history

The concept was originally developed by Netscape Communications and implemented in Netscape Navigator published in 1994 . Netscape published a preliminary specification on their website. In 1995 the IETF began work on a specification that was to be standardized as an RFC . In 1997 the specification was published as RFC 2109 ; it differs in some details from the Netscape specification. The new specification should spread incrementally, as the Netscape Navigator was upwardly compatible with the innovations . When it became known that Internet Explorer's cookie implementation was incompatible with the new specification, work began on a new version. This was published in 2000 as RFC 2965 and uses new HTTP headers such as “Set-Cookie2” to avoid incompatibilities with existing implementations.

While the IETF classified RFC 2109 as "obsolete" (out of date), RFC 2965 was not widely used. Opera also supported "Set-Cookie2" in addition to the old format, but Mozilla Firefox did not. In 2011, RFC 6265 replaced the two previous RFCs. The most common mode of operation was specified in RFC 6265 and “Set-Cookie2” was marked as obsolete. In addition, the "HttpOnly" attribute was specified, which was introduced by Microsoft in Internet Explorer 6 in 2002 and adopted by some web browsers.

Netscape specification cookies

"Set-Cookie:" Name "=" Wert *(";" Attribut)
"Cookie:" Name "=" Wert *(";" Name "=" Wert)

Name=Wertis a sequence of printable US-ASCII characters without semicolons , commas and whitespace characters. If one of these characters is to appear in the name or value, it must be encoded with the URL coding %xx .

The following attributes are defined in the Netscape specification:

EXPIRES=dateValue (optional)
Expiration date of the cookie in the format .Wdy, DD-Mon-YY HH:MM:SS GMT
If no expiry date is given, the cookie will be deleted when the browser is closed.
DOMAIN=domainName (optional)
Domain name to limit the validity of the cookie to a specific domain name. The specified domain name only has to be a suffix of the domain name, i.e. a DOMAIN=example.comspecific cookie is valid for example.comand underlying domains such as foo.example.comor bar.quux.example.com. If this attribute is not specified, the current domain name is used.
PATH=pathName (optional)
Path prefix to limit the validity of the cookie to a specific path or path prefix. If this attribute is not specified, the current path is used.
SECURE (optional)
Cookie may only be sent to the server via a secure connection (i.e. HTTPS).

Cookies according to RFC 2109

The main difference between the specification of RFC 2109 and that of Netscape is that Wertsemicolons, commas and whitespace characters can now also be included, but these must be enclosed in quotation marks. Namebut must no longer $begin with a , as these are used to identify the attributes of cookies in HTTP requests. 

"Set-Cookie:" Name "=" Wert *(";" Attribut)
"Cookie:" "$Version" "=" value 1*((";" | ",") Cookie)

Cookieis a cookie that, in addition to the name-value pair, can also contain the Set-Cookievalue pairs specified in and separated by a semicolon for path and domain :

Name " =" Value [" ;" " Path=" Path ] [" ;" " Domain=" Domain ]

In addition, the Expire attribute has been replaced by the Max Age attribute, which, in contrast to the Expire attribute value, now specifies the validity period in seconds instead of a fixed time. Domain semantics have been expanded. The Comment and Version attributes have been added .

"Comment" "=" value (optional)
Comment on a more detailed description of the cookie
"Domain" "=" value (optional)
Domain or part of the domain name to which the cookie applies. If this attribute is not specified, the current domain name is used. However, if this attribute is specified, the value must begin with a period; if not, the point is added by the client.
"Max-Age" "=" value (optional)
Expiry time in seconds - 0 for immediate deletion. The client can also use the cookie after this time, so the server cannot rely on the cookie being deleted after this expiry time.
"Path" "=" value (optional)
as in Netscape's specification
"Secure" (optional)
as in Netscape's specification
"Version" "=" 1*DIGIT (necessary)
Specifies the cookie management specification in a decimal number (always 1 in this specification)

Cookies according to RFC 2965

Cookies according to RFC 2965 differ from those according to Netscape's specification and according to RFC 2109 in particular in that the header field is called Set-Cookie2instead Set-Cookie. 

"Set-Cookie2:" Name "=" Wert *(";" Attribute)
"Cookie:" "$Version" "=" value 1*((";" | ",") Cookie)

There are also some additional attributes:

"Comment" "=" value (optional)
as in RFC 2109
"CommentURL" "=" <"> http_URL <"> (optional)
URL under which a description of the functionality can be found (specified in RFC 2965 )
"Discard" (optional)
Unconditional deletion of the cookie when the web browser is closed (specified in RFC 2965 , complemented Expires = 0, Max-Age = 0).
"Domain" "=" value (optional)
as in RFC 2109
"Max-Age" "=" value (optional)
as in RFC 2109
"Path" "=" value (optional)
as in Netscape's specification
"Port" [ "=" <"> portlist <"> ] (optional)
Limitation of the port to the currently used or to a list of ports
"Secure" (optional)
as in Netscape's specification
"Version" "=" 1*DIGIT (necessary)
Specifies the cookie management specification in a decimal number (always 1 in this specification)

The following example shows a server response according to RFC 2965 . The server replies with the search result and asks the browser to remember the last search term using the "Set-Cookie2" field: 

 HTTP/1.0 200 OK
 Set-Cookie2: letzteSuche="cookie aufbau";
              Max-Age=2592000;
              Path=/cgi/suche.py;
              Version="1";
              Port = 101;
              CommentURL = "http://example.org/docs/cookies/letzteSuche"

privacy

A cookie can be “set” by application programs or parts or extensions of the operating system of a computer that provide a service, for example when the program is started. This does not normally require the direct consent of the user. The cookies set can later be found and deleted by the user via the browser or the operating system. Security experts recommend that you use cookies carefully. This includes being aware of which cookies a visited page wants to set while surfing . Only very few websites make cookies mandatory (such as the page for logging in to Wikipedia). Most of the time, cookies are set randomly in order to log surfing behavior. Preventing this is annoying, but ensures informational self-determination and data protection . It is not uncommon for a single commercial website to attempt to set a dozen or more cookies. To prevent this, you have to deactivate the automatic acceptance of cookies in the browser settings.

The value of the cookie typically contains a memory address via which the functions of the service can be accessed. Databases of this type are also called cookie jars . Web browsers usually provide a cookie database, which is also called a cookie cache . The web server of a visited website can store information in this database in the form of HTTP cookies and read it out when the website is visited again.

Google cookies and their "PREFID" can clearly identify the browser. In the course of the revelations of Edward Snowden it became known that the NSA was abusing them to place targeted espionage software on individual computers and to monitor them automatically and "exploit them remotely".

Directive 2009/136 / EC, known as the "Cookie Directive", has been in effect since December 19, 2009. This requires the website user's consent to the use of their personal data by the website operator. The EU countries reacted differently to this directive.

The Bundestag dealt with the topic. The SPD's draft law to amend the Telemedia Act (17/8814), which was supported by the opposition, was rejected on October 18, 2012.

In 2012, detailed recommendations by the so-called Article 29 group followed. In 2014, there was still “uncertainty in Germany” about implementation while “in Spain the supervisory authorities are already sending fines”. Despite the confusing legal situation in 2014, specialist lawyers recommend express consent ( opt-in ) in the form of a popup for every user of a website.

In Austria, the directive was implemented in Section 96 (3) of the Telecommunications Act (TKG).

With the General Data Protection Regulation (GDPR), which came into force in May 2018, the so-called e-Privacy Regulation, the draft of which the EU officially presented on January 10, 2017, should also become legally binding. It represents a detailed addition to the GDPR, especially in the area of ​​application of cookies. The draft of the ePrivacy Regulation is currently passing through the European Parliament (as of September 2018) and should become applicable law in May 2019 at the earliest. This would replace the EU cookie directive and create new regulations regarding use.

On October 1, 2019, the European Court of Justice ruled that the setting and retrieval of cookies by websites requires the active consent of the website visitor.

See also

Web links

Individual evidence

  1. ↑ a b Cookies , Karsten Neß, Privacy Handbook, accessed December 24, 2018
  2. ↑ RFC 6265 section 4.1.1 refers to the specification of tokens in RFC 2616 section 2.2.
  3. ^ Carsten Bormann: Panic mode: A Disconnection-tolerant AJAX Library . ( September 28, 2007 memento on the Internet Archive ) O'Reilly Emerging Technology, March 2006
  4. ↑ Websites take out anti-cookie measures , Herbert Braun, heise online , July 31, 2011, accessed December 24, 2018
  5. ↑ The Web Never Forgets: Persistent Tracking Mechanisms in the Wild , Gunes Acar, Christian Eubank, Steven Englehardt, Marc Juarez, Arvind Narayanan, Claudia Diaz, Universität Leuven , 2014, engl. PDF 950 kB, accessed December 24, 2018
  6. ↑ How to: Delete Cookies , test.de from July 17, 2012, accessed on October 24, 2018
  7. ↑ Delete cookies to remove data that websites have on your computer , support.mozilla.org, accessed October 24, 2018
  8. ↑ Mirjam Hauck, Max Muth: The thing with the hook. Süddeutsche Zeitung of May 28, 2020 (accessed on May 29, 2020)
  9. ↑ Firefox add-on cookie button  ( page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / addons.mozilla.org  
  10. ↑ Firefox add-on Cookie Monster  ( page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / addons.mozilla.org  
  11. ↑ Edit Cookies  ( page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / addons.mozilla.org  
  12. ↑ Cookies Manager +  ( page no longer available , search in web archives )  Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / addons.mozilla.org  
  13. ↑ David M. Kristol: " HTTP Cookies: Standards, Privacy, and Politics ", May 9, 2001. arxiv : cs.SE/0105018 .
  14. ↑ bugzilla.mozilla.org
  15. ↑ Overview HttpOnly, history and reference OWASP
  16. ↑ Section 10.1 of RFC 2109 refers to this.
  17. ^ Secret service scandal: NSA spies on Internet users with Google cookies. In: Spiegel Online . December 11, 2013, accessed February 10, 2014 .
  18. ↑ Directive 2009/136 / EC (PDF)
  19. ↑ Cookie Policy in Europe. In: Computerwoche January 11, 2013. Retrieved October 15, 2014 .
  20. ↑ Printed matter German Bundestag 17/5705. (PDF) Retrieved October 12, 2014 .
  21. ^ The resolutions on October 18. In: German Bundestag web and text archive. Retrieved October 14, 2014 .
  22. ↑ http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf
  23. ↑ EU Commission on the Cookie Directive. In: Heise Verlag Newsticker. Retrieved October 14, 2014 .
  24. ↑ Cookies consent and data protection. (No longer available online.) In: Website of the IT law firm. Archived from the original on October 23, 2014 ; accessed on October 14, 2014 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.it-recht-kanzlei.de
  25. ↑ Michael Feike: Court ruling: Opt-in for cookies is mandatory! In: Onlinemarketing.berlin. Retrieved August 3, 2020 .
  26. ↑ Federal Ministry of Economics says cookie policy has been implemented. In: Haufe.de web portal. Retrieved October 14, 2014 .
  27. ↑ The user must first be asked for cookies. The standard of March 5, 2014.
  28. ↑ The implementation of the EU cookie directive in Germany . 1und1.de/digitalguide. April 20, 2018. Retrieved September 12, 2018.
  29. ↑ Cookies? - but only with consent! . rechtslupe.de. October 2, 2019. Retrieved October 2, 2019.