KWANZA SONORA EDWARDS

Professional Documentation Platform

The Invisible Trail

Cookies are often presented as a simple choice: accept or decline. But the choice presented to you is only one part of the story. As a Network Analyst and Researcher, I have encountered sites where I have opted out of tracking, yet the browser continues to contain cookies carrying information that can reveal characteristics such as location, session activity, or identifiers. At the same time, more websites and even services designed to protect privacy, including VPN providers are increasingly presenting cookie controls and options for managing cookies.

The problem is that cookies are not one universal object.

A cookie belongs to a particular domain, is created for a particular purpose, and can contain information specific to the application that created it. An option in one service's dashboard cannot automatically tell you what every other website is doing in your browser.

This is where the journey begins.

A cookie banner may tell you that cookies are being used. An opt-out button may tell you that you have declined certain categories of tracking. But neither necessarily teaches you what was actually placed in your browser, what information it contains, where it came from, or how it is being used. This guide is about closing that gap. Rather than asking you to take a website's privacy statement or a cookie banner at face value, this field guide gives you a way to identify and research a cookie for yourself.

Consent is a choice. Understanding is a capability.

Once you know where to look, the browser stops being a black box. You can begin to see the identifiers being created, the domains communicating with your browser, and the information being stored locally as you move through the web.

Consent is a choice. Understanding is a capability.
That distinction matters. This guide is intended to help you develop that capability. Knowledge is power, but only when you know where to look.

Finding a Cookie in Your Browser

You do not need specialized security software to begin examining cookies. Your browser's built-in Developer Tools give you direct access to the cookies stored by a website.

For this example, we will examine a cookie named:

`_ga_SLN5FJT0F4`

The exact names will vary from site to site and there may be multiple cookies from a site.
The important part is learning how to locate the cookie and then read the information associated with it.

Step 1: Open Developer Tools

Open the website you want to examine.

In most desktop browsers, you can open Developer Tools by:

* Windows/Linux: `F12` or `Ctrl + Shift + I`
* macOS: `Cmd + Option + I`

You can also right-click anywhere on the page and select Inspect.
Developer Tools will open alongside or beneath the webpage.

Step 2: Open the Storage or Application Tools

The exact name and location of this section varies slightly between browsers.
In Chromium-based browsers such as Chrome and Edge, look for the Application tab.
In Firefox, look for the Storage tab.
These sections allow you to examine information the website has stored in your browser, including cookies.

Step 3: Find Cookies

Expand the Cookies section.

You should see one or more domains associated with the website.

Select a domain and examine the cookies listed for it.

You may see columns such as:

  1. Name
  2. Value
  3. Domain
  4. Path
  5. Expires / Max-Age
  6. Size
  7. HttpOnly
  8. Secure
  9. SameSite

This is where the cookie becomes something you can actually inspect rather than something you simply agree to in a banner.

Step 4: Examine Cookie

What Is the _ga Cookie?

There are many cookies, let's analyze the following cookie.

Cookie Name
_ga_SLN5FJT0F4
Purpose
Google Analytics 4 (GA4) persistent tracking cookie
Domain
.google.com: third-party
Type
Persistent: remains after session ends
HostOnly
false: accessible by subdomains
Secure
false: transmitted over HTTP

The Cookie Value: Array Breakdown

The cookie value is an array with three elements:

    _ga_SLN5FJT0F4: Array [
      0: "GS2",
      1: "1",
      2: "s1784582869$o1$g1$t1784582951$j60$l0$h0",
      length: 3
    ]

Decoding the Encoded Session Data

The third element contains the session data, separated by $ symbols. Here is what each part means:

s1784582869
s = session start: the user's session began at this timestamp
$o1
o = session count: 1 = first session for this user
$g1
g = campaign attribution: 1 = organic/direct traffic
$t1784582951
t = last activity: the user's last interaction at this timestamp
$j60
j = session duration: 60 = the session lasted 60 seconds
$l0
l = language/location: 0 = default/unknown
$h0
h = hit count: 0 = no hits recorded yet

