You can also tune some labels, like the Title, or the Accept button :
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.
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).
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.
CustomizeI’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.
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.