NgSysV2-5.4: Browser Cookies

This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.

Last reviewed: February 2026

1. Introduction

Most times you open a new webapp, these days, you are greeted by an annoying pop-up that tells you "this site uses cookies" and asks what you want done with them. Here's an example

This is GDPR, the EU's "General Data Protection Regulation" in action. Although it is likely that less than one in a hundred of us have the faintest idea of why a cookie might be, or care, particularly, you won't be permitted to enter the app until you submit to this interrogation.

This post attempts to clarify the situation by explaining:

• what a browser cookie is
• where you can see them
• what their purpose is
• how they may pose a danger to you
• how GDPR and other standard bodies are working to minimise your risk
• how you may assist their work by taking commonsense precautions yourself

In the process, the post will also attempt to untangle the vicious knot of terminology that infests the subject:

• first-party cookies
• third-party cookies
• third-party identity cookies

Sounds like fun? This post certainly lays bare some of the web's grubbier secrets

2. Cookie Basics - First-party Cookies

A cookie is a packet of information held in the user's browser storage. To view cookies for a website in a browser such as Google Chrome, right-click anywhere on the page, select Inspect to open Developer Tools, click the Application tab, and expand the Cookies section in the left sidebar. You'll now see a table listing the cookies associated with your website's domain. The graphic below shows the cookies that have been created by the "dev.to" website to help me write this post:

The most basic form of cookie provides a way of enabling persistent website behaviour between sessions - for example, you might use a cookie to let the user set the font size of a page (ctrl +/ctrl - shortcut keys in most browsers) for both this and future visits. These are called first-party cookies because they are available only to pages on the website that set them.

Setting a basic (first-party) cookie:

Here's some JavaScript that you might use:

document.cookie = "font-size=" + fontSize

This creates a cookie called font-size with the value of the fontSize variable. In passing, you might like to know that the document.cookie method also allows you to set attributes of the cookie, such as its lifetime and its scope (ie which pages can access it).

Retrieving a first-party cookie:

This is a bit harder because you have to find a named cookie in a browser's "cookie-jar" that contains cookies with many other names. The following would do the trick:

fontSize = document.cookie
  .split('; ')
  .find(row => row.startsWith('font-size='))
  ?.split('=')[1];

When you run this, the font-size cookie's value will be set on the fontSize variable.

Here are some more examples of useful first-party cookies:

Session Management & Authentication: These are cookies that keep you signed in to websites, allowing you to move from page to page without re-entering your password.

Shopping Carts & E-commerce: These are cookies that store items in a shopping cart, allowing users to add products and continue shopping or return later to complete a purchase.

The important point to remember about first-party cookies is that information accumulated here is accessible only to the first-party app. This post now describes how other types of cookie can be used to pass information silently to other websites.

3. Third-party cookies

Here's a screenshot of the cookie storage from another site. It's the helpful word-finder webapp I use when desperate to complete a crossword.

Notice that the familiar first-party cookie entry for the crosswordsolver.org domain is now followed by a long list of cookie entries for other domains (eg visitor.omnitagis.com). Hmm - what are these doing there?

The word finder site is very useful to me, but it has never charged me for the service. How can this be? The truth is that behind the scenes, I'm paying for it in another way. This site has negotiated deals with advertisers who pay the site for advertising space. Fair enough, you might say, but there is more to this deal than meets the eye. If I click on an ad that has caught my eye, I will find that, behind the scenes, I have got more than I bargained for. The advertiser will have set a cookie in my browser storage that contains a unique code. Whenever I use crosswordsolver.org in the future, the advertiser will be informed. It doesn't know who I am, but it does know that the same person is making a return visit.

Even more sinisterly, if I click on other domains that carry ads for the same agency, the agency site will again be informed of my visit. This is because the cookie is shared. I am now being tracked cross-site.

Cookies like those owned by visitor.omnitagis.com in the Inspector's "cookies" view of the crosswordsolver.org site are "third-party" cookies. They appear here because the visitor.omnitagis.com site is embedded somewhere in the crosswordsolver.org site - probably as an advert. The information they supply is used to deliver personalised, targeted advertisements relevant to user interests. Suppliers are happy to pay considerable sums to agencies if they increase sales. I myself might be pleased to be alerted to products I might be interested in. But not always ....

