[Install Time Permissions Prompt] Concerns

[FluorescentHallucinogen]

I'm not sure that Install Time Permissions Prompt could really solve the problem of compulsive denial of permission prompts described in the explainer.

I truly believe that web apps should ask for user permission in context (rather than on page load or install time), then the purpose of the request should be obvious. Lack of understanding of purpose will still lead to denial of permission prompts.

This is where Permission Request Purpose Strings could help.

IMO, quite the opposite, restricting some Web APIs like e.g. Web USB to only installed PWA looks a promising idea. Why would a regular web page on the Internet can ask you permission for such powerful API?

I'm sure the true root of the problem is that permission managing currently is hard and not intuitive for users (please read https://crbug.com/974785 from the beginning to the end).

This concern is amplified by the fact that on the web permissions are persistent.

This is where One-time Permissions could help.

If the permission managing UX is improved (see my proposals in https://crbug.com/974785), then the compulsive denial of permission prompts will no longer be a problem. Users will be able to easily change permissions: easily grant (turn on) the permission if they dismissed (turned off) it once before, and, more importantly (because it's a bigger user privacy issue), easily dismiss (turn off) the permission if they granted (turned on) it once before.

The idea of declaring permissions in the manifest isn't new. See #395, #319, #218, #75, #62, #52, #31, #8 in the https://github.com/w3c/manifest. So @marcoscaceres wrote an interesting "Why manifests and permissions don’t mix" blog post.

Just curious why you believe this idea will be accepted this time?

See also W3C Privacy CG report on Permissions and User Consent. This is a great source of various ideas and concerns.

@b1tr0t @marcoscaceres Thoughts?

I'm not sure that Install Time Permissions Prompt could really solve the problem of compulsive denial of permission prompts described in the explainer.

We have to make a clear distinction between regular websites (such as simple PWAs) and Web Applications. First of all, it should be clear for the end-user that a Web Application is not a regular website and that it may offer much more functionality, so it's why it may be presented as a "whole" package with an install time permissions prompt aggregating all the sensitive information considering the permissions requested to the user.

Because Web Applications are not just regular websites, the "procedure" to install them is not the same as a "compulsive" browsing of the internet, where users happen to quickly change tabs and websites. This is this quick browsing habit that pushes users to compulsive denial of those extra features in regular websites, because they do not feel that it is in their interest to accept them, or that the environment in which they are is secure enough. For them, those prompts are a bit like kinds of annoying popups interfering with the browsing experience, and often appearing without enough clear explanation from the website about why this happens.

So, the compulsive denial of permissions is clearly a sign of an awareness from the users that the browser sandbox is not really a secure environment, as indeed, the browser can also do any kind of wacky network requests or even monitor all their activities with spyware analytics without their consent.

In a Web Application, users expect a more secure and controlled environment and thus are also more inclined to put more focus and awareness into it, so that if they want to use the application, they also have to focus on the permissions that are requested, in their own interest. That's why it makes sense to aggregate all the permissions ahead of time and to request them to the users at install time so that the user can have a clear and global understanding of what the web application can actually do, and on how they can make best use of it.

Related in w3c/webappsec: (#578)

[b1tr0t]

Modern computing platforms are moving away from runtime permissions and towards finer grained, time scoped, runtime permission model. This pattern, and the benefits, are well described in this paper and others in systems research: https://www.usenix.org/legacy/events/webapps11/tech/final_files/webapps11_proceedings.pdf#page=83

However, I do see a benefit to pre-declaring a "high watermark" of permissions needed by an application in the manifest with auto-deny of permissions requested at runtime which exceed the high watermark. This would help us better describe to the user what they should expect from an application in the install UI, act as a countermeasure from an app which has been tampered with asking for access that it shouldn't need, and could be a useful signal for app stores to promote apps that need fewer permissions for less time.

However, I do see a benefit to pre-declaring a "high watermark" of permissions needed by an application in the manifest with auto-deny of permissions requested at runtime which exceed the high watermark. This would help us better describe to the user what they should expect from an application in the install UI, act as a countermeasure from an app which has been tampered with asking for access that it shouldn't need, and could be a useful signal for app stores to promote apps that need fewer permissions for less time.

Yes, and it is particularly relevant for security concerns, such as network policies. The "high watermark" could act as an application blueprint in the case that permissions are dynamically changed or added within the app at runtime. If a network policy is silently changed or added that is not already declared into the blueprint, then an "auto-deny" procedure may be applied by the browser. But this mechanism could also be leveraged by the browser in the case of application updates requested from within the app. In that case, an update permission would be requested to the user. For example, if a network policy changes for a particular application resource, the browser has to figure out how to deal with it: is this a legitimate update to the application or is this a security threat coming from the network ? This high watermark may not necessarily need to be configured in the application manifest though, as the main application document could be leveraged if the security model happens to be defined "client-side" rather than "server-side" (cf whatwg/html #6553), which would be way more secure.

[FluorescentHallucinogen]

For years we were made to believe that asking permission at start is bad practice (anti-pattern), that developer must use context-related runtime permissions:

• Don’t show all permission requests at once.
• Avoid asking for permissions upfront, when the app is first installed.
• Initiate a permission request when the user selects a feature that requires that permission.
• Ask users permissions at a time when the benefit is obvious.
• and so on.

What has changed during this time?

I still believe in this. :)

We have to make a clear distinction between regular websites (such as simple PWAs) and Web Applications.

I believe that separating web sites and web apps in the eyes of users and developers is not a good idea. I'm personally against the Web platform fragmentation.

I love progressive web apps precisely because they are ready to use without installation and can be distributed without app stores. If I like the web app, I can install the icon to home screen to come back to it later again and again (this is equivalent to adding the web site to favorites).

Imagine a big complex PWA, a 3D WebXR WebGPU video game, that uses PRPL pattern to lazy-load levels, objects, textures on demand. To play this game, all it needs is just enter the address in the address bar or found it in the search engine. Each level can be significantly different from the others and require different permissions. User unlocks levels step by step.

I mean, a web app can be made up of few parts. Each part may require different permissions. And all parts may be not simultaneously available at install-time. E.g. super app.

BTW, how does install-time permissions fit in with one-time permissions and time-limited permissions?

If the time-limited permission was requested at install time and the time is over and it was revoked, will it be requested at the next app start time (start-time permissions)?

IMO, some sensitive Web APIs like geolocation, camera, microphone must be one-time permissions (must be prompted every time, because the user may forget that he gave permission earlier). One-time permissions is a special case of time-limited permissions, where time is limited to session.

However, I like the following ideas:

1. Grouping of permission requests. Instead of displaying 3-5 permission request dialogs in a row, one permission request dialog with 3-5 checkboxes/toggles can be displayed. This should improve UX (and solve the problem of compulsive denial of permission prompts). But 2 important things: 1. this is not a "all or nothing" story (e.g. the user should be able to grant access to the microphone, but deny access to geolocation, and be able change geolocation permission later if needed). 2. this permission request dialog with a few permissions can be displayed at any time at runtime, not only at install-time.

2. Allowing some powerful Web APIs like e.g. Web USB to only installed PWA. If the user has installed the app, then he trusts it in some sense.

I believe that separating web sites and web apps in the eyes of users and developers is not a good idea. I'm personally against the Web platform fragmentation.

One didn't use the word "distinction" in a sense of "separation" or "fragmentation", but rather in the sense that one can not treat equally a simple website such as a landing page for a company, a RSS feed reader and a complex web application such as a document editor used in professional environments, in regards to security, privacy and data ownership.

• A company Landing Page would be best accessed via an URL into the browser,
• A RSS Feed Reader would be best accessed as a quick installable PWA,
• A Document Editor would be best accessed as a downloadable Web Bundle for portability and a better sense of native-like application.

Imagine a big complex PWA, a 3D WebXR WebGPU video game, that uses PRPL pattern to lazy-load levels, objects, textures on demand. To play this game, all it needs is just enter the address in the address bar or found it in the search engine.

Yes, to find this game, all the user needs is an URL, but to play the game, I think the user might find that the presence of the browser UI prevents a good experience and immersion into it, though it might be used in fullscreen mode without it being installed as a PWA. The same with the Document Editor: the browser UI prevents a good sense of native-like application, but that problem could be solved if developers had access to native, customizable window controls tags within a frameless display-mode (cf whatwg/html #6549)

how does install-time permissions fit in with one-time permissions and time-limited permissions?

Install-time permissions might be conceived as permissions that are mandatory in order for the application to configure itself, such as application settings necessary for functionality. For example, a Document Editor might write files to a default folder. That default folder is set at install-time, but could also be changed later on by the user if they need to.

It would not be good UX design that the Document Editor asks the user for the permission to write files to disk each time files are modified (one-time permissions) and it would not be very good design either to ask the permission again and again at each end of session (start-time permissions), such as the Filesystem Access API is presently doing in chromium.

Thus, there is somehow a need for an install-time permission, so that the application behavior stays consistent between sessions without prompting the user for permissions that have already been approved and may not need to be changed between sessions. However, and as you said, if it needs to be changed, the user should be able to do so in the application settings (within the app UI), which would then retrigger a new permission request from the browser.

But ideally, and this is even more relevant for Web Applications, there would need to have a seamless experience between the Application UI and the Permission UI, so that the Permission UI could be customizable by the developer. For example, imagine an install-time splashscreen with default settings, that would also, if approved by the user with the click of a button, translate into permission grants from the browser point of view. We would then have to think about a security model that would allow this behavior without compromising the security of the application.

The issue with a PWA is that it is served from an URL and in order to load scripts from within the main document it has to have network access by default. Therefore, a Web Bundle is more secure in that regard, because it already has all the resources "client-side", and we can use it in an offline-mode scenario. The service worker could emulate an offline-mode, but it can also be tampered, because it has network access too, like the main document.

In the context of an "Install Time Permissions UI", we do not want the main document to have network access, so that the Permission UI can not be a security issue for the application. "App stores" or "official websites" could act as a source of truth for the Web Bundled Applications, but then, ultimately, the security model has to be implemented by the developer client-side in the context of an offline-first application.

[FluorescentHallucinogen]

What about using Permissions.request() (that supports requesting multiple permissions at once) instead of declaring permissions in web app manifest?

[FluorescentHallucinogen]

Permissions.request() is also mentioned and required by Time Limited Permissions spec. See https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/TimeLimitedPermissions/Explainer.md#api-proposal.

[aarongustafson]

If the time-limited permission was requested at install time and the time is over and it was revoked, will it be requested at the next app start time (start-time permissions)?

@FluorescentHallucinogen As proposed, time-limited permissions revert to Ask/Prompt once expired. (I wrote that one too.)

Thus, there is somehow a need for an install-time permission, so that the application behavior stays consistent between sessions without prompting the user for permissions that have already been approved and may not need to be changed between sessions. However, and as you said, if it needs to be changed, the user should be able to do so in the application settings (within the app UI), which would then retrigger a new permission request from the browser.

100% this. There is also an effort (I don’t have the link handy) to provide implementation-agnostic links to specific permissions settings so that an app can offer direct references in their own UI (e.g., "change your default folder" takes the user to the Filesystem Access permission for the domain).

What about using Permissions.request() (that supports requesting multiple permissions at once) instead of declaring permissions in web app manifest?

Reading through that proposal, I’m confused: does request() support multiple grants? That was one of the first ideas I considered back when I first wrote this. If we get batch permissions, there is nothing prohibiting an implementor from using that as the plumbing (and UI) for this feature. This approach, however, offers a declarative way of enumerating the permissions without requiring JavaScript. There are some follow-on benefits too:

• Catalogs can read & expose this info to users prior to install (which many catalogs already do for compiled apps)
• Browsers could adjust the display of the site permissions screen to prioritize these permissions.

With runtime requests, neither of those is possible.

However, I do see a benefit to pre-declaring a "high watermark" of permissions needed by an application in the manifest with auto-deny of permissions requested at runtime which exceed the high watermark.

@b1tr0t Could you expand a bit on this idea?