An origin trial for a new HTML <permission> element (2024) | Hacker News Reader

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

developer.chrome.com

98 pointstentacleuno92 comments

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

Maybe they don’t want to update this web page if the other vendors change their minds? They have links instead.

They never update web.dev pages, and often present not-even-close-to-being-standard as done deals

This bit from the WebKit response hits hard for me:

> Security Complexity: Proposed security measures (styling constraints, timing, and position mitigation) add substantial complexity, indicating possible fundamental issues with the approach.

"Security complexity" is never something you want to see, because it will become yet another game of whack-a-mole between browser makers and hostile websites (i.e. between Chrome and Google Ads). Does anyone believe that a standard will hold up against the AdTech industry armed with the full power of HTML+CSS+JavaScript? These are the people who brought you the "Enable push notifications? Yes/Pester-me-later" pre-prompt.

Google probably wants to bring the "maybe later" anti-pattern to the browser permission system:

https://tildes.net/~tech/1d9u/im_thoroughly_done_with_my_cho...

It's a reminder that Google is not a friend, but an ad-versary, and that you aren't given a free browser to happily navigate the internet, but to be milked by the ad industry.

Considering that Chrome doesn't support getAutoplayPolicy() even though it's been 7 years since browsers decided to break autoplay for everyone, I'm pretty sure Google doesn't have any good intentions here.

If you have a website that relies on autoplay, because it is basically just one giant video element, then there is no way to detect that autoplay is blocked and fall back to a stopped video. You're forced to essentially not use autoplay at all. When autoplay is blocked you don't get an error, the autoplay events are simply disabled. You can't prove the absence of the event even with an invisible silent sound being played in the background. That's what getAutoplayPolicy() is for and guess who didn't implement it.

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.

It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that. Google probably has data showing a large number of users have disabled such permissions globally, with no easy path to trick them into opting back in. That would be the cynical view!

edit: also one can never be too paranoid around Google.

> It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that.

I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.

> I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.

This does not appear to be the case, at least on iOS Safari. I went to Google Maps, gave it permission, then went to Google Search and searched for “delivery near me.” It again asked me for permission.

I imagine browsers have special logic for misbehaving major websites baked in all over the place.

Passkeys require a password manager, so at most, this locks you into a password manager - choose carefully!

But it’s not that locked in. You can generate new passkeys for a different password manager, so migration is more of an annoyance, if you do it gradually. Having more than one password manager for a while isn’t so bad.

> Passkeys require a password manager

No, they do not. For the vast majority they will simply require using the two major closed OSes which desire to lock the user in. Importantly the OS layer is where they will first encounter keypass, and so that is where the vast majority of keypass will happen, which is as gp said, the lock in factor.

Advanced users such as that that browse this site, will make use a password manager. Due to the extra effort involved, such users are a minority.

iOS and Chrome (often on Android, but not necessarily) have built-in password managers. I use both! I believe Windows has one, too.

It's true that a lot of people who don't really think about which password manager they should use will end up using one of those by default. (Much like happens with web browsers.)

Getting the masses to use password managers regularly will greatly improve security. It would be better if more people made a deliberate choice, though.

If you already had a password manager, of what good is the passkey?

One improvement is that they use public key cryptography, so they will never show up on Have I Been Pwned due to poor website security.

But yeah, if you use a password manager you’re probably doing better than most people.

If they wanted to improve things, they could include a small little xml link in their password change and registration pages that tells my password manager what passwords are allowed so it could auto-generate them rather than me trying to find out that they disallow anything longer than 32 characters, or that the ampersand isn't permitted. (Or, like years ago, when I discovered that Adobe didn't disallow long passwords they just truncated them to 64 characters internally and wouldn't accept the longer one after.)

Passkeys solve all that by hiding key generation entirely from users. But it requires a password manager and good backups.

Hiding things from me is never going to be a good thing. Hiding things from most people will never be a good thing.

Now that the FIDO alliance transfer protocol has been hashed out, Passkey transfer has been announced to be coming in iOS/macOS 26, I assume it's also coming to the other password managers

