Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
For background on standard bodies and their concerns regarding unsanctioned tracking, see [W3C TAG 2015] and [RFC-7258].

We care because authentication protocols strongly resemble the privacy threat called "bounce tracking". Other privacy and anti-tracking efforts also affect various elements of the higher ed technical infrastructure. This page identifies the term used generally, the threat to users, the mitigations being considered by the browsers, and the impact those have on federated identity systems.

FedCM is one of several additions to browser technology that is designed to allow users to tell browsers that certain cross-site communication – whether through cookies or bounces – is "sanctioned" by the end user. FedCM doesn't block any protocols; FedCM is a way for a user to signal trust to a browser that is otherwise protecting the user's privacy.

Table of Contents

Overview

>> Put link to overview of FedCM specifically here and explain the broader concerns of browser changes <<


How does it workMitigationsImpact

Navigational tracking

Bounce tracking transfers a user via redirect (or POST) from one site to another, exchanging information in the process. A common pattern is to have "decorated links" that have embedded identifiers for the user.

Safari: Intelligent Tracking Prevention – W3C Privacy CG draft

Firefox desktop: Enhanced Tracking Protection – Mozilla and W3C Privacy CG draft

Proposal Draft: when a user has no interaction with a site (at eTLD+1 level), limit cookies to an hour lifetime.

EVOLVING PRACTICE: FedCM is a possible signal to allow a more aggressive mitigation of bounce tracking while protecting SSO.

Authentication protocols use cross-site redirection with "link decoration" and POST to exchange information about the sites and the user.

While SSO is understood as a critical element, it is understood much more as a single bounce, consumer side authentication, without the many bounces to translate across protocls and implementations, nor is there understanding the trust models and authorization elements involved.

This is the main focus of REFEDS Working group interaction with the W3C groups.

Third party cookies"Third party cookies" are those sent or set in a browser when the top level document (the URL in the browser bar) makes image or iframe calls to other sites. 
  • FedCM : a new way for an authentication token to be exchanged
  • Cookies Having Independent Partitioned State (CHIPS, also know as Partitioned cookies) allows an iframe to set cookies that the iframe can retrieve across a specific top level site, but no other site – documentation from Mozilla and Chrome
  •  Storage Access API  or Shared Storage API allows a site to ask a user to allow third party cookies for that site's use – documentation

Third party cookies are not needed at any protocol specification. However, some consumer authentication libraries embedded in various sites and apps use third party cookies.

Within SAML, identity federation, and higher ed, implementations of logout and of Seamless Access are effected. In Seamless Access, the "smart button" is not available without third party cookies and introduces additional clicks in the flow for sites using advanced integration.

Cross site request cookies (2021)

Cookies received by a site when a user is directed to that site via a link from another site.

In a proposal shared in the W3C WebAppSec WG regarding "Standardizing Security Semantics of Cross-Site Cookies",  the authors note a pattern they call "Top-Level Cross-Site POST Requests."  The document recommends "Given the existing widespread usage and lack of clear alternatives, we recommend following the current state of the web and not blocking cross-site cookies in this scenario."

This applies to any SAML SP that has

  1. integrates using the recommended POST binding of the SAML response  
  2. uses SP initiated and saves state using cookies before sending the user for SAML authentication
  3. and expects those cookies to be presented on the response in order to correlate the response to a session state with initial request parameters.

iCloud Private Relay (2021)

Apple's Private Relay for iCloud+ customers is a "lite" relay network used only with Safari and TCP Port 80 (aka http) traffic. All DNS requests are encrypted and go through Apple.

Network relays and proxies can obscure the IP address of the users device or a network's WAN IP address(es) to protect endusers from being associated with a specific origin.

Campus networks that need users on the network to not go through a relays but to appear to originate from the network must make changes documented at "Prepare your network or web server for iCloud Private Relay" 

Systems that assume region or city level geoaccuracy when interpreting IP address may only get country level accuracy if the user chooses that setting in the relay configuration.


Secondary sources and articles

Slides, blogs, and videos

Useful references

[Hamilton] Dave Hamilton, “Digging into Apple’s ICloud Private Relay,” The Mac Observer, June 9, 2021, accessed May 24, 2023, https://www.macobserver.com/tips/deep-dive/digging-into-apples-icloud-private-relay/.

[Kitamura] E. Kitamura, “Understanding ‘same-site’ and ‘same-origin,’” web.dev, 10-Jun-2020. [Online]. Available: https://web.dev/same-site-same-origin/.

[RFC-7258] S. Farrell and H. Tschofenig, “RFC-7258 BCP-188 Pervasive Monitoring Is an Attack,” IETF, Best Current Practice RFC7258, May 2014 [Online]. Available: https://tools.ietf.org/html/rfc7258. [Accessed: Feb. 03, 2016]

[W3C TAG 2015] M. Nottingham, “Unsanctioned Web Tracking,” W3C, W3C TAG Finding, Jul. 2015 [Online]. Available: https://www.w3.org/2001/tag/doc/unsanctioned-tracking/. [Accessed: Aug. 20, 2021]