Better ensure path-of-least-resistance is a defensive usage rather than an insecure usage?

[laughinghan]

(Cross-post of privacycg/storage-access#8 (comment) — if that's not ok, let me know)

I think IsLoggedIn is a good idea overall, but one very minor concern I have is that it's a little easier to use it in a way that could be abused, than it is to use it in a defensive way.

Specifically, it's easy to write the 3P iframe script to check if isLoggedIn() and communicate it to the 1P without anyone validating that this 1P is someone the 3P wants to communicate with. And if a lot of sites have 3P iframe scripts lacking validation, they could be collected into a fingerprint. This validation is potentially something that the 3P iframe script has to go out of its way to do, which is bad because ideally, the path of least resistance ought to also be the most likely secure one.

It could turn out that this isn't an issue in practice—maybe 3P iframe scripts will usually require an API token from the 1P; or maybe 3P iframe scripts usually won't communicate logged-in status to the 1P in the first place, they just show or don't show a Log In button, and the only indication of whether login was one-click or required a popup is the delay from mouseenter over the iframe to successful login being reported to the 1P (which, due to user interaction requirement, couldn't be realistically collected into a fingerprint).

I don't have any particularly clever ideas for how to address my concern. The obvious idea that occurs to me is to add a required argument to navigator.setLoggedIn(), domains, which would be a space-delimited list of domains, or '*dangerous-allow-any*'. Empty string '' or undefined would be an error. Documentation would advise that if you use '*dangerous-allow-any*', you need to do your own validation of the 1P like checking an API token or ensuring that information from navigator.isLoggedIn() doesn't leak out of the iframe, lest you be unwittingly roped into a tracker's fingerprint (you could even threaten to add such unsafe 3P iframe scripts to a browser block list, to include an element of self-interest).

(I initially thought of just '*' to allow any domain, but I think having the word dangerous in the keyword is important because it's likely to be used in tutorials for expediency, and while '*' can be glossed over, '*dangerous-allow-any*' will demand explanation.)

If there are better ideas, I'd love to hear them?

[johnwilander]

This has now been ported to the W3C repo. Please continue the discussion there.