High-level trust signal (requestInstall / requestTrust)?

[kushal]

Based on some of @michaelkleber 's comments in the last meeting, and some of the broader conversations about user permission, I wondered if we could view non-login state and login state as being on a spectrum. In this model, a site first asks to be "installed" or "added to my browser" or "trusted" or "remembered" and then later or simultaneuosly (possibly) can indicate the user is logged in. This is sort of a crazy idea but maybe it will spark some others.

Background

A few concerns have come up with isLoggedIn

1. "Login" doesn't cover all of the cases where a site may want less aggressive state deletion (shopping carts, paywalls, avoiding MFA on subsequent logins)
2. Sites may be motivated to and able to lie if a login flow must not be browser-mediated
3. Sites may force users to create accounts (or install apps) just to persist state, resulting in more tracking
4. If isLoggedIn provides binary information about authentication in third-party contexts, it may be vulnerable to fingerprinting

Some of the above issues are being solved by prompting users, but there is understandable reluctance to confront users with cryptic prompts they may be predisposed to accept without reading.

Idea

However, there is a place where users already grant permission in a way that feels (and is) weighty and provides a conceptual model we can leverage, which is installing an app or browser extension. Although generic and a bit heavy, it sets a gate for sites to do more that doesn't rely on heuristics or purpose-built APIs.

1. A site can display a button asking a user to "install" the site that calls a requestInstall API. This would replace the current PWA concept of adding a site as an pseudo-app, which could be a chekbox option when "install"ing.

2. The resulting prompt for installing a site would be fairly heavy, similar to installing an app, and it could have real estate for browsers to provide additional trust information or warnings.

3. By default, an installed site might have a small number of additional rights

   • Longer cookie duration
   • The right to further prompt the user for permissions that non-installed sites in this new world don't get to ask for (say, notifications)

4. This could be sufficient for most login, paywall meter, "seen this person before", cookie consent, analytics, and shopping cart cases. Sites currently pushing registration upfront could move to pushing anonymous "installs" instead.

Extensions

1. In this model, isLoggedIn might only be for login information that wants to be advertised in a third-party context to know who to prompt for StorageAccess. A site could request to set this bit, and if the login flow is not mediated by the browser, the user could be prompted to allow this permission to be set. Gating the right to even ask for this permission on being "installed" reduces risk of permission spam and fingerprinting, especially when coupled with reminder UIs when this bit is accessed.

2. If the "install" flow truly feels as weighty as installing an extension (possibly including manual review), users could even be subsequently prompted to grant wildcard StorageAccess across the web to trusted sites, just as they effectively can today with browser extensions or URL handlers, but in a better sandbox and with more visibility into when it is accessed.

3. "Installed" sites could also receive the right to ask for more fingerprinting-prone APIs, thereby limiting the surface area over which they can be used for correlation and reducing permission spam.

4. Browsers could automatically "install" sites that a user visits frequently with an "undo" option to reduce the hassle of managing all of this.

5. Browsers could still purge "install" state for unused sites.

6. As part of "install"ing, users could agree to share that permission across a listed first-party set of sites.

7. Users could be prompted to "install" sites as part of logging in to a site. Maybe browser-mediated logins default to also installing the site. This is useful for banks or video services where almost all functionality is login gated anyway.

8. Users could mange a list of "installed" sites in their browser.

9. A user noticing they're on a site that is not installed might be a signal in phishing avoidance.

Concerns

The risk here is that the incentives for being installed are so high that sites push this quite hard and users do not net increase their privacy. The key is for the install barrier to be high enough and for policing by search engines to be strong enough to mitigate this. We saw this happen with native mobile apps, where after an initial rush of user-hostile install prompts, things settled at a low-key equilibrium.

Another risk is that the whole concept of "installing" a site is confusing and possibly antithetical to the web. It could raise the perceived weight of checking out a new website and managing the sites you've been to. Sites would also have to manage when they want to ask to be added to the browser vs being added as a full app.

Maybe "install" is just too overloaded a concept and a browser-mediated "remember me on this site" or "trust this site" or "save this site" that behind the scenes works the same is close enough? This is also discussed in https://github.com/privacycg/is-logged-in/issues/9

Another risk is that if browsers continue to improve isolation between sites, then it would be less necessary to purge first-party state, and then some of this machinery is less useful.

Final thoughts