Passkey lock in appears to be a temporary issue. One of the WWDC announcements was that the FIDO alliance worked out a way to securely port passkeys between platforms. I expect Google to adopt import and export before year end.

I believe the issue Google is attempting to solve is frustration when a single web page spams multiple permissions requests. (Location, camera, microphone, advertiser tracking, notifications, privacy policy agreements, terms of service, etc…). The benefit to Google is better fingerprinting when a single sheet allows all at once.

Edit: perhaps they will sneak in a Google automatic login as a permission to smooth user interactions.

It's not temporary. The whole point of attestation in the passkey spec is to make lock-in permanent.

Could you explain more? For Apple, the web page I found seems to be an enterprise thing:

https://support.apple.com/guide/deployment/passkey-attestati...

That's the "cover story" use case. The real use case is so that passkeys created on Apple devices can only ever move to other Apple devices, and ditto for on Microsoft or Google devices, and the real point of attestation is so that they can force you to use theirs by cryptographically ensuring that you're not using open-source ones like KeePassXC.

But the whole point of this new standard is to allow passkeys to be portable:

https://arstechnica.com/security/2025/06/apple-previews-new-...

If that ends up letting attested passkeys be exported outside of the Microsoft/Apple/Google oligopoly, I'll eat my hat.

Who uses attested passkeys? (Serious question.)

As an example, see this issue opened against keepassxc saying that if they continue allowing plaintext passkey export, they're at risk of being blocked once attestation is standardized:

https://github.com/keepassxreboot/keepassxc/issues/10407

The goal here isn't maximizing user choice, it's to enforce minimum agreeable standards by the major vendors. It's up to you whether your personal needs wholly align with what they want to mandate, forever.

Yeah, I’m okay with that. It’s also true that not just anyone can become a domain registry either, but we still have choices.

It’s less convenient, but you can always create a new passkey manually for an account.

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.

Agreed. The UI should be owned by the browser and entirely separate from any page UI that could be hijacked.

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.

This is part of the standards process. Incubation happened here https://github.com/WICG/PEPC now on to Origin Trials before Standardization

Standardization... also known as open washing by their employees in WHATWG.

Well, they moved on despite both other major engine vendors having a negative position on this spec, so is the standards process really doing anything?

Yes, when people complain about what they're doing, they can say "this is just the way the standards process works".

I think that’s kinda misleading, isn’t it? You make it sound like it’s making good progress towards standardisation. They asked for feedback from other browser vendors, everybody said no, and they are shipping it anyway. Is “incubation happened, now on to origin trials before standardisation” really a suitable summary of that?

