Re: [Model-t] Web Tracking

Thanks — very useful!

Dirk

On 17 Feb 2020, at 18:31, Eric Rescorla wrote:

> 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

> -- 
> Model-t mailing list
> Model-t@iab.org
> https://www.iab.org/mailman/listinfo/model-t