User tracking for digital marketing can violate user privacy on the web. Now that browser vendors are looking to implement methods to stop user tracking, we must ensure these methods do not clobber other frameworks which protect privacy such as Single SignOn through the UK federation, SAML and OpenID Connect.
Problems and mitigations
Digital marketing is Big Business, potentially taking over from traditional marketing mediums such as print or broadcast. User tracking through the complex digital advertising ecosystem is key to gathering digital analytics and maximizing marketing revenue.
Popular tracking techniques currently employed by marketing agencies use existing web primitives to track users across sites. These techniques include third-party cookies, query parameter link decoration, and sequences of almost undetectable HTTP redirects to advertiser sites (navigational tracking). The UK’s Information Commissioner said “most of the time, individuals are not aware that this is happening or have not given their explicit consent. This must change” [1].
Mitigations from Ad blocking apps and plugins have been around for a long time. These typically work by blocking requests to known ad-tracking domains. Now, browser vendors themselves are in a race to prevent cross-site (third-party) tracking to improve user privacy on the web, regain users’ trust, and comply with data protection laws. Apple started their comprehensive Intelligent Protection Prevention System (ITP) [2] using machine learning in 2017. Firefox widely deployed its Enhancing Tracking Protection [3] in 2019. Google, on the other hand, has a direct need to support advertising on the web and as such have launched a series of initiatives based on their Privacy Sandbox for the Web [4]. Other browser vendors have different takes on tracking mitigations [5].
A common goal to prevent tracking is to block third-party cookies. All major browser vendors, except Google, do this by default today. Google has delayed its rollout until 2024, long enough for advertisers to move to Google’s Privacy Sandbox for targeted, cohort-based, advertising.
Firefox and Apple currently include early mitigations for link decoration and navigational tracking. Apple uses machine learning to classify tracking sites, capping the lifetime of any tracking cookies they set. Similarly, Firefox removes all storage including cookies after 24 hours for known tracking sites—based the Disconnect.me list—and removes query parameters from URLs based on a curated deny list (Facebook and Google do not fare well in these lists [6]).
This presents a challenge to the federated access world. Delegating authentication through protocols such as SAML and OpenID Connect uses the same web primitives that browsers are attempting to deprecate. Third-party cookies are not critical for most SAML flows, but changes to the way browsers handle link-decoration and navigational tracking may have unwanted side-effects in the future.
- SAML authentication requests in URLs look like link decoration
- WAYFless URLs also look like link decoration
- HTTP 302 redirects from the SP (Service Provider) to the IdP (Identity Provider) looks like navigational tracking
Introduction of the FedCM draft
The Federated Credential Management API (FedCM) aims to support the primitives required by federated identity protocols in the face of third-party cookie deprecation and other cross-site tracking mitigations.
FedCM is under active development and so far, represents a notable change to the way federated authentication occurs on the web. The browser will take an ‘active’ part in the authentication process, mediating both ‘account’ selection through a browser-driven UI (User Interface), and authentication token exchange between the IdP and SP. Whilst the proposal has merit from the perspective of social-login providers, it does not scale well to multi-lateral SAML authentication flows used in established R&E (Research & Education) federations.
Research and Education Hackathon
Google’s web platform team and Mozilla invited representatives of the R&E community to Mountain View in early 2023 to discuss the FedCM draft in the context of R&E federations. The Shibboleth Consortium [11] funded Phil Smart, a Senior Software Engineer in Jisc’s Trust & Identity group, to attend.
Demonstrations of federated authentication flows that included IdP discovery were given, limitations of the current FedCM proposals were discussed, and two new proposals put forward [8][9]. Broadly speaking, both proposals require the user consenting to the authentication flow that is about to happen between the SP and IdP. Once consent has been given, the flow will be allowed to continue as normal, and the browser promises not to interfere —allowing third-party cookies, decorated links, and 302 redirects. This represents a fundamental change to the current FedCM draft.
Next steps
Work is continuing in the W3C FedID Community Group [7] and the REFEDS working groups [10].
For now, it is important for the R&E community to track and lead these new FedCM drafts. If they become necessary in the face of browser led cross-site tracking mitigations, it will mean a change to the way IdP’s and SP’s work, and a new authentication experience for users.
You can contact Phil Smart at trustandidentity@jisc.ac.uk for more information.
[2] https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
[3] https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop
[4] https://privacysandbox.com/
[5] https://privacycg.github.io/nav-tracking-mitigations/#navigational-tracking
[6] https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/query-stripping/records
[7] https://www.w3.org/community/fed-id/
[8] https://github.com/fedidcg/proposals/issues/4
[9] https://github.com/fedidcg/proposals/issues/5
[10] https://wiki.refeds.org/display/GROUPS/Browser+Changes+and+Federation