> “incubation happened (and we don't care what anyone said), now on to origin trials before standardisation (in chrome, and good luck if you use another browser)”

That's exactly how google would describe it with some missing context added.

It cannot be a standard until two browsers ship the API.

lol. As long as a browser with Chrome's market share ships it, it will be used.

Whether it's an official standard by some criteria doesn't matter.

Technically, it’s not two browsers shipping it, it’s two independent implementations. Otherwise everything that Google ships as part of Blink would become a standard as soon as any one of the other Blink-based browsers (e.g. Edge) includes it.

It's not. There are now probably dozens (if not more) "standards" that are shipped in Chrome because "it's part of standards process".

Google creates an excuse of a standard proposal. Other browser vendors find major issues, or outright say "no", Google still ships the "standard".

Well, It's on an Origin Trial, so it's only "in use" for people that have explicitly turned it on. There's not much to dislike.

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.

If it's blocked by default and you need to interact to opt in, isn't the default "block on every visit"? The only reason it's an option now is to avoid the modal popping on every visit, which isn't a concern for this proposal.

Edit: Not sure why I'm being voted down? Can someone who disagrees with my statement explain why you'd click a button with the goal of opening a modal to deny a permission when the permission is already blocked?

We want an option that means "block, and don't let this site ask me for this permission ever again".

That's the point: the site never asks for permission with this proposal. You can't opt out of asking because the UI for the proposal is explicitly opt in. What would you want such an option to do in the context of this proposal?

It depends on how styleable the <permission> element ends up. I don't imagine any website will use it if it's limited to being an ugly default button with non-configurable text. But if the button is configurable enough, there's nothing to stop websites from abusing it for permission spam, just like the current model is.

Basically, I expect users wil stil need a way to defend against permission spam.

This proposal doesn't (nor can it possibly) fix the issue of the site putting a full-viewport UI up that forces you to trigger a permission modal. That's an issue today, and it doesn't even have anything to do with permissions. See: cookie popups, newsletter popups, disable your ad blocker popups. It's impossible to avoid that problem, because the nag screen is the content of the page. Even if you block permission requests with today's options, the site can still do this to annoy you into changing your mind.

If you're on a site that follows your cursor around with this button forcing you to click on it, the SITE is spam, not the permission request.

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

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

You're describing the "no easy undo for allow" problem. Google doesn't care about that and doesn't want to fix it, since they want more of your data, not less. This element is just to have a solution to the "no easy undo for block" problem.

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.

Olx.in

Original fb marketplace in india.

These fuckers ask for location on each search query, basically on each page load.

It is annoying to operate on Firefox focus and regular Firefox on android as it has a bug I assume that does not honor per site permission disable request.

Same on Firefox desktop, it works, sometimes it does not and then the site is unusable unless you deny location on each page load. Urrrghhh

We need global default off and per site permission.

Also, would it not be easier to pass dummy coordinates like 0.00,0.00 to bypass the nag screen ?

Same for notifications. "Yeah yeah notifications are enabled. Stop bothering me" ??

> These fuckers ask for location on each search query, basically on each page load.

Google's search is rapidly going in the same direction

> "Yeah yeah notifications are enabled. Stop bothering me" ??

It boggles my mind that even the "privacy conscious" browsers like Safari and Firefox don't have a "no, and never ask me again for this site".

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.

Only the button that triggers the dialog is in the content area

Nope, there’s a modal in the middle of the screen.

There are no screenshots in the linked article that show a permission modal in the middle of the viewport. The only screenshot with a modal in the viewport is a screenshot of Google Meet today without this, showing how to open the modal to reset permissions.

The permission modal that's shown intentionally overlaps the line of death, which is exactly the same as it is today

Oh, sorry, the modal discussion is in the Mozilla position, for example: https://github.com/mozilla/standards-positions/issues/908

A ways down in the discussion they note that there's really two parts to the proposal: showing the permission state and triggering the permission dialog, and separately having an in-content permission dialog. The article linked here doesn't seem to touch the second part at all. That's probably wise, and it doesn't mean the proposal is DoA.

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.

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.

It does, but on the very bottom in a smaller text size.

> Last updated 2024-06-12 UTC.

I saw, but I think I’d also find a publication date useful

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

” but this isn't how HTML works. Really, while at first glance it might seem like a good idea, this whole feature is an inconsistent mess. It's not the declarative element it's claimed to be.

Except it is declarative? The element renders a button and clicking the button (without any JavaScript) shows a browser UI for managing the permission. How is that imperative?

It's not declaring a permission: it's instructing the browser to render a button. That's like saying <button onclick="Notification.requestPermission()">Notify me!</button> is declarative.

It's declarative in that it's telling the browser to render a complete UI for showing and modifying the state of the permission. Just because there's also an imperative API that already exists doesn't mean it's not declarative. It's certainly not imperative, there's nothing imperative about it.

Moreover, it allows the user to show the browser controls for re-requesting the permission if it was previously denied, which isn't possible with the imperative API (because an imperative API can implicitly be abused).

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

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

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.

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.

The dialog isn't stylable, and the button that triggers the dialog has minimal styles

What does Mozilla/W3C/WHATWG think about this?

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

Webkits and Mozillas positions are linked at the bottom (they are both negative).

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)?

because it is where you go to do video conferencing.

HTML means HyperText. It has always been about much more than mere text documents.

You might thinking of plain text documents? Those have no need for your camera and microphone.

Reply on news.ycombinator.com