[Proposal] Multi Permissions API

Tags: #<Tag:0x00007fb629e0f740>

Inspired by Oauth2 and GDPR consent screens, but with 2 flavors : short box, long box.

Short box

1

If you click on “Customize”, you get the long box.

You can also call the long box directly.

Long box

Tune labels

You can also tune some labels, like the Title, or the Accept button :

1-2

1-3

1-4

1-5

Allowing Developers to alter the Accept button is OK, because you cannot alter other labels. For example, you cannot switch Accept / Cancel buttons, because you cannot edit the Cancel button label.

This API is expected to greatly simplify Authorizations by allowing web apps to declare their intentions in a single round, reducing friction for both parties (user and webapp), while still being flexible on individual authorizations.

See also

[Proposal] Share User Data API

[Proposal] Show GDPR popup

[Proposal] Multiple permisson request API

Requesting permissions needs to be able to ask for multiple things · Issue #92 · w3c/permissions · GitHub

This was discussed to some extent in the past (for example here or here), but the conversation has not resulted in much progress so far (but for instance audio and video can be asked for in combination now).

1 Like

Is there any technical obstacle that blocked the discussion ?

I don’t think any of the issues were of technical nature. The spec has been making slow progress for other reasons (that I’m not completely aware of).

1 Like

I’m sorry but this is an awful idea. What happens when the user gets redirected onto one of those fake “Prove you aren’t a robot” pages that ask for notifications then spam ads? With this, they get to have the browser chrome (an area assumed safe) say things like

Please prove you aren’t a robot

to-connect.top will be able to send notifications, access your location, and store persistent data.

Customize I’m not a robot Cancel

And most users will blindly click through. Besides, you aren’t supposed to ask for permissions in batches, only as needed.

You just click on cancel.

Yes, but it’s still a mistake to allow site-provided text in the UI like that. What is your use case for asking for many permissions at once anyway?

Web App declares all the permissions it wants to use, just like it would do with OAuth2.

User can refuse, accept, or provide granular consent, according to GDPR.

It is a natural evolution of OAuth2 permissions, but handled 100% in front, by browser, without the complex OAuth2 backend machinery.

For the dev it is super easy to code.

For the user it provides a seamless way to accept in 1 round all permissions the web app declares.

At anytime user can remove consent thanks to the browser.

Permissions should be requested as needed, not all at once.

What is the rationale for this statement ?

The principle of least privilege. If a site doesn’t need my location yet, why should I allow access? Besides, you will (probably) get much higher acceptance rates when the user understands why a permission is needed. If I load an online store and it immediately asks for camera and location I’m going to deny them (breaking features later) but if the store asks for location when I click a “Find stores near me for pickup” button or camera when i open a barcode scanner I’ll allow because it makes sense. See also Android’s move away from install-time permissions.

In that case I invite you to see this proposal the other way around.

In the Multi Permissions API you can refuse, granularly or all at once. Which means you can avoid all these multiple prompts that you would be exposed if they were popped individually. A single click to refuse them all. In the GDPR spirit.

We cannot measure this, because the proposal hasn’t been implemented.

You reason with existing stuff, but the proposal is about creating things that do not exist yet. So we don’t know what approval or refusal rates would be.

It would be a non-scientific approach to shut down a proposal before being able to measure its effects.

Sure but neither you or me can speak for all users. We need to measure.

This proposal is independant from the time you ask.

The Web App can declare its permissions needs at account creation, for example.

It is also possible to split the permissions in multiple fragments, like permissions A + B + C at account creation, and permissions D + E at a later moment.

I really think it makes sense to be able to group some permissions requests together.

It is a possibility that currently the platform does not offer. We don’t have choice.

The art direction lies into the developers. Only them can decide the best moment to show these requests.

Spoof-ability and safety are key metrics of any API addition. The “customizing labels and buttons” is IMO absolutely anti-web. Sites already attempt this ‘prove you are human by allowing notifications’ garbage. It’s highly recognizable to most as just undesired. We don’t need to go allowing the web to embed that behavior into the UX provided by the browser.

Do we need better ways of handling permissions? Absolutely. Should we expand to this level of detail in a multiple request? No. Ideally, sites should ask for permissions as-needed and give the user a reason within their page to support getting it.

There is no technical thing here beyond multiple requests in one box. Which, should be very narrowly scoped (as it has been) and discussed on its own merit. The UX configuration this is calling for is too prone for abuse to end users.

“Just click cancel” is not a good response to spoofing. The web platform has to think of a billion users of varying levels of sophistication. Most are not that sophisticated and click through most things. For now, better give sites more clicks so users hopefully figure out they are asking for too much too soon rather than make it a one-click API dump.

Update

Microsoft announced to work on a kind of multi permissions modal after Install

See at 14"34

I think probably the thing to do is just make the prompts stack, no new APIs needed.