Overheid vraagt internetbranche om input voor cookieverbod

Dat wordt dan mogelijk opgelost met een alternatief:

Alternatives to cookies:

Some of the operations that can be realized using cookies can also be realized using other mechanisms.

IP address:
Users may be tracked based on the IP address of the computer requesting the page. This technique has been available since the introduction of the World Wide Web, as downloading pages requires the server to know the IP address of the computer running the browser or the proxy, if any is used. The server can track this information whether or not cookies are used. However, these addresses are typically less reliable in identifying a user than cookies because computers and proxies may be shared by several users, and the same computer may be assigned different IP addresses in different work sessions (as is often the case for dial-up connections).

Tracking by IP addresses can be reliable in some situations, such as the case of always-on broadband connections which retain the same IP address for long periods of time, so long as the power stays on.

Some systems such as Tor are designed to retain Internet anonymity and make tracking by IP address impractical or impossible.

URL (query string):
A more precise technique is based on embedding information into URLs. The query string part of the URL is the one that is typically used for this purpose, but other parts can be used as well. The Java Servlet and PHP session mechanisms both use this method if cookies are not enabled.

This method consists of the Web server appending query strings to the links of a Web page it holds when sending it to a browser. When the user follows a link, the browser returns the attached query string to the server.

Query strings used in this way and cookies are very similar, both being arbitrary pieces of information chosen by the server and sent back by the browser. However, there are some differences: since a query string is part of a URL, if that URL is later reused, the same attached piece of information is sent to the server. For example, if the preferences of a user are encoded in the query string of a URL and the user sends this URL to another user by e-mail, those preferences will be used for that other user as well.

Moreover, even if the same user accesses the same page two times, there is no guarantee that the same query string is used in both views. For example, if the same user arrives to the same page but coming from a page internal to the site the first time and from an external search engine the second time, the relative query strings are typically different while the cookies would be the same. For more details, see query string.

Other drawbacks of query strings are related to security: storing data that identifies a session in a query string enables or simplifies session fixation attacks, referer logging attacks and other security exploits. Transferring session identifiers as HTTP cookies is more secure.

Hidden form fields:
A form of session tracking, used by ASP.NET, is to use web forms with hidden fields. This technique is very similar to using URL query strings to hold the information and has many of the same advantages and drawbacks; and if the form is handled with the HTTP GET method, the fields actually become part of the URL the browser will send upon form submission. But most forms are handled with HTTP POST, which causes the form information, including the hidden fields, to be appended as extra input that is neither part of the URL, nor of a cookie.

This approach presents two advantages from the point of view of the tracker: first, having the tracking information placed in the HTML source and POST input rather than in the URL means it will not be noticed by the average user; second, the session information is not copied when the user copies the URL (to save the page on disk or send it via email, for example).

window.name:
All current web browsers can store a fairly large amount of data (2-32 MB) via JavaScript using the DOM property window.name. This data can be used instead of session cookies and is also cross-domain. The technique can be coupled with JSON/JavaScript objects to store complex sets of session variables[39] on the client side.

The downside is that every separate window or tab will initially have an empty window.name; in times of tabbed browsing this means that individually opened tabs (initiation by user) will not have a window name. Furthermore window.name can be used for tracking visitors across different web sites, making it of concern for Internet privacy.

In some respects this can be more secure than cookies due to not involving the server, so it is not vulnerable to network cookie sniffing attacks. However if special measures are not taken to protect the data, it is vulnerable to other attacks because the data is available across different web sites opened in the same window or tab.

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 pages request. This information can be used to track the user.

Adobe Flash Local Shared Objects:
If a browser includes the Adobe Flash Player plugin (formerly developed by Macromedia), the Local Shared Objects 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 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.[40]

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


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.[41] With HTML 5 there will be a DOM Storage (localStorage) method, currently supported by only some browsers. For Internet Explorer 5+ there is a userdata method[42] 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 <script type="text/javascript" src="example.js">. The first time this page is loaded, the program example.js 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 id=3243242 (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.[citation needed] The major drawback of this method is that the global JavaScript variable must be static, meaning that it cannot be changed or deleted persistently like a cookie.

[Reactie gewijzigd door pentode op dinsdag 27 april 2010 11:25]