Re: [w3c/manifest] beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app (#835)

> > Those permissions aren't used as a signal to allow other features ... In general, we don't think asking persistent permissions upfront in a manner disassociated with the relevant user actions is a good model for security or privacy sensitive features because there is a risk for users to tap through prompts without fully understanding the implications, the users may not remember what permissions they've previously granted to a given website, and it may not be clear for users to revoke such permissions later.
> 
> Installation as a sole signal to allow other features is not considered good practice in Chromium either (see https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/permissions-for-powerful-web-platform-features.md), and we are trying to move towards a model where persistency of permissions is the key differentiator of installation (since installing is an explicit act of persistence by the user). Permissions in tabs would move towards being ephemeral only.

I'm not sure how or why this commentary of what Chromium does or intend to do in the future is relevant to my earlier comment but okay.

> > , and there is a clear connection between what the user is trying to do (e.g. join a video conference) to what the permission is asking (e.g. access to camera).
> 
> This would be entirely under the control of the web content right?

And that is precisely why we want to limit & reduce the number of such permission prompts as much as possible. Any new prompt that depend on web content requires a substantial burden of proof to be added. Accessing a camera, for example, is inherently tied to what the website offers (e.g. video conference) and the current state of what the website is trying to do (e.g. are you in a chat room vs. shoping page). Saving a website to home screen doesn't come off as something that's required to be initiated within the website due to its dependency on a specific functionality or a state of a given website. Having a dedicated UI in the browser to do that (as Chrome & Safari both already offer) would be a better fit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/835#issuecomment-563620065