28 Jul 2019

The new browser consensus and SSO

(Update 24 Sep 2019: add link to IsLoggedIn. Update 20 Sep 2019: copy edit. Update 14 Aug 2019: Add link to Safari’s policy)

(Disclaimer: I work for Mozilla. Not speaking for Mozilla here.)

The first result of the browser privacy trend is a growing difference between how the browser treats two kinds of third-party data collection.

  • third-party data collection that happens when the user chooses to use information from one site on another site

  • third-party data collection that happens when a site or service, without an action from the user, tries to use information about the user’s actions from one site while they’re using another site.

Any third party interaction that the user knows about is supposed to keep working. But hidden tracking pixels, scripts and any technology that tries to implement tracking without user interaction are all supposed to stop working.

Protections to implement this are still in progress, but this clearly the direction Safari, Firefox, and now Microsoft Edge are going. We now have the same kind of rough consensus on user expectations about tracking that we developed pretty early on in the email spam situation. This consensus is based on extensive user research. (Why browsers took so long to listen to people about what they find creepy is another story.)

An example of a protection step that’s common across browsers is the the Storage Access API. This gives browsers a way to allow third-party scripts to use cookies and LocalStorage, but only if the user takes action. Apple Safari, Mozilla Firefox, and Microsoft Edge are all involved. (hashtag #worldsFriendliestBrowserWar)

The WebKit Tracking Prevention Policy used by Apple Safari, says

Merely hovering over, muting, pausing, or closing a given piece of content does not constitute an intention to interact.

and

We consider certain user actions, such as logging in to multiple first party websites or apps using the same account, to be implied consent to identifying the user as having the same identity in these multiple places. However, such logins should require a user action and be noticeable by the user, not be invisible or hidden.

The Mozilla anti-tracking policy is similar.

For sites, what this means is that SSO and registration walls are relatively safe. If the user is clearly presented with “Sign in with (identity provider brand)” and there is a button the user has to click the first time they go to the site, that SSO system should keep working. The user knows that they’re using it, and clicked the logo of the provider they “sign in with.” A proposed API, IsLoggedIn, from Apple Safari developer John Wilander, would make it easy for a site to check logged-in status from JavaScript.

If the user can’t see the way that multiple sites are trying to use the same information about them, then that flow of data across sites is likely to get blocked, whatever the technical implementation is. This is likely to be good for the relative market power of sites that people trust more, if it turns out that people are more willing to “sign in with” (and obviously share info about themselves) on their trusted sites than on a random site that their uncle sent them a link to.

More on this: Will ITP and ETP kill traffic arbitrage?

 

#