What This Reveals:
This cookie contains a complete record of the user's session when it started, how long it lasted and when they were last active. It also contains a unique client ID that allows Google to track this user across sessions and across sites.

A cookie does not necessarily contain a sentence that says:
"This user started a session at this time and has been active for this long."
Instead, the application may store that information using compact identifiers and delimiters.

What You Can Learn From the Cookie

Once you know how to inspect the individual fields, you can begin asking better questions.

Who created this cookie?

Look at the domain and the cookie name.

How long is it intended to remain in the browser?

Look at the expiration information.

Can JavaScript access it?

Check the `HttpOnly` attribute.

Is it restricted to HTTPS?

Check the `Secure` attribute.

Can it be sent in cross-site contexts?

Examine `SameSite`.

What information is contained in the value?

Inspect the value itself and determine whether it contains identifiers,

timestamps, counters, or other structured data.

This is the difference between seeing a cookie and reading a cookie.

The browser gives you the evidence. Your job is to learn how to interpret it.

The cookie is one piece of a larger system.

To understand what information is actually being collected and where it goes,
you eventually need to examine other parts of the Application Layer as well,
including network requests, DNS lookups, scripts, and third-party connections.
That is why this field guide begins with the cookie.
It gives you a place to start.
Find it. Read it. Question it. Then follow the data.

Epoch Convert

When you encounter a number such as:

1784582951

inside a cookie, it may look like an arbitrary identifier. It may not be.

One useful technique when examining structured data is to ask:

Could this number be a timestamp?

What Is an Epoch Timestamp?

An Epoch timestamp represents a point in time:
January 1, 1970, 00:00:00 UTC
This is commonly called Unix time or Epoch time.

That means a value such as:
1784582951

can potentially be converted into a conventional date and time.

Ask a few basic questions:

  1. Could this be a timestamp?
  2. Does the number fall within a plausible date range?
  3. Does converting it reveal a meaningful relationship with another value?
  4. Does the value change when you perform an action?
  5. Can you observe the same value or event in a network request?

This is how an investigation develops.

Convert the Value

Take the value from the cookie:

1784582951

You can convert it using a programming language, a calculator, or an Epoch conversion tool.
The number is no longer just a string of digits.
It represents a specific point in time.

A cookie value that initially looked like:
1784582951
has now become:
July 20, 2026 — 19:29:11 UTC

How Third-Party Tracking Works

Now that you know how to find a cookie and examine its value, the next question is:
How does a cookie become part of a larger tracking system?
The answer begins with the connections a website makes to third-party services.
A useful way to understand this is to follow the same identifier as you move between different websites.
A cookie does not physically "follow" you from site to site like a shadow.

For this example, imagine:

  • Site A — the website you are visiting
  • Site D — another website
  • Company X — a third-party service used by both sites

Step 1: You Visit Site A

You visit Site A.

Site A includes a script or other third-party resource provided by Company X.

That resource may cause information to be exchanged between your browser and Company X's servers. Depending on the technology being used, an identifier may be created or read.

For example:

_ga

The browser stores the associated cookie according to the cookie's attributes.

At this point, you have created the first piece of the trail:

You

Site A

Company X

Identifier

The important thing to understand is that Site A does not necessarily need to be owned by Company X.

Company X can be present on Site A because Site A has incorporated Company X's service into its application.


Step 2: You Visit Site D

Later, you visit Site D.

Site D also incorporates a service provided by Company X.

Your browser again communicates with Company X.

If the browser can provide an identifier that Company X can associate with an existing record, Company X may be able to recognize that the request is associated with the same browser or identifier previously encountered.

The important distinction is that the recognition does not come from the cookie simply "following" you around the Internet.

The connection exists because the same third-party service is present in multiple places.

Conceptually:

Site A ──────┐


Company X


Site D ──────┘

Company X is the common connection.


Step 3: Activity Can Be Correlated

Now imagine that Company X is present on Site A, Site D, Site K, and Site S.

Each site may generate information about your interaction with that site.

Depending on the tracking technology and the data available to Company X, those interactions may be associated with the same identifier or other identifiers that can be linked together.

The result can look conceptually like this:

