Third-party requests

## Why it matters

A third-party request leaves a trail. Your browser makes a request to domain B while you're on domain A, and domain B learns where you are. Repeat that millions of times across the web and you've built a surveillance network. Trackers rely entirely on this mechanism to follow you between sites.

Ad networks use the same pattern. A banner ad on a news site isn't hosted by the news site; it's hosted by Google, Criteo, or another ad network. That fetch is third-party, and it's how the network knows you visited. Block third-party requests and you stop most tracking. You also stop the adverts.

Filter lists like EasyList and EasyPrivacy spend their effort on third-party domains because that's where the leverage is. First-party scripts (code the site owns) are harder to block without breaking the page; third-party code is fair game.

## How it works

The browser always knows which domain you're on, because the address bar shows it. When the page asks the browser to fetch something from a different domain, that's a third-party request. The browser sends the request with the address of the page you're on (the Referer header), so the third party knows where you came from.

Here's a concrete example. You open https://example-news.com:

1. The browser fetches the article from example-news.com.
2. The article HTML tells the browser to load a script from analytics.com. This is a third-party request.
3. The browser loads it and sends Referer: https://example-news.com, so analytics.com knows where you are.
4. A banner ad tells the browser to fetch a creative from ads-network.com. Another third-party request, another tip-off.

The terms are fixed: first-party means the domain matches your address bar; third-party means it doesn't. A request is third-party or it isn't, depending on that one thing.

Filter rules target third-party requests with the $third-party option. EasyPrivacy uses it heavily; the rule ||analytics.com^$third-party says "block analytics.com only when it's loaded from somewhere else." Load analytics.com's own site and the rule doesn't fire. This keeps the page from breaking when you visit the service itself.

Chrome's declarativeNetRequest API exposes this distinction with the domainType condition. Rules can check whether a request is thirdParty or not and act accordingly. Scalpel's ruleset uses it to separate third-party trackers from everything else.

## What does not matter

Cross-domain requests aren't inherently bad. Fonts, scripts, and stylesheets often come from CDNs. As long as the third party isn't tracking you, the origin doesn't matter; your browser handles mixed content transparently.

The distinction only matters for tracking and targeting. A third-party image service that serves pictures stays invisible; a third-party analytics script that watches your behaviour is the problem. The mechanism is the same (a request from a different domain); the intent differs.

Don't mistake "third-party" for "ad network." Some ads are first-party (hosted by the site itself) and some third-party analytics serves no advertising purpose. The term describes where the request comes from, not what it does.

## Code example

In the HTML of example-news.com:

<!-- First-party: from the news site's own domain -->
<script src="https://example-news.com/js/article.js"></script>

<!-- Third-party: from an ad network -->
<script src="https://ads-network.com/banner.js"></script>

<!-- Third-party: from an analytics service -->
<img src="https://analytics.com/track?page=article" alt="" />
Copy

In the browser's network tab, both requests show up. The analytics request includes Referer: https://example-news.com so the analytics service knows you're reading the news.

A filter rule to block third-party analytics:

||analytics.com^$third-party
Copy

This blocks analytics.com only when loaded from somewhere else. If you visit analytics.com directly, the rule doesn't fire.

## How Scalpel shows it

Scalpel Ads Blocker's ruleset uses domainType: "thirdParty" in its declarativeNetRequest rules to target third-party requests only. Most tracker URLs are blocked with this condition, so the rules don't interfere when you're on the tracker's own site.

The blocked count reflects all rules that matched, including third-party blocks. When you open Scalpel's popup, the count shows how many third-party and first-party requests Chrome stopped on the current page.