Subject: [Model-t] Web Tracking

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Feb 2020 09:31:45 -0800

And here is our text on Web Tracking

One of the biggest threats to user privacy on the Web is ubiquitous
third party tracking. This takes advantage of HTTP Cookies [RFC6265]
in what is called a "third party context". The basic idea here is that
whenever a resource is loaded from a server, that server can include a
cookie which will be sent back to the server on future loads. This
includes situations where the resource is loaded as a "subresource" on
a page (e.g., an image, a piece of JavaScript, etc.). In addition,
those loads include a Referer header which contains the top-level page
that the subresource is being loaded from.

The combination of these features makes it fairly straightforward to
build a system which tracks the user across the Web. The way this
works is that the tracker convinces a number of content sites ("first
parties") to include a subresource from the tracker site.  Sometimes
this subresource also performs some other function such as displaying
an ad or providing analytics to the first party site, but sometimes it
is simply a tracker. Then, whenever the user visits one of those
content sites, the tracker receives the pair of (1) the Referer header
and (2) the cookie, which is the same for each browser client
regardless of which site the tracker is on. Together these allow the
tracker to build up a picture of the user's browsing history. This
can then be used for various purposes, but is most commonly used
for ad targeting.

This capability itself constitutes a major threat to user privacy.
However, there are a number of practices which increase the threat:

* Cookie Syncing: any given tracker may not be on all sites,
  which gives the tracker incomplete coverage. However, trackers
  often collude (a practice called "cookie syncing") to bridge
  different tracking cookies.

* Identifier correlation: sometimes trackers will be embedded
  on a site which collects a user identifier (e.g., an e-mail
  address), in which case the site can inform the tracker of the
  address which allows the tracker to tie it to the cookie.

* Fingerprinting: Cookies are a form of explicit state, which allows
  browsers to blook or erase them. However, it is also possible to use
  characteristics of the browser to track the user.  For instance,
  features such as User-Agent string, plugin and font support, screen
  resolution, and timezone can yield a fingerprint that is sometimes
  unique to a single user [0] and which persists beyond cookie
  deletion. Even in cases where this fingerprint is not unique, the
  anonymity set may be sufficiently small that, when coupled with yet
  more data, yields a unique, per-user identifier. Fingerprinting of
  this type is more prevalent on systems and platforms wherein data
  set features are flexible, such as desktops, wherein plugins are
  more commonly in use.  Fingerprinting prevention is an active
  research area; see [1] for more information.

A number of browsers have started adding anti-tracking technologies.
This is a rapidly moving field and so it is difficult to characterize
here, but there are several basic ideas:

* Blocking any communication with known trackers
* Identifying trackers and suppressing their ability to store
  and access cookies and other state.
* "Double keying" in which each third party load on different
  first party sites is treated as a different context, thereby
  isolating cookies and other state, e.g., TLS-layer information.

[0] Gómez-Boix, Alejandro, Pierre Laperdrix, and Benoit Baudry. "Hiding in
the crowd: an analysis of the effectiveness of browser fingerprinting at
large scale." Proceedings of the 2018 world wide web conference. 2018.
[1] https://amiunique.org

---

From: Jim Fenton <[email-masked]>
Date: Mon, 17 Feb 2020 10:14:52 -0800

> And here is our text on Web Tracking

Excellent summary.

> that the subresource is being loaded from.

In addition to the Referer header, I would also mention the use of
identifiers in the URL, often encoded as query components. They can not
only associate the query with the top-level page, but also persist when
a URL is shared from one user to another, giving the tracker visibility
into user relationships.

-Jim

---

From: "Dirk Kutscher" <[email-masked]>
Date: Mon, 17 Feb 2020 19:46:08 +0100

Thanks — very useful!

Dirk

> -- 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 17 Feb 2020 22:18:43 +0300

Peace,

> And here is our text on Web Tracking

The text doesn't mention a potential side channel issue.  E.g. today,
the world's largest user activity tracker is also the world's largest
Web browser vendor, so in theory, they technically (I'm not saying
"legally") don't need cookies at all.  Other side channels exist, e.g.
a DDoS protection provider who happens to also provide a VPN phone
app.

--
Töma

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Feb 2020 21:07:32 +0000

Thanks again for more good text.

> here, but there are several basic ideas:

Yeah, this area is harder to describe both because it's
so active but also I think because many of those in
this space to some extent today depend on the ad based
business model and/or want to track people for reasons
some of the people tracked will consider good, while
others will regard that same tracking as bad. Töma's
mail also hits on that aspect I think.

The other thing that struck me is that collecting
telemetry and calling-home (for s/w update) are
somewhat similar to web tracking. I think Mozilla have
been actively trying to reduce the tracking potential
of your telemetry in various clever ways, so pointers
to that might help the discussion some. I've no idea
if anyone has had good ideas about better ways to call
home for updates though.

Anyway, I'll be really interested in where this
discussion goes!

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Feb 2020 13:34:06 -0800

Thanks for your note. I feel like both of these attacks fall into the
category of "local compromise" and thus are in a distinct bucket from Web
tracking.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 18 Feb 2020 00:48:23 +0300

Peace,

> category of "local compromise" and thus are in a distinct bucket from Web

There are different shades of "local" on the user's machine.  E.g. I think
one of the purposes of QLOG was to provide transparency about what
applications are doing by resurrecting the side reporting channel (which
existed ad-hoc before the applications began to carry their own encryption
stacks) to the system.

I personally feel there are different *scopes* of tracking rather than
different types.  The difference is basically that we won't be able to find
a MECE segmentation which won't be biased.

--
Töma

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Feb 2020 14:03:07 -0800

> a MECE segmentation which won't be biased.

I don't really agree with this. Web Tracking uses existing Web APIs in an
unexpected (and largely undesirable) way. It is a totally different threat
model from the attacker running malicious code on the user's machine.

Anyway, I'm not sure debating this is that useful, as we're not writing a
document here; my note was merely my description of a specific topic. If
you'd like to write your own description of some set of threats, you should
go ahead.

-Ekr

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 18 Feb 2020 01:13:02 +0300

Peace,

On Tue, Feb 18, 2020, 1:03 AM Eric Rescorla <[email-masked]> wrote:

> There are different shades of "local" on the user's machine. [..]
>>
>
> [..] Web Tracking uses existing Web APIs in an unexpected (and largely
> undesirable) way. It is a totally different threat model from the attacker
> running malicious code on the user's machine.
>

Does (or does not) the concept we discuss here include running malicious
frontend JS code on the user's machine?

--
Töma

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Feb 2020 14:20:41 -0800

> frontend JS code on the user's machine?

Well, I can't speak for "we", but from the perspective of a browser
manufacturer, the threat model includes malicious JS.

-Ekr