To understand the operation of web browser cookies, we must first understand how web browsers work. If you read this page carefully just once, you will understand how insidious tracking on the web has become...

How Web Browsing Works . . .

With that definition in mind, a web browser's “operation model” is simple and straightforward; it is just a series of individual queries and replies:

1. Query: The browser requests an “asset” from a remote server. 2. Reply: If the server has the requested asset, it is returned and provided to the browser.

The key concept is that individual page assets exist separately on remote servers, and each must be requested separately by the web browser.

Since each individual page asset must be separately requested from remote web servers, pages are literally built-up and assembled by requesting, receiving, and accumulating many separate assets onto a single page.

The main "body" of the page is first retrieved from a remote web server: After receiving the page's text, the web browser searches for all references to additional assets contained on the page and sends out a second wave of requests for each of the page's additional assets: The remote web server (or servers) locate and return all of the requested page assets to the requesting browser, thereby completing the page and allowing it to be displayed in finished form:

As depicted in the diagram below, a single web page can request and receive web page assets from more than one server. Since individual web page assets are identified by URL addresses, just like web pages, they can originate from anywhere on the Internet.

As shown in the diagram above, the “first-party server” is addressed by the page's main URL. It provides the web page's main page & body, and usually provides most of the page's other assets. “Third-party servers” are any other servers, located at different web addresses, which pitch-in to provide some of the page's content. Web advertisements are often provided by “third-party ad servers” which inject their advertisements into hosting web pages in the fashion shown above.

• The web page upon which an advertisement will appear reserves a blank space in the page's layout with a URL containing a third-party advertising server address.
• Whenever that page is displayed, the user's web browser will read the page, discover the URL address of the advertising server, and request a web page asset (the advertisement) from it. This could be an image, flash animation, video, or other resource from the third-party server.
• When the advertising asset is received by the browser, it will be inserted into the page to appear in the reserved location and become part of the delivered page.

Another way to express what we summarized above, would be to say that when a web page is displayed it can contain, and usually does, URL references to page assets existing on web servers other than the site we're visiting. To retrieve all of the page's content, our web browser will then — without notifying or asking us in any way — send queries to all referenced “third-party” web servers requesting the required page assets.

As we will now see, what's disturbing about this is the amount of potentially private information that's automatically sent to unknown & untrusted “third-party” organizations located anywhere on the Internet . . .

The following table shows the complete contents of a single query for a single web page asset.

Please don't worry about understanding the details of the material below. (There will not be a test on this.) We just wanted to give you one complete sample of a query so that you could see how much “stuff” a web browser supplies during every query:

A Web Browser's Query to a Web Server

Web browser queries are composed of a series of lines of information, called headers, with each header line containing a “name” and a “value” (known as name-value pairs). Not all queries contain all of the same items. Some may contain additional name-value pairs, some fewer. The example above is typical and you can probably infer much of the intent from the names and values themselves.

Once your eyes have uncrossed from encountering all of the gory details of one complete query, we'll focus upon just the few details that are important for our exploration:

GET	The “GET” header line provides the “target address” of the web asset being requested, and specifies to the web server the highest HTTP protocol level understood by the web browser. In the example shown above, the browser is requesting a graphic image named “browser4.png” located in the “/cookies” directory of the web server, and the browser is declaring that it understands HTTP protocol v1.1.
Host:	The “Host” header specifies the “machine name” to which the query is directed. This is used for at least two purposes: First, multiple web sites can be located (hosted) at a single IP. So when a connection is made to a shared IP, the Host query header must be used to “disambiguate” the query so that it applies to the correct web site sharing a single IP address. The second use for the Hosts header is for domain tagging of any cookies that may also be included with the query. Web browsers store cookies “per domain” and return previously received cookies in subsequent replies when the domain name under which they were received and stored matches the domain specified by the query.
Referer:	The “Referer” header provides the full URL of the referring object. If a query is being made for a web page's image asset, the Referer header will provide the URL of the web page making the request. If a query is a link being clicked by the user, the Referer header provides the URL of the page containing the link. (The "Referer" header was originally misspelled and has remained misspelled ever since.)
Cookie:	The “Cookie” header specifies the cookies the web server wishes to set for the domain specified in the Host header. Multiple cookies can be set, they can have expiration dates, be secured so that they will only be sent over encrypted SSL connections, and have various other properties. The web server can also delete previously set cookies by setting their value to nothing.

With an understanding of the concepts provided above, the “trick” of third-party web browser cookie tracking can be readily understood:

FIRST, a user visits Web Site A containing an advertisement from (third-party) Web Site X ...

As depicted above:

