Should we standardize how we expect browsers to use this signal?

[englehardt]

Our discussion on the teleconference today makes me wonder whether we should try to standardize the isLoggedIn "signal" independent of how browsers plan to use the signal. The questions from Ben show that there are a lot of different ways we could imagine using the signal, and I don't think we're aligned.

A couple of the possible applications we discussed today:

• Long-term access to client-side storage (in the first-party context)
• Access to certain powerful browser APIs

FWIW I also brought this question up on a previous call and John shared that he'd like to keep the API small in scope.

[melanierichards]

For the purposes of discussion, possible uses of the IsLoggedIn signal fall into a few larger buckets:

• Empowerment of sites where the user has a logged-in relationship (e.g. relaxing scoping restrictions with Storage Access API)
• Restrictions on sites where the user does not have that relationship (e.g. automatic or user-managed clearance of longterm client-side storage or permissions)
• Enablement of helpful user experiences in the browser/UA, using logged-in signal (e.g. dashboard of "here's where you're logged in")

Discussion should help drive which of these buckets are reasonable applications of the IsLoggedIn signal, and how precise we need/want to be about expected use of the signal vs. UA innovation.

What will have bearing on this conversation is strength of the IsLoggedIn signal, and so #17 is relevant to this discussion.

[samuelweiler]

This seems related to #14, where I suggest that there is benefit to doing things (e.g. setting state lifetimes) based on the same parameters that would "protect" the IsLoggedIn signal, even if the "signal" itself is not exposed.

[ajknox]

It is not possible to have a meaningful discussion about the costs and benefits of a signal without talking about how it will be used. There is considerable risk of building the wrong thing when the conversation starts with a solution without specifying a specific problem it is solving.

Empower Logged In Sites / Restrictions of Other Sites

AFAICT this is two says of saying the same thing, that it allows browsers to divvy up all web interactions into two categories, account based vs. not, and that they will give preferential treatment to the former. This is even more loaded language than the previous discussion about "managed" vs. "mediated", if this conversation continues it may be helpful to look for language with less connotation to capture this idea.

If there are specific reasons why the scoping restrictions on the Storage Access API are specifically onerous for sites where the user has an account or expects persistent state, it would be great to see those articulated. Similarly, if there is a specific reason and benefit for more clearing of longterm storage, that should be the topic of discussion.

Helpful User Experiences

You could probably implement the "Login Dashboard" without a login flag by using the same tricks and hooks third party password managers already use. It would be easier with a browser-mediated login, but you don't actually need the IsLoggedIn API to do this. This might be a nice user experience but it doesn't seem like an urgent problem, or to require standardization to succeed (this could be a differentiating feature for a browser).

One of the most helpful user experiences that could be enabled by browser-mediated logins is default support for PAKEs. This is super nifty, solves real ongoing problems (e.g. people reuse their passwords), and may work better if it's mediated by the browser. It also doesn't really require the IsLoggedIn API.

These are fine security features, but don't depend on IsLoggedIn, and the dashboard doesn't require standardization.

Focus on Concrete Costs and Benefits

I'm sure people are familiar with "You Ain't Gonna Need It" - it's often true in development generally that if you built some method, hook, or bit of infra because you anticipate you are going to need it, it often turns out that you didn't quite need the thing you thought or found a totally different way to solve it by the time you actually use it.

John referred to two issues in the meeting two weeks ago when we were talking about this: "bounce tracking" and "first party tracking".

While I am personally unconvinced that the benefits outweigh the costs for trying to make it impossible to follow navigation through a click, it does make sense that if you want to to explore this area that bounce tracking is on the table for discussion for that topic along with cookies, link decoration, and all the others. I don't see the connection to logged in state, except very indirectly by way of the argument above that it might lead to more state clearing. If this is the motivation, it would be great to see that called out specifically, so this can be compared to any proposals that address the same motivation more directly.

The argument against "first party tracking" is quite novel. I have a hard time distinguishing "tracking" from "navigation" in a first party context - the idea that a session with multiple interactions can have state seems like a pretty fundamental bit of utility. I suspect that is not what we are talking about. As discussed in issue #9 , the real point seems to be the idea that users don't always expect state to persist across sessions. As I warned in the same interchange, this is very different than what we normally talk about when discussing privacy and tracking. Indeed, almost all previous proposals specifically call out "third party tracking". Even conversations about fingerprinting, which does impact first party relationships, usually phrase their harm in terms of comparability across parties. The engineers and researchers working in this field have spent a lot of time understanding how privacy and cross-party relationships interact, and therefore you have a higher chance that type of criticism or support is more likely to be of high quality and to have considered more implications. That's not an argument against exploring this idea, only to move more cautiously because the consequences will be harder to predict. Reducing scope with how first party interactions occur also has much higher risk for catastrophic breakage, and the trade-offs threaten to strike deeper into disrupting core functionality that users and developers expect.

There are also real potential economic harms. If aggressively clearing state between sessions leads to consumers having a harder time with shopping experiences leading to more cart abandonment, that's a dead weight economic loss. Consumers want to buy the thing, businesses want to sell the thing, and friction is leading to worse outcomes for both.

The conversation will be much more productive if it starts with a specific use case and articulation of the problem it's meant to address. As is, this looks like a stepping stone towards intermediating user to business relationships on the open web, without a clear privacy benefit.

[jwrosewell]

Following request at F2F meeting to move questions to GitHub to use time more efficiently I'm making this observation here as advised.

If frequency of visit to a web site is used as an indicator of the trustworthiness then this will favour sites that are bigger, well known to the user in advance, or provided by default by the browser vendor.

New or smaller sites being visited for the first time will be need to build trust with users. If they are impaired from providing the same experience as the bigger, well known, default bundled website then they will be less able to compete with them.

If they need to drive people to register and login then more personal information will be capture more often which goes against the goals of the group. Further the need to register and then login will create friction which might discourage people from interacting with the site.

[qualitybydesign]

At the May 19, 2021 F2F, @johnwilander commented on the use of this signal saying (as quoted from the meeting notes)

if you created an account and logged in, maybe we don’t need to prompt as often or block the site from using powerful APIs that might be sensitive. Might unlock power to the web for future things, not necessarily just gating existing APIs.

I would be careful not to conflate login with trust, especially as the end of third party cookies drives more sites to require login. Just because a site forces me to log on, and the browser can detect I went through an authentication flow, doesn't mean I want to make it easier for it to track me.