An origin trial for a new HTML <permission> element (2024)

> The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it.

I don’t understand this proposal enough to have an opinion yet, but that sure is an interesting way to say both Firefox and WebKit oppose it.

https://github.com/mozilla/standards-positions/issues/908#is...

https://github.com/WebKit/standards-positions/issues/270#iss...

At face value this seems reasonable, but (and this might just be me) because its being pushed by Google I have to ask myself: what's in it for Google, and what am I missing?

Manifest 3 for example breaks adblockers for the sake of 'security', and adverts are Google's business. Passkeys are pushed for security as well (and do have benefits) but for the average person locks you into a eco-system; another business model plus for Google.

So with that in mind, how does this benefit Google at the expense of the user? Making the permissions less explicit, or less separate from the content of a site might be a net benefit to Google... I don't know.

I might also be reading way too much into motivations, and/or paranoid.

I fear we're regressing.

There is a concept in browser UX design called the "line of death"[1] - the delineation between trusted browser UX and untrusted website UX. Unfortunately, because it looks ugly, every new year of visual designers further weaken its guarantees.

Here's an interesting anecdote from an earlier time. In the 2000s, back when the internet was a lot newer, and UX best practices were much less well understood, and internet users were starting to see the first big wave of "evil" websites, many of us independently discovered a surprisingly simple and surprisingly effective mitigation. If you choose a custom browser theme, preferably with bright colors, websites can't fake browser UX elements. The default theme will clearly mismatch, and websites can't guess what theme you did pick.

[1] - https://textslashplain.com/2017/01/14/the-line-of-death/

I appreciate the effort being made here but the more I think about it the more I’m convinced it’s a no-win scenario.

Modal permission prompts are very annoying but inline prompts will need to have styling severely limited (as they do here) to avoid nefarious use. Almost all web sites with a designer attached will end up continuing to use styled buttons that call the modal prompt when clicked. I guess this sort of works as a <noscript> equivalent for permissions… but you can’t use the majority of those permissions without JavaScript anyway.

This special class of element also feels like a maintainability nightmare for browser teams. What happens when I put a <div> on top of this prompt with pointer-events:none on it? Would be textbook example of how you could mask the prompt. I’m sure you can fix that but there must be a hundred whack a mole problems I haven’t even thought of.

I thought I liked the idea at first when I was imagining an element with no UI that just told the browser what the page wanted - I see how that solves some of the issues they mention at first. But I don't like it as a UI element that is interacted with - the whole performance around what styling of it is allowed seems like the tip of a nasty iceberg of awkward issues and anti-patterns.

I really dislike when this happens. Completely side steps the standards process and puts forth an API that will have to be now considered since it’s in use. Chrome has done this before, too, I’m pretty sure with web components. Leading to the mess that they are.

Looks sensible, though I imagine it is going to be a nightmare trying to prevent click jacking, e.g. people putting elements over the top with `pointer-events: none`. There are probably a load of those attacks that are possible. Probably not too bad though because the final dialog is presumably shown above all other elements unconditionally.

Also those dialog designs are pretty awful from a usability point of view. In terms of design they all look identical, but the buttons change meaning pretty drastically, so you have to actually read the text. It would be better if it had some kind of slider or something that showed you the three possible states and let you switch between them consistently.

Can't blame Mozilla and WebKit for being against this API. Permission prompts are supposed to be controlled from outside the page so users can trust them. This proposal is very dangerous, and it's surprising Google doesn't see why.

This is the opposite direction permissions should be taking if anything they should be more prominently disconnected from the page, and browsers should improve their UI so multiple requests can be surfaced in a single prompt window.

Google's trial has "allow on every visit" and "allow this time", but "block on every visit" is conspicuously missing.

> Another challenge, especially on big screens, is the way the permission prompt gets commonly displayed: above the line of death[0], that is, outside of the area of the browser window that the app can draw onto.

So the proposal is to... put the permissions grant flow _below_ the line of death? Permissions grants _should_ break out of the untrusted context! It's a privilege escalation that only the browser (and its associated UI) should be able to grant!

[0] https://textslashplain.com/2017/01/14/the-line-of-death/

I’m not sure the linked document makes a good case for this. My initial reaction was that I didn’t understand why they made a point of it being declarative when the permission that results requires imperative code to function.

I think the point behind this is to stop websites from spamming permission popups by moving the permission prompt to page content and making the contents browser-controlled not website-controlled. I think that’s a better model, but it doesn’t really solve the annoyance of having the “fake” permission prompt followed by the real one, does it? Won’t websites just alter their “enable notifications” fake popup to include this?

I also don’t see how this solves the “no easy undo” problem. Won’t websites just remove that element once they gain permission? Or worse, they could spoof it and fake the undo.

What about <permission> having browser-defined UI instead? A site needs to access the location, for example there's a button on the page, 'Show my location', which is wrapped in a <permission> tag. When the user hovers over the button, the browser UI would appear on top of the area with a lock or something (the site cannot style this UI). If the user clicks on it, it would show the usual 'Site wants to use your location', and if the user agrees, they can click on the 'Show my location' button, if they don't agree, the browser UI would be shown again on the next hover. It would make it impossible for sites to obscure the permission-requesting UI.