Site A ──┐
Site D ──┤
Site K ──┼──► Company X ──► Associated activity
Site S ──┘

This is where individual observations can become a profile.

The profile does not necessarily exist entirely inside one cookie. A cookie may contain only an identifier or a small amount of structured information.

The larger profile can exist on the server side, where the third party combines information received from multiple interactions and sources.

This distinction is important when investigating tracking.

The cookie is evidence of a mechanism. It is not necessarily the entire mechanism.


Step 4: The Data Can Be Used

Once information has been collected and associated with identifiers, it can potentially be used for purposes such as analytics, personalization, advertising, attribution, or other forms of profiling.

What happens next depends on the company, the data collected, the relationships between the parties, and the purpose for which the information is processed.

Finding the cookie is the beginning.

The next questions are:

  • Who set it?
  • What identifier does it contain?
  • What other requests are being made?
  • Where are those requests going?
  • What third-party services are present?
  • What information is being transmitted?
  • Can activity from different sites or sessions be associated?

Those questions move you from examining a browser artifact to examining a data flow.

The Important Distinction: Cookie vs. Tracking System

A cookie is only one component of a larger architecture.

A tracking system may involve:

  • cookies;
  • JavaScript;
  • HTTP requests;
  • DNS requests;
  • browser storage;
  • device or browser characteristics;
  • unique identifiers;
  • third-party services;
  • server-side databases;
  • and relationships between multiple data sources.

That is why simply deleting a cookie does not necessarily tell you whether tracking has stopped.

The cookie may be one identifier within a much larger system.

Conversely, finding a cookie does not automatically tell you exactly what information a company has about you.

You have to follow the evidence.

The browser tells you what has been stored.

The cookie tells you something about the identifier and its structure.

The network tells you where information is going.

And the combination of those observations gives you a much clearer picture of what is happening.

Follow the Identifier

This is the habit this field guide is trying to develop:

Don't just look at the cookie. Follow the identifier.

Start with the browser.

Find the cookie.

Read its attributes.

Examine its value.

Identify the domain.

Then look at the requests associated with that domain.

From there, begin mapping the relationships between your browser, the website, and the third-party services involved.

The invisible becomes visible one connection at a time.

Why This Matters: Connecting the Dots

Finding a cookie is interesting.

Understanding what the cookie connects to is where the investigation becomes important.

A cookie may be a small piece of data stored in your browser. An identifier may be only a short string of characters. A request may look like nothing more than a routine connection to another server.

Individually, these pieces can seem insignificant.

Together, they can become a much larger picture.

This is why learning to read cookies and follow data flows matters. The information collected at the Application Layer does not necessarily remain in the browser. It can become part of larger systems used for analytics, advertising, personalization, attribution, and—in some circumstances—profiling and decision-making.

Targeted Advertising

This is the most familiar example.

Information about your browsing activity, interests, interactions, and purchasing behavior can be used to personalize the advertisements you see.

You search for something.

You visit a related website.

You read an article.

You interact with an advertisement.

Those individual actions can become signals used to determine which content or advertisements are presented to.

The advertisement is what you see.

The data collection behind it is what you don't.

And targeted advertising is only one possible use of a digital profile.

Influencing What You See

The same kinds of signals can also influence the information presented to you.

Your previous interactions can be used to determine which content is recommended, prioritized, or shown to you.

Over time, this can create a feedback loop:

You interact with something

Your interaction becomes a signal

The system learns from the signal

Similar content is presented

You interact again

The cycle continues

This is one way personalized information environments can develop.

The important question is not simply:

"Am I being tracked?"

It is also:

"What decisions are being made from the information being collected about me?"

That question takes us beyond cookies.

When Data Becomes a Decision

The consequences become more significant when information about people is used to make decisions about them.

Digital information can be combined with other sources of information to create models, classifications, scores, or profiles.

The exact practices vary between industries and organizations, and a cookie by itself does not prove that any particular decision is being made about you.

But the broader possibility is important enough to understand.

Credit and Financial Services

Financial technology companies have explored alternative sources of information when evaluating consumers.

