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

  <permission type="camera" />

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.

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.

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.

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

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

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

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?

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

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

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.