Support "Remember me" functionality

[johnwilander]

This issue was ported from WebKit/explainers#38.

Many websites have an option to remember certain things, typically the username, even after the user logs out (whether explicitly or via timeout). If setLoggedOut immediately clears all first party state (does it? this isn't really explained in the explainer yet), then these features likely can't work. Do we need a provision for them?

[melanierichards]

A couple different topics to discuss under this umbrella:

The motivating use case for "remember me" functionality

…is something like a bank website. These might have very aggressive logout practices for the user's financial security, but want certain data on a longer term. For example, they might want to provide a smoother user experience on subsequent logins by remembering the device and not requiring additional trust signals like 2FA and CAPTCHA completion.

IsLoggedIn could potentially support this by taking a "remember me" parameter that is stored on the device after IsLoggedOut is called (but could be cleared by the user). Once the website next sets IsLoggedIn, the browser could pass along the "remember me" bit, and the website can bypass 2FA etc.

Is this a use case we should support?

Related, should IsLoggedIn support storage of username metadata even when other local data is cleared, for a true "remember me" user flow (e.g. website can prefill the username field in a login form)? User consent mechanisms for this?

Hiding vs clearing website data in logged out state

At a broader meta point, should it be possible to hide website data on logged out state, rather than completely clear it, such that data can be restored at the next logged-in state? Should we consider this within the scope of IsLoggedIn?

[gffletch]

Left this comment on another issue... but it's relevant here:)

Not sure this is the best place to leave this comment... but a key aspect of identity flows on the web is for the identity provider to write a cookie into the browser on the fully qualified IDP domain (e.g. login.idp.example) that identifies that George has logged in from this browser. Consider this a trust token to improve the experience when George comes back and wants to login again.

Consider the "untrusted" experience when you go to a new coffee shop, open your browser, clear all your cookies and try and log into Google. You will likely be asked for more than just your password because of the "untrusted" nature of the login.

From an identity perspective, it is super important to be able to persist the "trust" token across logins/logouts. It's unclear to me how this is managed with the isLoggedIn proposal.

[AramZS]

I would like some sort of isKnown state, outside of isLoggedIn. That would also be useful for handling use cases like metered paywalls.

[melanierichards]

Seems like Trust Tokens might be a better fit for some of these use cases, but we can discuss on the call shortly!

[AramZS]

I think Trust Tokens are still intended to handle users as in or out of a log in state no? The goal is to handle the state between "totally unknown to the site" and "logged in to the site"

[AramZS]

After the discussion on the meeting, I think my comment needs to be a separate issue or perhaps a separate proposal as it is interested in addressing a very different use case.

[michaelkleber]

The way web login works today, it very often results in some amount of cross-site information leakage — either due to giving out a global email address, ot due to a federated identity provider learning what site you visit and maybe giving the relying party access to some global information about you. (I acknowledge that this doesn't have to be the case, but it usually is today.)

Pushing sites to make people log in, when the sites actually only need to remember single-domain information about them, seems to me to push things the wrong direction.

I think there is merit to the browser asking "Do you really want this site to remember stuff about your previous visits?", and perhaps hiding old data, rather than deleting it, until such a hurdle is cleared. And maybe if a user is (or perhaps was) logged in, then we can presume we know the answer to that question is "Yes".

But the state "recognized while on this site, but not logged in" is valuable for sites, and I believe it's better for privacy than conflating the two.

[gffletch]

Whether a site chooses to require sign-in or not seems out of scope for the decision here. In federated identity cases (at least with protocols like OpenID Connect) the information shared between the IDP and the Relying Party (RP) is clearly exposed to the user and the user can choose not to login and therefore not share that information with the RP. Many site activities actively require a login (e.g. reading mail, leaving a comment on a news story, storing personal information at the relying party, etc).

Note that when it comes to user experience and security of the user's identity across the web, it is actually very helpful to "track" the user in a way that allows the identity provider (whether local to the RP or federated) to separate malicious attempts to login to an account from real attempts to login to the account. If there is no state, then every attempt must be considered as unknown and hence require additional challenges to get the user logged in. I don't think this is the web we want. I believe most users are perfectly comfortable from a privacy perspective letting the IDP know things about their devices and activity in exchange for improving the UX and increasing the security of the identity online. The key here is that this information should only be used for these purposes.

Finally, if the long-term goal it to keep federated identity providers from knowing which relying parties the user is visiting, integrating with the self-sovereign-identity flows and making the browser a valid wallet/agent on behalf of the user would solve that problem.

[michaelkleber]

@gffletch If a site's ability to remember something about a user for (say) more than 24hrs is predicated on that user logging in, then it will incentivize many more sites to request login, and cause many sites' functionality to degrade if they don't get it.

I'm all in favor of making the web better for IDPs, and for the people and the RPs who make use of them! And I very much agree that a login flow should be able to know and expose whether or not this person has logged into this site in the past, ideally in a cryptographically robust way.

But putting websites in a position of "get login or else your UX degrades after N hours/days" promotes lots of login in places that shouldn't really need it, and this has a cost.

[gffletch]

@michaelkleber I get the intent of wanting sites to not require login when it's not needed... though as can be seen by sites like Wired, login is becoming required for Wired to meet its business requirements; content isn't free to produce:) Are you suggesting the browsers somehow enforce whether a site can request the user to login or not?

As for cost to the user, there is a potential privacy cost (shared global identifiers) as well as a usability cost (user can't access the content they want because they have to keep logging in). If the user can stay logged in for long periods of time, then their experience is optimized for what the user wants (from a functionality perspective). Whether their privacy is abused is a function of how the site treats their PII. I worry that in trying to protect the user's privacy we may be ruining their experience across the web.

This is where I'd love to see browsers focus on understanding the site's privacy policy and make that data known to the user in a consumable way from which the user can make a much more educated choice as to whether they want to interact with the site at all.

[michaelkleber]

Yup, I get it. My goal is to let sites meet their business requirements without any cross-site tracking — this is what proposals like FLoC and TURTLEDOVE-and-friends are all about.

Returning to the point of this Issue, I think that a "Remember me" capability is a good idea, but having a prior login action as a prerequisite is unintentionally privacy-harmful.

[johnwilander]

Returning to the point of this Issue, I think that a "Remember me" capability is a good idea, but having a prior login action as a prerequisite is unintentionally privacy-harmful.

Are you still talking about a remember-me-for-the-purposes-of-login or a more general remember-this-browser function similar to what Aram just filed in privacycg/proposals#20.

[samuelweiler]

Back to the question of "Do we need a provision for 'remember me'?"...

I understood the point of isLoggedIn to be the expiry of state, which is part of why I asked why it needs to be an exposed signal. That use case seems like it demands expiring everything. I don't think I've heard a use case for "semi-expiring" site data - to force someone into the "semi-logged-in" state envisioned in this issue. Maybe I'm just misunderstanding the whole here?

[AramZS]

@johnwilander Thanks for tagging me back in! Yeah, I think the best answer to the question of

But the state "recognized while on this site, but not logged in" is valuable for sites, and I believe it's better for privacy than conflating the two.

is indeed something like the isKnown concept I have in that issue. My intent is that it solve exactly this problem, a way to understand a user as known to the site without requiring them to log in or end up hitting paywalls on first view, which would be worse for privacy overall and for a healthy web.

I also understand the idea here of is Remembered and my intent is not to argue against it here, though I see @michaelkleber's point, but just to separate that interest from this one, as I think it is a significantly different use case.

[michaelkleber]

@johnwilander Way back at the top of the Issue, @melanierichards wrote:

At a broader meta point, should it be possible to hide website data on logged out state, rather than completely clear it, such that data can be restored at the next logged-in state? Should we consider this within the scope of IsLoggedIn?

I think a flow of hiding data, and then restoring it when the user gives a signal to do so, is a good idea. But I think being logged in is too strong a requirement for this behavior — a user should directly be able to say "I want my old state back" without also probably saying "...and I'll give you a cross-site identifier to prove it".

I also think willingness to retain/expose a small amount of data, as in @AramZS's #20, has merit, but it seems like a different issue to me.

[ajknox]

I think "RememberMe" is the real proposal, and some of the confusion here stems from the fact that logging in is often not a good proxy for a user expecting persistent state. It may be better to rename the entire proposal "ExpectsPersistentState" since that appears to be the actual goal. Melanie's example with forced bank logouts becomes more transparent (the bank logged you out but you still expect persistent state), and Aram's and Michael's points about the login itself being a tacking vector are also addressed if there are good ways to set the flag that don't require a login.

In this phrasing, logging in is a signal that a user expects as persistent state and could be used to set the flag, but expecting a persistent state is no longer conflated with the elevated permissions associated with being logged in.

[johnwilander]

I think "RememberMe" is the real proposal, and some of the confusion here stems from the fact that logging in is often not a good proxy for a user expecting persistent state. It may be better to rename the entire proposal "ExpectsPersistentState" since that appears to be the actual goal.

We have mentioned several other goals of this proposal and they are very much around formalizing the state of being logged in and logged out.

[michaelkleber]

We have mentioned several other goals of this proposal and they are very much around formalizing the state of being logged in and logged out.

Indeed. That makes a compelling case for why RememberMe and IsLoggedIn should be two different ideas. And likely being LoggedIn is stronger, in that once you are LoggedIn the browser can assume you want RememberMe.

(And @kushal's privacycg/proposals#21 essentially proposes that they are two different points on a spectrum, and we should figure out what else is on that spectrum along with them.)

[johnwilander]

Indeed. That makes a compelling case for why RememberMe and IsLoggedIn should be two different ideas. And likely being LoggedIn is stronger, in that once you are LoggedIn the browser can assume you want RememberMe.

Are you thinking a separate spec for RememberMe/RememberDevice and then potentially have browsers set policies on it such as "Must have had IsLoggedIn set at least previously to allow RememberDevice" or "Must have Engagement Index higher than X to allow RememberDevice"?

[ajknox]

I think "RememberMe" is the real proposal, and some of the confusion here stems from the fact that logging in is often not a good proxy for a user expecting persistent state. It may be better to rename the entire proposal "ExpectsPersistentState" since that appears to be the actual goal.

We have mentioned several other goals of this proposal and they are very much around formalizing the state of being logged in and logged out.

What are they? I feel like I'm going a lot of digging and guessing to uncover the goals, and still don't understand how they relate to the state of being logged in/out.

I see in Why Do Browsers Need to Know an assertion that persisting state indefinitely is privacy risk, which is plausible in the sense that persisting things indefinitely is basically always a security risk, but deserves more articulation and evidence to show how that goes from security risk. It's not at all obvious why being logged in is the only interaction that deserve longer persistence; Melanie has pointed out one very clean example with persisting past login history without logged in state. It's also clear there are benefits to having persistence across sessions without logging in. Aram and Michael also show there might be privacy harms associated with marrying cross-session persistence to logging in.

There's also a point about storage space. I'm not an expert on the various types of storage, but cookies specifically are usually tiny - anecdotally I just checked my work and home computer and each has far less than 1 MB of cookies despite years of use and never clearing my history. Space saving can not be an argument for clearing out cookies.

There's one last hand wave that there might be other bits of functionality, like Melanie's suggestion of a dashboard allowing users to manage their logins in #15, which would benefit from but not require IsLoggedIn and does not appear to be a primary motivation.

Succinctly: while it is obvious that a login usually means a user wants state persisted, it is not obvious requiring users to log in to persist state is beneficial. Expectation of persistence and logged in state are not the same thing.

[othermaciej]

It seems like a lot of the discussion here is about a different concept of "remember me" than what the OP was talking about. When I originally filed the issue that was manually imported as this issue, it was about the "remember me" checkbox found on many login forms. This notion of "remember me" is intrinsically tied to login, and would face special challenges if the logout part of this API wiped all client-side state. Other notions of "remember me" which are unrelated to login or which are not otherwise tied to the "remember me" checkbox on login forms should be discussed in a different issue or perhaps should become their own proposal.