> 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.

Isn't there an important reason for the permission dialog to _not_ be in the content area? I see no discussion of how this will avoid clickjacking attacks.

Here's an alternative along these lines:

An <intrusive type="..."/> element. It wouldn't be styled by the site except to determine whether it was visible at all and how it was positioned on the page. The element would support a dom api to query information corresponding to it's type (eg location, video, etc). The element would only provide information when it was fully visible on the page. It would display on top of every other element on the page, and wouldn't be permitted to be positioned on top of other <intrusive> elements. It would display to the user a visualization of the information being provided to the website. For example, an <intrusive type=location> element would display a map with the location the browser is giving the website being positioned on the map.

By default, if the user didn't interact with it at all, it would give the page "fake" information that doesn't require permissions to know. For example, for location, it would display the location on a map as determined by the users externally visible ip address using geoip. For video, it would display a static avatar. For audio, it would perform text to speech based on whatever is typed by the user. The element would contain a short text explaining that this is what it is doing (eg: "Location: coarse"; "Video: avatar"; etc). The user could click/tap on the element to configure what information it provides. For an <intrusive type=location>, a dialogue would be displayed suggesting the user either give "fine", or "coarse" location to the site. A preview of what the intrusive element would look like afterwards would be given for each option. The default selected option would be whatever the currently selected option is, eg "coarse" for location. There would be a button marked "continue" which would leave the current option selected. Since users often click "continue" (or "ok", or even "cancel") without thinking about what they are doing, this would cause the permission to "fail safe".

This is really convenient for users. A really convenient way for them to unwittingly grant more permissions than intended.

thinking how this shifts the framing of permissions from being browser-managed to site-declared. putting the intent inline means sites start shaping how consent feels, not just when it happens. that changes the surface area. the prompt becomes part of UX design, not just a browser interruption.

it's subtle, but long term it puts more pressure on users to parse trust context visually, not functionally. if every site can skin permission requests differently, consistency breaks down. user instinct gets trained on style, not source

Notably absent from the list of allowed CSS declarations is font-family, probably because you could abuse it to change the text on the button. While I appreciate the safety that this gives, it's going to be an annoying UX wrinkle basically in perpetuity. Especially if you're building a page with serif fonts and the browser makes your button sans serif (or vise versa).

It's a good idea, but that complicated list of styling interactions/restrictions seems honestly ridiculous.

If the goal is to let users easily identity this element as "browser-provided", then having the element "stick out" and be distinct from the page style would sort of be the point - so I don't see why styling fonts or colors should be possible at all.

If this is not the goal, then why restrict styling at all?

In any case, I don't see how users could be educated to rules like "If the letter spacing is between 0 and 0.5 em, it's genuine, otherwise it's fake" or "the font can be normal or italic, but not bold or underlined" to distinguish genuine from fake permission elements.

I get that permitting full styling would allow all kinds of dirty tricks with overlays, strategic invisibility etc, that have to be defended against. But do they really want to play continuous whack-a-mole with all the ways styling could be exploited?

So Chrome's just completely sidestepping `.request` being dropped for being too much of a security risk in the context of people being limited in attention, and the web being rife with abuse, then? That's how this whole thing reads to me.

I wish the template that Google uses for all of their dev blogs had a clear date, otherwise people would have realized that this is one year old, and the origin trial has already ended.

https://developer.chrome.com/blog/permission-element-origin-...

In case you got a stupid-ass machine-translated version.

> No easy undo

> Finally, it is too easy for users to navigate themselves into a dead-end. For example, once the user has blocked access to a feature, it requires them to be aware of the site information drop-down where they can either Reset permissions or toggle blocked permissions back on.

Yea, that's a real humdinger, if only the vendor of that software would commit some engineering resources to solve that problem.

The article says: “In its simplest form, you use it as in the following example:

  <permission type="camera" />

<permission> looks like only the elements inside will have access to the feature. But we all know that's not how permissions work.

I think this is not the good way to handle permissions; it has many problems (including the problematic complexity of the security and other aspects of the implementation). Other comments mentioned here describe some of these problems. I think it is better to use the browser's UI instead of within the document itself.

However, I also think it would be a better idea to allow these permissions to be proxied (e.g. when camera access is required, you are allowed to specify a file instead if you want to do, or any external program, etc; this can be a third option in addition to "allow" and "deny"). To be able to easily undo permissions, add a menu that you can easily alter them.

Its a way for Google to ensure some things will only work with Chrome. I hope it will bite them back

I think that as long as the APIs for interacting with whatever each permission gives access to: camera, microphone, geo-location, etc, can't be accessed directly from HTML, a <permission> tag should not be in the spec.

Maybe they want to bring a whole lot of other elements in to allow that type of access, but I wouldn't put the carriage before the horses.

These prompts should not be stylable and should have a standard layout for all sites. This is another cookie banner disaster in the making. This is a big step backwards.

What does Mozilla/W3C/WHATWG think about this?

That's a joke, who cares....

Will be a good XSS PoC prompt.

Thanks, I hate it!

Looks like they try to "fix" an issue that should be fixed on the browser's UI side.

Why am I supposed to give access to my camera and microphone to a text document (HTML page)?