Depending on the system and the jurisdiction, this can include information about spending behavior, device usage, online activity, or other digital signals.

The advancements are worth researching:

More data can potentially help organizations make faster decisions, expand access, or evaluate people who have limited traditional financial histories.

But the same idea raises another question:

What happens when the data is incomplete, inaccurate, or interpreted incorrectly?

A data point that seems insignificant in isolation can take on very different meaning when it becomes part of a model.

Insurance

Insurance is another area where organizations evaluate risk.

Digital information can potentially become one input among many when assessing individuals or groups.

Again, the lesson here is not that a cookie sitting in your browser automatically determines your insurance premium.

It doesn't.

The larger issue is the ecosystem surrounding personal data:


  • What information is collected?
  • Who receives it?
  • What additional information can it be combined with?
  • What decisions can ultimately be influenced by it?

Those are the questions worth investigating.

Employment

Digital information can also enter the world of employment and hiring.

Organizations may examine publicly available information, social media activity, or other digital signals when evaluating candidates.

This creates an important distinction between what a person intentionally presents and what can be inferred from their digital activity.

You may consciously choose what to put on a résumé.

You may have much less awareness of the information being generated by your ordinary interactions with websites and applications.

Housing and Other Decisions

The same principle extends beyond advertising.

Whenever organizations use data to evaluate people, there is a possibility that information collected for one purpose can become relevant to another decision.

That does not mean every website is secretly building a profile to determine whether you qualify for an apartment, a loan, or a job.

It means that data has a lifecycle.

Collection is only the beginning.

The Promise and the Reality

There is usually a promise attached to data collection.

More information can mean:

  • more personalization;
  • faster decisions;
  • improved services;
  • better fraud detection;
  • more accurate analytics;
  • access to services that might otherwise be difficult to provide.

Those benefits can be real.

The problem begins when the person generating the data has little visibility into what happens after collection.

The Promise

Data can make systems more efficient.

It can help organizations understand how their services are being used, identify problems, personalize experiences, and make decisions at scale.

The Reality

The same data can become difficult for an individual to see, control, correct, or remove once it enters a larger ecosystem.

The person providing the data may never see the complete picture.

A cookie may be visible in the browser.

The server-side profile may not be.

The network request may be observable.

The downstream use may not be.

That is the gap this field guide is trying to help you understand.

The Human Impact of the Application Layer

It is easy to think of the Application Layer as a technical abstraction.

Packets.

Ports.

Protocols.

HTTP requests.

DNS.

Cookies.

JavaScript.

Identifiers.

But every one of those technical mechanisms ultimately exists within a system used by people.

The Application Layer is where information begins to acquire context.

A browser request can identify a resource.

A cookie can identify a browser or session.

An identifier can allow activity to be associated over time.

A collection of interactions can become behavioral information.

And behavioral information can become an input into systems that affect what people see, what they are offered, or how they are evaluated.

That is why the Application Layer matters.

It is not simply the layer where a webpage loads.

It is one of the places where the relationship between technology, data, organizations, and people becomes visible.

The Architecture of the Modern Web

The modern web is built from thousands of interconnected services.

A website may communicate with its own servers while simultaneously communicating with analytics providers, advertising networks, content delivery networks, payment processors, embedded services, and other third parties.

To the person visiting the page, this may look like one website.

From a network perspective, it can be many relationships happening at once.

That is why this field guide keeps returning to the same principle:

Follow the connections.

Start with the cookie.

Identify the domain.

Examine the identifier.

Look at the request.

Find the destination.

Identify the third party.

Then ask what information is being exchanged.

Each step gives you another piece of the picture.

You do not have to understand the entire architecture at once.

You only need to learn how to follow one connection at a time.

The Bigger Picture

The purpose of examining cookies is not to make you afraid of cookies.

It is to teach you how to investigate the systems behind them.

A cookie is small.

A data ecosystem is not.

Once you begin connecting the dots, you can start to see how a seemingly insignificant piece of information can participate in a much larger architecture of collection, correlation, and use.

The technical details matter because people are on the other side of them.

That is the human impact of the Application Layer.

BACK NEXT