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

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

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.

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/

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.

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.

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.

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

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

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?

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

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

  <permission type="camera" />

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.

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.

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

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