If you work on managing or developing Research and Education federations – or are simply curious about browser privacy – this post is for you.
We delve into the navigational tracking mitigations currently implemented in major web browsers. In a follow-up post, we will present experiments that examine the impact of these mitigations on the single sign-on (SSO) protocols used within Research and Education federations, as well as what actions you can take in response.
Browser Privacy Changes?
Online privacy is a crucial issue. People are increasingly aware of how their personal data is being collected and how their online activities and interactions can impact their privacy. Major regulatory bodies have taken steps to safeguard consumer rights by enacting newer (e.g. the Washington Privacy Act in the US) and enforcing existing (e.g. GDPR in the European Union and the Data Protection Act in the UK) protective legislation.
Cross-site tracking
An important battleground for online privacy is the tracking of users across different websites (cross-site tracking). Since the early 2000s, the (then emerging) digital advertising industry has sought to track and target individual users at a level of granularity they simply could not with magazines or printed adverts.
Tracking users cross-site can be accomplished through various technical methods, including but not limited to the following:
- Third-party cookies: These are cookies set for a site different from the one the user is currently visiting. They can be used to identify the user and track their behaviour across multiple websites. Noting that third-party cookies do have legitimate uses, such as implementing single logout (SLO).
- Browser fingerprinting: This involves collecting, correlating, and sharing (from website to marketing provider) information about the user’s web environment to statistically identify a person. For example, your browser version, the operating system you are using, any browser extensions you have installed etc. (information which, up until now, has been commonly sent to or is interrogatable by web servers).
- Navigational tracking: Navigational tracking overcomes third-party cookie deprecations by tracking a users’ identity during site navigations. It often takes the form of “bounce tracking,” which may include additional tracking query parameters or path variables.
Navigational Tracking Explainer
Navigational tracking is the general term for tracking users across different websites using browser navigations. Bounce tracking is a specific type of navigational tracking that utilises automatic navigations (e.g., HTTP 302 redirects) to track users. When a user moves from one site to another or navigates within a site, they are ‘bounced’ through an intermediary tracking site. During this ‘bounce’, the URL can be modified to include additional parameters that help identify the user to the intermediary site. Furthermore, since the tracking site acts as a first-party site, it can set and receive its own cookies, allowing for tracking even if third-party cookies are blocked.
The following shows two of the most common forms of cross-site bounce tracking:
For example, taking the ‘Bounce Back Tracking’ scenario depicted in Figure 1, as a user on a shopping website which supports cross-site tracking:
- Search for a product, and when you find it, click on the link.
- The first navigation is a redirect to an ad-tracker site with a decorated URL (e.g., using the query parameter ?userId=ID).
- The tracking site is now first-party.
- The query parameters, along with any stored first-party cookies on the tracking site can be utilised to identify the user and their behaviour.
- The tracker then performs a HTTP 302 redirect to navigate the user to the retailer site, as was the initial expectation of the user.
Bounce-tracking happens so quickly that it is difficult for the user to notice.
Taking measures to prevent tracking is essential for enhancing user privacy on the web. However, it is equally important to recognise that bounce tracking and web single sign-on (SSO), a key feature of federated logins, are often indistinguishable. For example:
- The user visits a service provider to access a protected resource.
- The service provider asks the user to log in.
- The user selects federated SSO; the service provider constructs a URL decorated with authentication related query parameters and redirects the user to their Identity Provider.
- The Identity Provider has a pre-established security context with the user and so forms a response and immediately redirects the user back to the service provider.
- The user does not interact with the Identity Provider in this scenario.
- The service provider verifies the response and either grants or denies the user’s request to access the resource.
This situation becomes more complex because the initial request may go through a non-interactive authentication proxy. The proxy redirects the user to an upstream Identity Provider before replying to the Service Provider. Authentication chaining like this can involve several proxies or hops. This scenario resembles the “Bounce Through Tracking” method, the second type illustrated in ‘Figure 1‘.
How are web browsers implementing navigational tracking
As of August 2024, browser vendors have differing implementations of bounce tracking mitigations. There is work within the W3C’s Privacy Community Group to document approaches by each of the major browsers, and suggest common, standardised, algorithms for future implementations.
Chrome
Chrome enabled bounce tracking mitigations by default from version 116 (August 2023) for users who have chosen to block third-party cookies. Their implementation follows the W3C’s Navigational-Tracking Mitigations draft.
Chrome flags sites as tracking sites if they access storage (e.g. cookies and local storage) during a redirection. Then, in the background, Chrome will traverse the list of flagged sites and determine if the user have interacted with the site within the previous 45 days. If not, all storage for that site is deleted the next time that redirection is performed.
Firefox
Firefox included bounce-tracking mitigations by default since version 79 (in 2020) with improvements in version 127 (in 2024) to align more closely with the algorithms described in the W3C’s Navigational-Tracking Mitigations draft.
Enhanced Tracking Protection (ETP) identifies domains, specifically the eTLD+1, as a tracking domain if the domain has set cookies or accessed storage within the last 72 hours, the domain is contained within the Tracking Protection (Disconnect.me) list, and the user has not interacted with the site in the past 45 days (In Firefox, interaction includes scrolling a page).
Once tracking domains are identified, Firefox clears a comprehensive list of site data including cookies, HTML local storage, and security settings. It also removes known tracking query parameters from URLs, including those from Facebook, Google, and Microsoft.
Recently, Firefox Nightly has incorporated the approach outlined in the W3C’s Navigational Tracking Mitigations draft. Expanding the Tracking Protection list to also classify trackers using similar heuristics as Chrome. This will identify state-setting domains that the user has visited but not interacted with in the last 45 days.
Safari
Since 2018, Apple has employed its Intelligent Tracking Prevention (ITP) version 2.0 to classify websites as first-party bounce tracking sites. This classification relies on data collected from indicators of cross-site tracking behaviour, which inform a machine learning classification model. For instance, one heuristic used in this process examines whether the user has interacted with the website that they are visiting, such as by clicking a button. If a site (eTLD+1) is identified as a tracker, Safari will:
- Immediately partition cookies: Third-party cookies are partitioned per top-level site, preventing them from accessing cookies across different sites. For example, the third-party embed C on website A has access to cookies A.C, and on-site B has access to cookies B.C but not A.C-– previously site C would have the same set of cookies on both sites.
- Remove cookies after 30 days of further non-interaction: any existing cookies and data for that site are removed and new cookies or data are blocked.
- There is no way to manually exclude domains from ITP rules.
This policy has been tightened in ITP v2.2 and ITP v2.3 [19] for cookies set by the client/browser (e.g., via JavaScript’s cookie API). That is, capping cookie lifetimes to one day if the redirecting site has been classified as a cross-site tracker and the redirection URL contains a query string or fragment identifier. Additionally, first-party storage (e.g., LocalStroage) is capped at seven days if the user has not interacted with the site within that time.
Possible impact of changes on single sign-on
In the current implementations of both Chrome and Firefox, the Identity Provider is unlikely to be flagged as a “tracking site” because the user would typically interact with their Identity Provider within a 45-day period. However, this situation may change if the Identity Provider acts as a proxy with which the user does not interact; in such cases, it is more likely to be identified as a tracker.
It is possible that in the future, the window for user interaction with their Identity Provider will be shortened further, which might eventually impact and degrade SSO performance. Safari is similar, although it is currently set to purge cookies after 30 days of non-interaction.
What is Next?
Look out for our upcoming blog post, we will conduct experiments to concretely measure the potential impact of these mitigations on current single sign-on flows.
