3p access to isLoggedIn

[jameshartig]

Continuation of privacycg/storage-access#8 (comment) and I think this is slightly different than #13.

One problem brought up in the Storage Access proposal is that third-parties don't know when the user is logged in and when it is appropriate to prompt for storage access on click. An example was a video player that doesn't want to show you ads if you're paying but doesn't want to ask for storage access on every "play" action. Additionally, it can be a better user experience to show some logged in state in the iframe instead of needing to always gate/hide content behind a button especially across page navigations.

The problem that Chrome brought up is that the logged in identity can be a huge fingerprinting signal. Since you can only get 1-bit of information from navigator.isLoggedIn() I'm not sure how much that helps fingerprinting but if username or other data is eventually exposed via the API, those can be disallowed in a 3p context. Alternatively, the isLoggedIn state could be partitioned based on the top-level origin. This would solve the problem above where you're logged into a widget but then navigate to a new page or refresh and you're now shown the logged out status again. When the iframe is granted storage access it could check that the user is, in fact, logged in (based on cookies or something else) and update the isLoggedIn state, which would then persist for this partition.

[jameshartig]

@johnwilander @melanierichards should we discuss this and #13 at the f2f?

[melanierichards]

@fastest963 SGTM!

The currently-proposed design for querying isLoggedIn() returns a Boolean, so I think we're all set on that point (not revealing username/metadata to an embedded 3p upon the isLoggedIn() method). Unless it feels useful to raise in discussion just to ratify that yes, that is the behavior we intend going forward.

[arthuredelstein]

If isLoggedIn is not partitioned by first party, then I think it a viable supercookie. You can combine repeated calls to isLoggedIn and setLoggedOut to figure out which of N known usernames have been stored by the User Agent. So partitioning seems critical.

[jameshartig]

If isLoggedIn is not partitioned by first party, then I think it a viable supercookie. You can combine repeated calls to isLoggedIn and setLoggedOut to figure out which of N known usernames have been stored by the User Agent. So partitioning seems critical.

I think this depends on how exactly we solve #4 and #21. If the user has to accept a modal or permission dialog in order to store a non-browser-observable login then they won't be able to actually repeatedly call it reliably. Also, if #21 isn't actually implemented or is not allowed in a 3p context that could prevent this as well.

[davidben]

I think the premise that fingerprinting only comes from the username isn't right. Even the 3p access to the boolean has this problem.

Fundamentally, whatever the requirements are on storing the isLoggedIn bit, the point is to capture the set of sites where the user is "logged in". This is a reasonably large set that varies across users. (Even more so when you consider the second-order incentive this establishes for sites to implement login if they want to persist state.) This set is effectively the user's browsing history, up to a granularity of sites that are "important" to the particular user.

Allowing third-party embeds to query the isLoggedIn bit means that, by embedding cooperating third-parties, you can have each query their bits and combine them into a view of this user-identifying set.