Comments (5)
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.
from is-logged-in.
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.
from is-logged-in.
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.
from is-logged-in.
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.
from is-logged-in.
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.
from is-logged-in.
Related Issues (20)
- Use the term bucket for storage HOT 1
- Support for logins to sites requiring 2FA login
- What does logout mean in a federated context? HOT 5
- Browser rules for a 'proper' login flow
- Support for federated logins, or the ability to transfer IsLoggedIn HOT 10
- Supporting display name and avoiding misuse of them HOT 1
- Logging-in does not necessarily mean giving tracking consent
- Safari implementation of setLoggedIn API HOT 1
- Concurrent logins support for `navigator.isLoggedIn` method.
- Would it be possible to have it isomorphic?
- Potential use of First Party Sets for Single Sign-On
- Integration with FedCM (formerly WebID) HOT 9
- Potential requirement to have JS turned on to log in users to a site
- Consider changing the name of the spec to better convey purpose, align with conventions HOT 1
- Consider renaming API entry points to align with conventions, better convey purpose
- Use Case: Updating OS-integrated surfaces HOT 3
- advice/hooks for other login helper APIs to change login status
- Should FedCM use the Login Status API? HOT 6
- Replaced by FedCM login-status API? HOT 3
- Status of specification?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from is-logged-in.