The IsLoggedIn API - Githubissues

johnwilander commented 4 years ago

We'd like to work on our proposed IsLoggedIn API in this community group. The API allows websites to inform the web browser of the user's login state.

Currently, web browsers have no way of knowing if the user is logged in to a particular website. Neither the existence of cookies nor frequent/recent user interaction can serve that purpose since most users have cookies for and interact with plenty of websites they are not logged in to.

Why do browsers need to know, you may ask.

The current behavior of the web is “logged in by default,” meaning as soon as the browser loads a webpage, that page can store data such as cookies virtually forever on the device. That is a serious privacy issue. Long term storage should instead be tied to where the user is truly logged in.

There could be other powerful features and relaxations of restrictions besides storage that the web browser only wants to offer to websites where the user is logged in.

The ability to do these things requires knowledge of where the user is logged in.

Full explainer, open issues we'd like to discuss, and a summary of previous feedback is found here: https://github.com/WebKit/explainers/blob/main/IsLoggedIn/README.md

Edit: Updated the link.

annevk commented 4 years ago

Could this be harmonized with https://w3c.github.io/webappsec-credential-management/ somehow? I believe everyone bought into that already at least for WebAuthn purposes. To keep things relatively straightforward for web developers we should probably not have too many different credential endpoints.

I'm also a little skeptical of the HTTP State Token dependency. I'd rather iterate on cookies. (For similar reasons.)

othermaciej commented 4 years ago

A goal here is maximum ease of adoption. If the dependency on Credential Management doesn't make this any harder to adopt, then sure, but I'm not sure it would. (Maybe it can be an optional dependency.) Unless many sites adopt this, the signal of logged in state will become useless.

I think Credential Management API only has buy-in exactly for the minimum needed for WebAuthentication, and not really for any of the password credentials stuff. In any case, having to opt in to a browser based credential chooser is probably a significant barrier to entry. On top of that, the Credential Management API doesn't tell the browser when a site performs a login or logout action. Only when it gets credentials or stores credentials. That doesn't really align with the concepts of interest here.

(The HTTP State Token dependency is optional, but since state tokens haven't advanced a whole lot, maybe better to consider adding it at a later time.

samuelweiler commented 4 years ago

I'm continuing the discussion in the WebKit repo, as I understood @johnwilander to request: https://github.com/WebKit/explainers/issues/44

LALeVasseur commented 4 years ago

From a Me2B perspective, this requires that the individual is first logged in--i.e. in a Me2B relationship--with the browser app.

Having a Me2B Relationship is memorialized through the creation of an account which is, importantly, accompanied with a legal agreement--TOS/TOU or similar.

We draw a distinction between:

a windowshopping state where the individual has a reasonable expectation of anonymity; this state is characterized by the individual not being logged in [and not wishing to be remembered].
and the Me2B Relationship state where the individual has voluntarily entered into a contract with the vendor and wishes to be recognized/remembered/responded to (https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/topics-and-advance-readings/functional-identity-primer.md).

The individual can choose to behave in a windowshopping state even if they have a Me2B Relationship (i.e. an account/credentials).

michael-oneill commented 4 years ago

It would be nice if there was also an associated ability for the user to log-out. If they see a site they are deemed by the site to be logged-in to, they might want to be deemed as having logged out.

johnwilander commented 4 years ago

It would be nice if there was also an associated ability for the user to log-out. If they see a site they are deemed by the site to be logged-in to, they might want to be deemed as having logged out.

See navigator.setLoggedOut(optionalUsername) in the explainer. That is for the site to log the user out. The browser cannot log the user out in the general case beyond deleting all website data for the site.

Note that IsLoggedIn is not for logging in or logging out. It's for the site to tell the browser the user has already logged in or already logged out. IsLoggedIn doesn't manage logins or logouts. It's for sites to tell the browser that they have managed a login or a logout.

pwnall commented 3 years ago

A few engineers from Google would like to discuss the ideas in this explainer. We would like to see the explainer move to a venue suitable for multi-vendor collaboration, such as this community group.

To be clear, this is not a commitment to implement from Chrome. We are seeking a venue to discuss the ideas in this explainer.

Thank you very much for your consideration!

hober commented 3 years ago

We have consensus among the @privacycg/chairs and @johnwilander (as required by our charter) to adopt this as a Work Item, with @johnwilander and @melanierichards as Editors. I'll spin up a repository for this Work Item soon.

hober commented 3 years ago

Closing, as this is now a Work Item.

privacycg / proposals

The IsLoggedIn API #16