|
A HTTP magic cookie (usually called simply a cookie) is a packet of information sent by a server to a World Wide Web browser and then sent back by the browser each time it accesses that server. Lou Montulli, a former employee of Netscape Communications, was the first to apply the cookie technique in web communications.
Purpose
Cookies can contain any arbitrary information the server chooses and are used to introduce state into otherwise stateless HTTP transactions. Without cookies, each retrieval of a web page (technically, each component of a web page) from a web site is an isolated event, virtually unrelated to all other views of the site's pages. By returning a cookie to a web server, the browser provides the server a means of connecting the current page view with prior page views. Typically this is used to authenticate or identify a registered user of a web site as part of their first login process or initial site registration without requiring them to sign in again every time they access that site. Other uses are maintaining a "shopping basket" of goods selected for purchase during a session at a site, site personalization (presenting different pages to different users), and tracking a particular user's access to a site.
A cookie may be set either by a web server via a CGI script or by a script, such as JavaScript, running in a web browser.
Permission
A browser may or may not allow the use of cookies. The user can usually choose a setting.
Tools > Internet Options > Privacy Tab
- Use slider to set options, or use advanced options
on some though you may have to go to security > custom level > and find cookies
Make sure to block 3rd party cookies without a compact privacy policy.
The best option is to enable P3P:
Open a new browser window and type about:config into the location box.
1) On the line that says "Filter", type "network.cookie.cookieBehavior" and change the value below to "3".
2) Then type "network.cookie.p3p" and change the values to 0 / afafaaaa for low, 1 / ffffaaaa for medium or 2 / frfradaa for high. (medium is suggested in most cases)
See: Firefox Help - Firefox and Cookies
Alternatively, you can use the Privacy options in (Tools > Options > Privacy)
(Note: On Linux this may appear as Edit > Preferences > Privacy, on the Mac as Firefox > Preferences > Privacy)
- Set options under Cookies
- Exceptions allows per site settings of block/allow for session/allow
- View Cookies opens a cookie management window, showing details of stored cookies, allowing them to be deleted or blocked
- If cookies are allowed, they may be restricted to the originating site only
- Accepted cookies may be kept until they expire, or until Firefox is closed.
Cookie settings in iCab can be set globally with the preferences or per-wildcard-URL with its Filter Manager. The information below is a touch long but reflects the power of iCab's configuration.
To view existing cookies and set HTTP-based cookie settings, open the Cookie Manager window: Tools > Cookie Manager
From here, you can view and delete cookies and (under Information for selected cookies) cause them to expire at the end of the session. Click Cookie Preferences to open the Cookie preferences.
- Cookies can be:
- Never accepted
- Prompted for acceptance
- Accepted but not used
- Always accepted
- Always accepted but only kept until the end of the session (i.e. you quit iCab/shut down the computer)
- Cookies not directly from the sites (servers) you are viewing can be rejected (e.g. third-party activity tracking cookies)
- Cookies that will not remain on the machine (which cannot be used to track your activity over time) can be automatically accepted regardless of the general setting
- Invalid and "Illegal" (in computer terms, not criminal law terms) cookies can be automatically rejected
Clicking Edit Cookies brings up the Cookie Manager window.
Those brave enough to face the Filter Manager can configure cookie settings on a per-wildcard-URL basis. JavaScript-generated cookies can also be blocked globally or per-wildcard-URL in the JavaScript preferences; general cookie settings appear to override JavaScript cookie settings.
Safari > Preferences > Security Tab
- Select one of the following options
- Always accept cookies
- Never accept cookies
- Accept cookies only from sites you navigate to (for example, not from advertisers on those sites) Selected by default.
You may also view every cookie that is currently residing in your browser and delete any of them at will.
- Remember to place the dot in front of the domain name .wikipedia.org otherwise wikipedia will not read the cookie (in KDE 3.3) when unlisted cookies are set to be rejected in Settings.
Tools > Preferences > Advanced Tab > Cookies
- Decide when to accept 'normal' cookies (sent by the Web page you are viewing) and 'third party' cookies (sent by other companies, typically advertisers or Web site analytics companies)
- Manage your cookies with the Server Manager, to delete or set preferences for individual servers
Permanence and limits
A cookie often stays on the user's computer for use in the next session (though it can be erased by the user in between), but it can also be for use within a session and be erased at the end of the session.
In Netscape's original specification, certain data limits were suggested, and these limits are often still followed today:
- 300 total cookies for the entire browser
- 4 kilobytes per cookie, (4096 bytes). This included the cookie identifing name as well as the data for that cookie.
- 20 cookies per server or domain. This limit, however, allowed completely specified hosts and domains to be treated as separate entities, ie: en.wikipedia.org and de.wikipedia.org could each have 20 cookies, while wikipedia.org itself could also have 20 cookies.
Some browsers allow much more data to be stored than the above limits.
The cookie setter can either specify a date, (in a "Wdy, DD-Mon-YYYY HH:MM:SS GMT" format), in which case the cookie will be removed on that date or when one of the three mentioned limits is reached. If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser.
Identification
If more than one browser is used on a computer, each has a separate storage area for cookies. Hence cookies do not identify a person, but a combination of a computer and a web browser. Thus, a single person who uses multiple browsers and/or computers will have a distinct set of cookies for each computer/browser combination. On the other hand, cookies do not differentiate between multiple users who share a computer and browser, unless they use different user accounts.
Opposition to cookies
Some people are opposed to the use of cookies on the Web, often because of privacy concerns. Below are some of their reasons.
Inaccurate identification
See the Identification section above.
Privacy, anonymity and advertising
Cookies also have some important implications with respect to a user's privacy and anonymity on the web. One way is that some companies monitor users' visits to disparate web sites for marketing purposes. Some sites contain images called web bugs (that are transparent and only one pixel in size, so that they are not visible) that place cookies on all computers that access them. A single source could have bugs on multiple sites, potentially tracking and correlating a user's activity on across multiple sites, assuming the other sites co-operated by placing the appropriate code into their own site.
Sweden has passed legislation concerning cookies, mandating that sites that use them include a statement to that fact, and includes instructions on how the user can avoid them.
Article 5 Paragraph 3 of the 2002 EU telecommunication privacy Directive requires that users are informed of any cookie and have the right to refuse it. However, the December 2004 report of the EU Commission on the implementation of the directive says on page 38 that this provision is generally not implemented and a thorough analysis of the situation in the Member States is justified.
The Swedish Wikipedia has a page concerning both rules at http://sv.wikipedia.org/wiki/Wikipedia:Cookies
Cookie theft and poisoning by cross-site scripting-based attacks
Even if cookies are not dangerous per se, they contain information corresponding to a particular context: user, computer, web browser, and above all domain served by the web server from where it originated. Bypassing this context, i.e. having this information "leak" out of this context, is undesirable for the user, especially when the cookie data contains personal information. This bypassing in turn represents a valuable undertaking for an attacker. Cross site scripting is the tool of choice to achieve this goal. Among the threats of cross site scripting attacks, cookie theft and cookie poisoning present a risk to the user, in that they enable a transgression of the context and the trust it carries.
- cookie theft: gathering of the user's cookie, sent to the attacker's website. The attacker can then use the cookie information for session hijacking of the user's account on the trusted/affected website.
- cookie poisoning: bypassing the security mechanism of context based trust, the attacker can inject code resulting in a modification of the cookie content, hence making the attack persistent.
Alternatives to Cookies
Due to the limitations and oppositions to cookies above, there are a few possible alternatives.
- The Brownie project [1] is an open source project at SourceForge. Brownies were to be for sharing across multiple domains, as opposed to cookies that are (supposedly) constrained to a single domain. The project is no longer in development.
- P3P is a protocol designed to give users more control of their personal information, such as cookies, when browsing Internet websites.
- Session identifiers are unique query strings appended to URLs that permit the server to match a session with a user without the use of cookies.
References
External links
| 
