search

WebKit / explainers

Explainers from WebKit contributors
374 stars 29 forks source link

Consider other makers for long term storage limitations #46

Closed lbdvt closed 4 years ago

lbdvt commented 4 years ago

Hi,

It seems to me that the binary status IsLoggedIn yes/no does not accommodate for all user expectations.

A user using a site every other week may want for this site to remember her preferences. But she may not want to be signed-in to this site to do so, from a UX and/or privacy standpoint.

Should different markers than "IsLoggedIn" be considered to set limits on long term storage?

johnwilander commented 4 years ago

Hi and thanks for filing! I'm hesitant to port this issue to https://github.com/privacycg/is-logged-in/ since it seems to be for other storage use cases than ones tied to logins. I do understand that there are cases where the user wants to maintain state for a long time and that there's no hard connection to a login. However, IsLoggedIn is explicitly about logins and so you're issue is about, as you say, "other makers" than IsLoggedIn that would also allow for longterm storage in a browser. I believe there is a Storage Permission proposal that could serve this purpose.

lbdvt commented 4 years ago

Hi, thank you for your answer!

I guess it depends on the purpose of the proposal. If the purpose is to provide "an API called IsLoggedIn with which websites can inform the web browser of the user's login state", as stated in the intro, then indeed my issue is out of the topic.

If the purpose is also to define first-party storage duration based on login state ("Long term storage should instead be tied to where the user is truly logged in." or as discussed in https://github.com/privacycg/is-logged-in/issues/15), then I do think that a discussion on "What's the user expectations in term of browser's side storage duration?" is required.

lbdvt commented 4 years ago

Closing this issue as this is now discussed in https://github.com/privacycg/is-logged-in/issues/14