• To display the entire page from Web Site A, which includes content from the third-party web server X, the browser must make a query to web server X to retrieve the required advertisement (or other web page asset of any kind).
• As with any query for an HTTP asset, in asking web server X for the asset specified by web site A, the web browser includes the Referer header to tell web server X which web site and web page contained the reference to web server X. Thus, the "Referer" header creates a major source of web privacy leakage.
• When web server X replies to the browser with the requested advertisement, it also returns one or more cookies with its reply. Unless the web browser has been configured not to work with third-party cookies (all browsers other than Apple's Safari are by default), the browser will store the cookie(s) under web server X's domain name.
• On the side, the third-party (tracking) web server X makes a note in a private database that such-and-such a cookie was given to the browser of someone who was visiting web site A. It knows about web site A from the Referer header that accompanied the request for the advertisement.

From then on, as this user visits any other web sites also containing an advertisement being served by the same (third-party advertising) Web Server X ...

As depicted above:

• As before, to display the entire page from Web Site B, which includes any content from the third-party web server X, the browser must make a query to web server X to retrieve another advertisement (or other page asset of any kind).
• Also as before, as with any query for an HTTP asset, in asking web server X for the asset specified by web site B, the web browser includes the Referer header which informs web server X which web site and web page contained the reference to the requested web page asset. This informs web server X where the user is now browsing.
• BUT! What's different this time is that since this web browser previously received an advertisement from web server X (when it visited web site A), and with that advertisement came a cookie, unless the web browser has been configured not to transact cookies with third-party web sites (as all but Apple's Safari web browser are by default), the browser will return the cookie it previously received from web server X when it makes its request for an advertisement for web site B.
• The third-party web server X, in examining the cookie it has just received along with the request for the advertisement from web site B, looks in its private database and discovers that this is the same cookie that it gave to someone who was previously visiting a page at web site A. The user's web browser received the cookie from web server X while visiting web site A, and it has now sent that same cookie back to web server X when visiting web site B! The two web sites A and B are thus linked by their common display of advertisements being served by the common web server X. And web server X's third-party cookie makes the connection.
• Upon receiving the same cookie from the web browser when visiting web site B, the third-party web server X adds this bit of information to its growing database about this user. At this point it doesn't know who the person is, but thanks to the third-party web server X cookie being carried by that browser, it can track the user's browser around the web, making note of web sites visited, pages are viewed, and for how long. Over time web server X can compile a comprehensive dossier about the web surfing habits of this user who uses this web browser.

The Final Bit of (Very) Disturbing Truth

Up to this point all of the information collected about the user has been anonymous. Using the common third-party cookie, the third-party web server is able to track this anonymous user wherever they go when visiting other sites also hosting advertisements or other third-party assets sourced from the tracking server.

However, a huge economic motivation exists to break this anonymity.

Advertisers would love to know the postal address and zip code of these tracked users since from that they can learn a great deal about the socioeconomic status of the less and less anonymous users being tracked by their database. So here's the really bad news: Thanks to the tracking linkage provided by third-party cookies, it takes only one colluding web site, knowing the names, addresses and other non-anonymous information about its users, to break the anonymity for every site its users visit. Some web sites that establish advertising relationships with their vendors obtain a “kick back” for sharing the real world names, addresses, eMail, and other personal information with their “partners”. And if you read the fine print of the agreement you clicked when you provided that information, you'll see that you inadvertently agreed to this back-channel information sharing.

Your account number often appears somewhere embedded in the URL address of the logged-in pages you visit on a web site. If so, that URL containing your account number in the “Referer” header is sent along with the third-party cookie to the third-party server. Now the third-party server knows your private account number at the referring web site. That colluding web site then only needs to send its third-party advertising “partner” a record containing that account number and all the information they have about you. The third-party server merges all of that information into its ever-growing database.

Or, if a logged-in user's account number doesn't appear in the site's URL addresses, the site can simply add it to the end of the URL requesting the third-party advertisement. This essentially says: “The user with this account is requesting a page with this advertisement.” Since the user's browser will include the third-party cookie with the request, the advertising partner again obtains all the information required to link the account number to the previously anonymous third-party cookie. That cookie is anonymous no longer.

Although the technology of web browsing was never explicitly designed to facilitate this sort of privacy leakage and identity disclosure, neither was it designed with this problem in mind. The original designers of the system were thinking about how functional and cool the technology was  . . . not how that cool functionality could be abused for commercial privacy-invading purposes.

Unfortunately, so much pressure exists to track and profile users across the Internet that the use of third-party cookies is no longer the sole means for accomplishing such tracking. Nevertheless, because it is supported by all browsers and enabled by default for all browsers other than Apple's Safari browser, the use of third-party cookies remains the number one most popular and powerful means of tracking users and the other non-cookie tricks are generally used to “reconstitute” third-party cookies that the browser's user has deliberately deleted in an attempt to prevent Internet tracking and surveillance.

Therefore, the easiest and most immediate thing you can do is to simply configure you web browser to not accept or return cookies offered to it by third-party web servers. The other pages in this region of this web site (see the link block below) will assist you in configuring your browser appropriately.