Exactly, as sites start using this new tag users will see this breaking in the other browsers who will then be "pushed" into the Google way.
The line about being open to feedback while they're encouraging sites to start building using this really feels disingenuous. At least they could own their choice that they want to go it alone on this.
we're planning to push ahead with our implementation in Chromium, continuing to iterate with your feedback in mind.
As noted in the intent to ship for both, these are a very specific narrow cases chipped off a bunch broader attempt to offer declarative ways to handle permissions in general, a <permission> element.
The root problem is that permissions right now are super hard to adjust for users (and the way they are exposed to the page is not very good at dealing with users turning permissions on and off either). It's imo very good that we are finally leaving this awful tarpit of design, & moving towards permissions being more fluid. I get that other browsers wanted to be conservative & not do a generic <permission> element, but given how big an improvement this feels like, I sort of wish it'd gotten the pass.
I'm a bit confused about how it actually works, and somehow they decided to not include a demonstration video.
If clicking on it does trigger a location permission prompt: what's the point? The "issues" with prompts getting denied can already be solved by web developers doing this themselves, rather than just blindly firing off a request on page load.
If clicking on it does not trigger a location permission prompt: have we forgotten about the Line Of Death [0]? Clicking random website-styled elements should never result in dangerous actions being taken - and leaking the user's physical location is definitely dangerous. Sure, they are trying to restrict the styling, but that's a fools' errant: somebody will just make a browser game where the button looks to refer to something ingame, but actually leak your real-world location.
Besides, who's actually asking for this? Location is perhaps useful for Google Maps-like websites to save you a few seconds of scrolling, but in practice it has mostly been spammy websites trying to get me to "subscribe to local news". Making geolocation easier is the last thing I want in my browser!
This seems pretty sketchy, and I don't really understand what prevents a website from clickjacking.
The original flow is awkward, but also renders the permission element in a location that can't be clickjacked, thus offering some protection from geolocation.
Main purpose of this seems to offer a way for undoing "previously blocked location access" by the user.
> If a prompt appears unexpectedly, users may block it reflexively or accidentally, unaware that this decision creates a permanent block that is difficult to reverse. This context gap—rather than the feature itself—is a primary driver of high denial rates.
> If a user previously blocked location access when browsing a site (perhaps by accident or lack of context), clicking the element triggers a specialized recovery flow. This helps them re-enable location at the moment when they actually want to use location, without the friction of navigating deep into the browser's site settings.
Google sees "high denial rates" when they try ask users for their geolocation. This is a problem for Google's customers, the advertisers. So they introduce this <geolocation> HTML tag so that dark patterns can be employed to trick users into permanently sharing location even though they have blocked location sharing before.
If the Google engineers who are working on this feature would actually give a damn about users who decided to block geolocation access, this feature would be designed as a "temporary access to geolocation for duration of browser session".
So basically it is all about more tracking and less data privacy.
It's overdue that skilled engineers provide better solutions than this crap, but of course it's much easier to be apolitical and become a millionaire working for a bunch of tech bros who visited Epstein's island.
This might be easier than refusing permission every time - it sounds like I can just not click it. I really dislike location permission things. I don't know what location will be shared, I don't use anything that needs a precise location, and I don't ever want to share my actual location. If location permission things showed me a map with where they think I am and let me click a (vague) location to share, I might use them, but currently to find nearest stores or whatever I just type in a postcode or use their map.
Edit: this has prompted me to go find a way to turn off location permission requests in the browser settings. It turns out you can do it under Privacy and Security > Site Settings in Firefox and Chrome.
This element has an autolocate attribute that will request permission automatically, plus it doesn't supersede the JS api, it simply provides a declarative alternative to it, so sites that follow this negative pattern will keep doing so.
At the same time, there is no reason to not implement this pattern today and require user intent prior to requesting the permission
Me too. I don't share precise location but will happily click on a map if a website gives me the option. For things that i really need, i just use dev tools to manually set the location :)
Contextual permissions are a big improvement over early and uncertain prompts. I will never agree to grant my permission when first loading a page, however, I may do so if intentionally activating a map widget. At least then I understand the context by which it's being asked, and can make a more informed decision.
This is pretty cool. But what gets me really excited is the new generic <Permission>[0] element. I had to implement a webcam element one time for some CV pet project and I had a lot of trouble getting the basic api to just work (Highly likely a skill issue). So seeing that this will also expand to webcam and other IO seems like a really good UX improvement.
This mostly changes how location is requested, not what you can do with it. Instead of imperative JS calls, location access becomes declarative in HTML, which gives browsers more context for permission UX and auditing. Your app logic, data flow, and fallbacks don’t change, and you’ll still need JS to actually use the location. Think of it as a cleaner permission and intent layer, not a new geolocation capability.
The main intent behind this seems to be constantly reminding users that enabling geolocation is an option, and that it is an ordinary thing to do. Dear user, why don't you still use it, everyone does it. Just click the button!
Yes, because users don't like when things don't work, and they don't think about that time they blindly dismissed a permission notification and don't understand how to go undo that easily.
So we make it easier for the user to actually do the thing they intend to do. Seems good to me.
This seems completely unnecessary. If they want to solve the issue of permission prompts on website load without user intent then disallow permission requests that are done outside a click event handler.
26 comments
[ 4.3 ms ] story [ 48.7 ms ] thread- scribble on a napkin (explainer)
- ask others for their position
- ship regardless of position or any outstanding issues
- claim it's a new standard
The line about being open to feedback while they're encouraging sites to start building using this really feels disingenuous. At least they could own their choice that they want to go it alone on this.
we're planning to push ahead with our implementation in Chromium, continuing to iterate with your feedback in mind.
https://github.com/WebKit/standards-positions/issues/545#iss...
jsdelivr.com is much more reliable (Multi-CDN, Multi-DNS). Comparison: https://www.jsdelivr.com/unpkg
I am not affiliated in anyway to jsdeliver or unpkg. I simply used to be a user on unpkg.
As noted in the intent to ship for both, these are a very specific narrow cases chipped off a bunch broader attempt to offer declarative ways to handle permissions in general, a <permission> element.
Intent-to-ship for geolocation: https://groups.google.com/a/chromium.org/g/blink-dev/c/GL0Bk...
Earlier Page-Embedded Permissions Control (PEPC) proposal: https://github.com/WICG/proposals/issues/113 https://github.com/andypaicu/PEPC/blob/main/explainer.md
The root problem is that permissions right now are super hard to adjust for users (and the way they are exposed to the page is not very good at dealing with users turning permissions on and off either). It's imo very good that we are finally leaving this awful tarpit of design, & moving towards permissions being more fluid. I get that other browsers wanted to be conservative & not do a generic <permission> element, but given how big an improvement this feels like, I sort of wish it'd gotten the pass.
If clicking on it does trigger a location permission prompt: what's the point? The "issues" with prompts getting denied can already be solved by web developers doing this themselves, rather than just blindly firing off a request on page load.
If clicking on it does not trigger a location permission prompt: have we forgotten about the Line Of Death [0]? Clicking random website-styled elements should never result in dangerous actions being taken - and leaking the user's physical location is definitely dangerous. Sure, they are trying to restrict the styling, but that's a fools' errant: somebody will just make a browser game where the button looks to refer to something ingame, but actually leak your real-world location.
Besides, who's actually asking for this? Location is perhaps useful for Google Maps-like websites to save you a few seconds of scrolling, but in practice it has mostly been spammy websites trying to get me to "subscribe to local news". Making geolocation easier is the last thing I want in my browser!
[0]: https://textslashplain.com/2017/01/14/the-line-of-death/
The original flow is awkward, but also renders the permission element in a location that can't be clickjacked, thus offering some protection from geolocation.
> If a prompt appears unexpectedly, users may block it reflexively or accidentally, unaware that this decision creates a permanent block that is difficult to reverse. This context gap—rather than the feature itself—is a primary driver of high denial rates.
> If a user previously blocked location access when browsing a site (perhaps by accident or lack of context), clicking the element triggers a specialized recovery flow. This helps them re-enable location at the moment when they actually want to use location, without the friction of navigating deep into the browser's site settings.
Google sees "high denial rates" when they try ask users for their geolocation. This is a problem for Google's customers, the advertisers. So they introduce this <geolocation> HTML tag so that dark patterns can be employed to trick users into permanently sharing location even though they have blocked location sharing before.
If the Google engineers who are working on this feature would actually give a damn about users who decided to block geolocation access, this feature would be designed as a "temporary access to geolocation for duration of browser session".
So basically it is all about more tracking and less data privacy.
It's overdue that skilled engineers provide better solutions than this crap, but of course it's much easier to be apolitical and become a millionaire working for a bunch of tech bros who visited Epstein's island.
https://permission.site/geolocation_element.html
But I have no doubt there is a play happening here.
Probably it will change over time to make gathering data easier?
Or something else that makes Google money.
Edit: this has prompted me to go find a way to turn off location permission requests in the browser settings. It turns out you can do it under Privacy and Security > Site Settings in Firefox and Chrome.
At the same time, there is no reason to not implement this pattern today and require user intent prior to requesting the permission
- [0] https://github.com/WICG/PEPC/blob/main/explainer.md
So we make it easier for the user to actually do the thing they intend to do. Seems good to me.
That would be a net benefit because pages requesting location for no reason end up in the block list and don't annoy me anymore.