A lot of challenges arise from trying to prevent lowest common denominator behavior on the web by sites a user visits transiently or are known bad actors while also empowering sites a user has a trusted relationship with. At the same time, we're trying to slice permissions finer while also recognizing that users don't respond well to tons of prompts. It seems like sort of first-aproximation signal from the user of who to trust would be quite valuble for a lot of things.

[eligrey]

I agree that the "install/trust this site" paradigm will make much more sense to both users and implementers than any browser UIs that have been proposed for IsLoggedIn.

This concept seems like it stands a better chance to strike a good balance of providing clear control to users without a significant increase in permission fatigue.

[michaelkleber]

I think this type of signal is worth exploring. However, the Concerns section highlights some key questions to consider.

The fundamental issue is what else a site gets out of the install/trust/whatever signal, either deliberately or de facto. The ability to retail single-site state (which is freely given on the web today) shouldn't be tied to giving the site even stronger capabilities. (My example in https://github.com/privacycg/is-logged-in/issues/9#issuecomment-690492133 is the observation that the common login flows on today's web often give out a cross-site user identifier.)

[annevk]

While I agree with the concerns regarding a login bit, I don't think that installation conveys trust. Just because you want easier access to some game, doesn't mean you have any kind of trust in it. (That only works to some extent in the store computing model and even that is showing cracks.)

[othermaciej]

Sites should not be able to initiate a prompt for this state freely, or it could result in the same kind of permission spam problem that we have seen for notifications. Further, users are not in a position to understand the way in which first-party state can be used for third-party tracking (at times without active cooperation of the first party), which makes this not a good thing to prompt for in general, even if there is some gate.

I do think it's reasonable to give more generous first-party storage limits (both time and space) to sites that the user has installed in an app-like manner, like iOS Homescreen Web Apps or Chrome PWAs.

[AramZS]

I do really like the idea that this operates on a spectrum, there's unknown on one end, 'known' in the middle and isLoggedIn on the other end and perhaps RememberMe or some other states between. But I am very uncomfortable with the idea of asking the user to install websites that are just websites. PWAs and Homescreen Web Apps have this flow for very specific reasons and to be honest even those flows I am not a huge fan of because of how they jumble the concepts of apps and websites and therefore make unclear the boundaries between the web and the device. This feels like an unsafe flow to be training users to work within and I'd prefer not to look at it as a practice to extend beyond the specific needs of those systems.

I appreciate your outlining of concerns, the problem of the incentives being high is a big one and I also feel the "antithetical to the web" problem is a big one. I'm having trouble imagining a web where all sites ask to install themselves in that way. The closest I'm getting is the 'open in app' prompt and that is already on a lot of sites and already a pretty bad UI.

I am inclined, as a result, to look at how to address this great idea of a spectrum of recognized-user state, but to do so with something that requires a lot less user interaction. I think if we go down the road of websites "installing" themselves, we end up in a worse place.

Also I'm not sure how effective the "install" prompt would be at making users think. There's a long history of spammy browser bars and malicious extensions that were capable of making and passing that bar, much to the detriment of users.

[kushal]

@AramZS All very fair—the thing I'm stuck on is this:

1. Yes, ideally we could decide on state preservation without user interaction (or forcing a login), but the current mix of heuristics is already quite confusing and subject to false positive and false negatives. Although proposals like 'known' are great they don't solve the general problem (and I'd argue having several different state management APIs for various cases could get confusing for developers).

2. Yes, we don't really want to prompt users or rely on them to make the right decisions, but if it's our only option there is one place where, even if totally imperfect, we've been willing to tie substantial privileges to a prompt and think we've trained users a little bit, and that is "installation."

Do you have ideas for other ways to stake out other points on the spectrum? Proposals like https://github.com/privacycg/is-logged-in/issues/9#issuecomment-690492133 also seem reliant on prompting the user in some way, although maybe simple "remember me" could be layered into existing cookie consent dialogs.

[kushal]

I think this issue is probably ready to close, although maybe the discussion around a more simple "remember me" from isLoggedIn should be pulled into a proposal?

As an aside I ran across this on the web payments blog today :)

Within the Web Payments Working Group we have been discussing a vision where payment apps are “first-class objects” in the browser, easily registered and managed via browser settings. We face an important question: “Will users want to register payment apps explicitly or will that create too much friction?” It has been argued that users are familiar with the ceremony of downloading and installing apps from an app store. If we adopt a similar approach for payment app registration, this might help increase the user’s understanding of which powers to grant to the payment app.

[erik-anderson]

Hi @kushal! We see that this proposal hasn't been touched in a while. Is there anything more to discuss here or should we close this out?