Install Time Permissions Prompt

An increasing number of sensitive APIs have been added to the web platform. To ensure user privacy is protected, these APIs are restricted to secure origins and typically require an explicit user permissions grant in order for the API to be available to a given domain. As web applications have become more advanced, these permissions request prompts have proliferated. This proliferation has led to users having “permissions request fatigue,” the major symptom of which is a compulsive denial permissions prompts, especially if the prompt is non-contextual or if several requests are shown in rapid succession. This situation is problematic for many applications that rely on these sensitive APIs to function (e.g., a video conferencing app not being granted access to the camera and microphone).

As web apps are continuing to evolve, some of the capabilities they need—run on user login, for instance—only make sense when a website is installed as an app (PWA). Additionally, there is some interest in loosening storage restrictions for installed websites to enable experiences like offline media consumption.

All of these considerations point to a need for some form of bulk permission request, which should be provided as part of the installation experience.

Read the Explainer

@slightlyoff mentioned there is some interest in batch permissions requests related to the Permissions API as well, so this would overlap with that work (which I think falls under Web App Security).

You should also contrast and compare to the getUserMedia/etc device permissions API/UI in prior art, and also consider how to minimize the number of different ways the same requests are presented to users. Also discuss why and how this resolves the issues seen in pre-Android-6.

Not sure I follow. Could you expand on this?

How do you mean? In terms of the actual user interface or the overall user experience or both? We have some detail in the Explainer about how permissions requests in the install/first-run experience will interact with permissions that have already been granted or denied as well.

This is covered in the Prior Art section.

Media permission prompts can already ask for multiple permissions at once (audio and video). These are requested typically at the time of usage; Chrome defaults to saving the permissions forever until revoked; Firefox defaults to not saving them unless a positive user action is taken (“Remember this decision”).
This is clearly in the area of ‘prior art’ for this request. There are differences (such as selecting a device, which your proposal doesn’t cover.)

Minimizing the different ways prompts are presented to users basically is: ensure that this proposed UI/API leads to an experience for the user which isn’t disjoint or confusing. (Actual UI is the job of the UA, but the API has to support the right set of options.) For example: the way Chrome remembers permissions unless explicitly revoked (at least for media), but Firefox explicitly doesn’t, and so may prompt-on-use more often. And then there’s the interaction with the OS, which may (on Android) ask if an app is allowed to access media devices (on first use). I.e. I think it needs a more detailed discussion of the issues and options and ways in which permissions are presented to the user, not just this set in a vacuum.

Lastly, you show the pre-android-6 usage, but you just describe it and why it was a problem. You don’t explain why this doesn’t have that same sort of problem, since on the surface you’re instantiating a similar permission flow. (I think I know what the answer would be, but you need to be the one making it.)

Oh interesting. I rarely use websites for conferencing, so I had not noticed this in my own web usage. It’s also interesting to hear that Firefox has implemented a batch permissions request as I was aware that folks at Mozilla had been generally against the idea. I’ll add this to the prior art section.

I think what a UA chooses to do with a permission (in terms of persistence or lack thereof) should be up to each individual UA. This explainer certainly would not be the right pace to define it. Perhaps the W3C PING is?

Totally my mistake, I have another internal document that goes into more detail. I thought I had already included that information and will update the Explainer accordingly.

I have updated the prior art section of the Explainer.