The early history of third-party cookies

You might wonder why anybody ever thought that third-party cookies were a good idea. It seems, however, that browser designers thought third-party websites should be provided with a mechanism to configure persistent user state just like first-party sites. For example, a user of an embedded map should be able to set a region or location preference and see it restored after a session break. For simplicity, the designers opted to preserve this state in cookie storage and then sought ways to create and access third-party cookies.

Setting a third-party cookie

Third parties cannot use the document.cookie method to set a cookie for the very good reason that they are in a different domain. What they can do, however, is add a Set-Cookieheader to the response to a file request from the first-party site. Typically, this request would be received when the browser is loading the embedded third-party site.

To set a uid parameter in the third-party cookie, the third-party's server might use code like this:

res.setHeader(
  'Set-Cookie',
  'uid=ABC123; Path=/; SameSite=None; Secure'
);

res.sendFile('/path/to/file.html');

On successful receipt of file.html, the browser would detect the header and set the cookie as instructed.

Reading a third-party cookie

The "headers" trick is used again here. Obviously, the third-party can't directly address the first-party and ask for its cookie. In fact, it doesn't have to because the browser sends the third-party's cookie as a standard Cookie header with every file request to the third party's files.

The Get command launched by the browser would typically look like this:

GET /page HTTP/1.1
Host: tracker.example
Cookie: uid=ABC123; prefs=dark

How third-party cookies track user activities

In order to display an ad, a domain like https://www.crosswordsolver.org/ must launch a "Get" instruction to obtain files containing images, scripts, etc., from the advertising agent's website. As described above, if there is a cookie for this third-party website, the browser automatically adds it as a Cookie header to the Get request.

Initially, the browser won't have a cookie for this particular third party. Recognising this, the third-party server will duly create one by adding a set-cookie header to its response. The content of the cookie thus created will be innocuous - simply a unique identifier looking something like the uid=ABC123 example used above. But this is the point at which the third party has created the opportunity to track the user's subsequent activity - potentially indefinitely.

On every subsequent visit by the user to the website, the third party will be contacted again. This is because at least one of the files referenced by the ad will have been tagged with "no-cache," which requires a refresh. To minimise impact on site performance, this will be a tiny dummy file displaying a blank 1*1 pixel image or a minimal JS fetch. As before, the third-party cookie with its unique tag will be set, and the third party will know that "this user" has visited the site again. If the user actually clicks an ad, more information will be gathered, and the agency will begin to build a picture of the user's interests.

But worse still, as mentioned earlier, if the third-party domain has ads on other sites, the cookie created by your use of the first site will also take effect here. This is because cookies are stored in the browser's cookie storage solely by their third-party domain. The user is now said to be tracked "cross-site". It's important to recognise that, at this stage, the agency doesn't know who you are - it only knows that this is the same person it has seen previously. But as you'll see shortly, over time and through cross-matching with other information sources, identification may be possible.

This tracking will persist until you clear your browser's cookie history. As you'll know, this is a very disruptive action (deleting useful sign-in credentials, etc., along with any third-party cookies), so you won't be in a hurry to do it too often!

Finally, what a third party realistically infer from tracking data.

(a) You are the same user across many sites

If cookie ID=9f3a8c2e1b appears on, say, news-site.com, diy-forum.net, travel-deals.org, the tracker infers: “These visits came from the same browser/device, so they most likely reflect the interests of the same person.”

(b) These are your interests

From page context and ad clicks, trackers may infer:

• Shopping intent (e.g. “barbecue equipment”, “insurance quotes”)
• Hobbies (DIY, cycling, photography)
• Travel plans (locations, timing)
• Media preferences (politics, sport, finance)

This works even if you never click an ad.

(c) This is your approximate location

From the originating site's IP address, Language and locale, repeated patterns, trackers might infer

• Country
• City or region
• Sometimes workplace vs home patterns

(d) This is the sort of device you are using

From the request headers information, the tracker might be able to determine the type of device you are using, and whether this is one person or multiple people sharing the same device

(e) These are your behavioural patterns

Over time, trackers may infer: Daily routines, Active hours, Workdays vs weekends, Session length and frequency

This is often more identifying than name or email.

(f) This is the sort of person you are

