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.
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!
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. It's imo very good that we are finally leaving this awful tarpit of design, & moving towards permissions being more fluid.
I feel like there was some other spec else also doing a <permissions> like thing recently...
I'm not familiar with how this process went in this case, the blog post seems to suggest that feedback from other vendors was incorporated. Can you elaborate on the outstanding issues?
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.
It still pops up a permission confirmation dialog
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!
[0]: https://textslashplain.com/2017/01/14/the-line-of-death/
I'm curious to why the polyfill example uses unpkg.com. It is quite unreliable and has broken sites many times.
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, this was a very specific narrow case chipped off a bunch broader attempt to offer declarative ways to handle permissions in general. https://groups.google.com/a/chromium.org/g/blink-dev/c/GL0Bk...
Earlier proposal: https://github.com/WICG/proposals/issues/113 https://github.com/andypaicu/PEPC/blob/main/explainer.md
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. It's imo very good that we are finally leaving this awful tarpit of design, & moving towards permissions being more fluid.
I feel like there was some other spec else also doing a <permissions> like thing recently...
Even though the other browser vendors have positive reaction, note how this follows the same pattern Chrome has followed for over a decade:
- scribble on a napkin (explainer)
- ask others for their position
- ship regardless of position or any outstanding issues
- claim it's a new standard
I'm not familiar with how this process went in this case, the blog post seems to suggest that feedback from other vendors was incorporated. Can you elaborate on the outstanding issues?
If you follow the links to browser positions, there are still discussions about various concerns that don't seem to have been addressed.