Without knowing who you are, trackers can infer: Age bracket, Income range, Family status, Education level

(g) Potentially - this is who you are

On its own, the cookie is pseudonymous, but there is no guarantee that, given the opportunity to access publicly available information from other sites, a tracker could not make an informed guess about who you are.

In short, over time, a third party may build a cross-site profile of browsing behaviour and inferred interests, which may be commercially valuable for targeted advertising.

The sensitivity here is that the information is gathered covertly. The arrangement is now seen as abusive, and standards lobbies have united in their determination to see standards created that will put a stop to these practices

What has been done to curb the "threat" posed by tracker cookies?

Two points before answering this question:

• Not all tracking is contentious. For example, tracking arrangements such as "Google Analytics" are invaluable in enabling sites to gain information about user behaviour - which pages are visited, how long they stay, and what buttons are clicked. This helps website owners explore performance issues and improve functionality.
• Tracking monetises user activity, thereby funding many free services that one has become accustomed to taking for granted. Would it be a better world if one had to pay for every Google search or ChatGPT query in exchange for assurance that such use remained strictly private?

That said, you might like to know that among major browsers, Safari, Firefox and Brave now block third-party cookies by default. Chrome and Edge still permit them for now, but are actively phasing them out.

Also, where third-party cookies are still permitted, they must explicitly label themselves as such by setting the SameSite=None; Secure properties. This makes cross-site cookies more visible and auditable, both by browsers and regulators.

But even when third-party cookies are blocked, I regret to say that there are many other ways advanced technology can still track our activity online. Even without cookies, a server can correlate requests using:

• IP address
• timing
• your browser's "signature"
• request patterns

While these data are individually weak, collectively they are strong. The information they provide is probabilistic, but often good enough.

See the next section for some advice on common-sense precautions you might employ to limit your exposure

4. Third-party identity cookies

In an ordinary third-party cookie, the "payload" will contain only an anonymous (but unique) identifier. But if the cookie was created by a website that signed you in with an Identity Provider such as Google, there was previously an opportunity for the identity cookie to carry your email address.

Clearly, the information gathered by such a third-party identity cookie is enormously more valuable - and potentially enormously more dangerous to the individual that is being tracked.

Recent moves by apps to routinely use "federated sign-in" to authorise users would appear to magnify this risk enormously. The good news is that authentication gateways such as "Sign in with Google" operate under a new FedCM standard that is explicitly designed to prevent Google itself from setting a third-party identity cookie on the site.
See "Sign in with Google", "Google One Tap" and "FedCM" for further information

The bad news is that the app itself does know the user identity, and there is nothing, in principle, to stop them from selling this information to third-party advertisers on their site.

In principle, this is where GDPR comes in. GDPR is a legal framework that requires apps to disclose how they use your data. An app would experience a massive backlash if it were ever revealed to be systematically exploiting the trust that its users had placed in it

But in such a complex and obscure environment, it clearly pays to be cautious. Privacy-conscious users should ring-fence their activities and use different identifiers for different services.

5. Summary and practical takeaways

Browser cookies began life as a simple, pragmatic solution to a real problem: how to make a stateless web feel usable. Over time, however, the same mechanism was repurposed to support large-scale, cross-site tracking — often without users’ knowledge or meaningful consent.

Modern browsers and regulators have now recognised that this arrangement has gone too far. Measures such as SameSite restrictions, third-party cookie blocking, cookie partitioning, and FedCM are all attempts to restore a balance between functionality, privacy, and transparency. They do not eliminate tracking entirely, but they do make covert, ambient tracking much harder to justify and much easier to see.

For users, a few common-sense conclusions follow:

• Not all cookies are bad — many are essential to how the web works.
• First-party cookies generally pose limited risk when used responsibly.
• Third-party cookies enable cross-site tracking and deserve greater scrutiny.
• Consent prompts exist because the underlying practices were opaque, not because cookies themselves are inherently dangerous.
• Blocking third-party cookies improves privacy, but it does not make tracking impossible.
• Awareness — not paranoia — is the most effective defence.

For developers, the lesson is equally clear: privacy-respecting design is no longer optional, and mechanisms that rely on silent cross-site state are living on borrowed time.

The web is in the middle of a long, imperfect correction. Understanding how we got here is the first step toward using it more thoughtfully.