Uughh why do we need this whole new html element and not simply make the getUserMedia API allowed to be called more than once if the initiator is a user click?
I'm not all that happy with second chance options in the first place... but a dedicated element with browser-level protections on making sure it's clear clicking that particular element is going to second chance the permission prompt is at least much less likely to get abused.
> protections on making sure it's clear clicking that particular element is going to second chance the permission prompt is at least much less likely to get abused.
I guess I really don't understand the abuse they're trying to guard against. The protections are like "the button isn't transparent and there's a 3:1 contrast ratio, because click jacking." Alright, so I will just make the button say 'click to view content' or 'click for free bitcoins' or really anything at all and people will happily press it.
And when they do they'll get the same permission dialog they would have if I had been allowed to make the button invisible anyway.
I understand the use case for the second chancing. I think it's really crazy to make it require this special HTML (!?) element that you can only have up to 3 of on your page at a time (because we all know as soon as you hit 4 of these buttons it means you're up to no good).
If it were me I would have allowed second chancing via JS API, only if initiated by user action (we have that pattern already for events), and with exponential back off between retries.
If they were really dead set on this whole concept of secure enclave essential oils elements, they had a decent idea with the `<permission>` element that they mentioned in the article - but then we decided to throw that out, but don't worry, specific `<camera>` and `<microphone>` elements are coming soon.
Or even fixing the "navigating complex browser settings" issue. They control the freaking UI yet still use that as an excuse to build something else instead. Pretty hilarious.
Or "we willfully borked the permission system in chrome so we could force everyone to implement our stupid solution". They could've just made better the "options" button at the top left of the URL bar which already allows you to quickly edit the website granted permissions but nuh uh. Be As Evil As Possible:tm:
At the very least, Firefox's position on the similar <geolocation> element is positive.[0] I would assume their position for other permissions elements would be the same.
I seldom see visibility for any releases in popular browsers. The only time I notice any is if I don't use it for years, then get handed a work laptop that uses X browser. It's at least cool to see these docs even if I likely won't ever see/appreciate the element in use.
> Cisco observed that users who initially denied permissions were only about 10% likely to successfully grant permissions using legacy prompts, but that rate jumped to more than 65% with the new element.
Meaning they tricked more people into granting permissions they would have otherwise not granted.
I'm not sure how the element itself increases fingerprinting surface more than the status quo. Not to mention manually blocking it makes you even fingerprintable
Chrome basically is abusing its market position, 69.65% globally, and becomes the new IE. Implementing its own HTML/JS standard.
The sad truth is, some companies will look at Statcounter[0] and say because Firefox does not reach 5% global population and decided not supporting it, actively or passively.
This is literally how the standards are meant to work, at least on the JS side. The tc39 process requires at least two live implementations to exist before a spec can move to finished.
In this case, there's also people from Mozilla onboard, so there's no guarantee that it'll remain chrome only or that chrome will keep it if the spec doesn't go anywhere.
In fact, much of the web as we know it evolved this way. We have IE to thank for AJAX, after all.
Standards are democratic controls for democratic institutions, not "organizations" that are entirely captured by corporate interests. Absolutely despise how private entities have ruined software engineering by pursuing things that favor themselves rather than people in general.
Another reason why this is problematic is that their proposed standards follow Google's priorities for its own products, particularly Google Meet.[0][1]
Another example is QUIC. What is the benefit of QUIC? On one hand Google boasts it greatly increases page load speed, which is contextually arguable. On the other hand, Google’s design priorities were to introduce UDP to the browser because UDP supports multicast, which lowers CPU utilization in data centers.
If you wanted to do dynamic stuff in IE, you had to use ActiveX. Which was IE-only. So many sites only used ActiveX, because IE was the 900lb gorilla, so why support anything else?
Interesting to see that on Desktop, Firefox (5.8%) just overtook Safari (5.0%) for third place. It doesn’t feel statistically significant but it’s a bit of data at least.
This has been happening for a while now, basically anywhere there’s room for a potential compatibility issue there will be one. As if any time some observable behavior is an implementation choice the Chrome team policy is “not what Firefox does”. The result is that if you develop on Chrome and don’t test on Firefox your stuff is very likely broken on Firefox.
The use started to decline when Google started the extreme marketing campaign of Chrome around 2010 or so. All Google services had huge banners and included all sorts of dark patterns to get people to install it.
TBF, Chrome probably also had some better features and performance over FF, but I don't think most people think much about their browser quality.
New is old and old is new. Back in 2010 the W3C had originally proposed camera access via the `<device>` tag.
Opera even shipped a build supporting it.
The immediate thought is re-prompt spam, for eternity, even with an appropriate signal sent from the user agent. This is the same as cookie banners - keep flushing the cookies after each session if the user agent doesn’t accept and wait until they do.
It’s a techbros wet dream on consent. Just keep asking until they say yes.
Uughh why do we need this whole new html element and not simply make the getUserMedia API allowed to be called more than once if the initiator is a user click?
I'm not all that happy with second chance options in the first place... but a dedicated element with browser-level protections on making sure it's clear clicking that particular element is going to second chance the permission prompt is at least much less likely to get abused.
> protections on making sure it's clear clicking that particular element is going to second chance the permission prompt is at least much less likely to get abused.
I guess I really don't understand the abuse they're trying to guard against. The protections are like "the button isn't transparent and there's a 3:1 contrast ratio, because click jacking." Alright, so I will just make the button say 'click to view content' or 'click for free bitcoins' or really anything at all and people will happily press it.
And when they do they'll get the same permission dialog they would have if I had been allowed to make the button invisible anyway.
I understand the use case for the second chancing. I think it's really crazy to make it require this special HTML (!?) element that you can only have up to 3 of on your page at a time (because we all know as soon as you hit 4 of these buttons it means you're up to no good).
If it were me I would have allowed second chancing via JS API, only if initiated by user action (we have that pattern already for events), and with exponential back off between retries.
If they were really dead set on this whole concept of secure enclave essential oils elements, they had a decent idea with the `<permission>` element that they mentioned in the article - but then we decided to throw that out, but don't worry, specific `<camera>` and `<microphone>` elements are coming soon.
I'm probably getting too old for this...
2 replies →
Or even fixing the "navigating complex browser settings" issue. They control the freaking UI yet still use that as an excuse to build something else instead. Pretty hilarious.
Or "we willfully borked the permission system in chrome so we could force everyone to implement our stupid solution". They could've just made better the "options" button at the top left of the URL bar which already allows you to quickly edit the website granted permissions but nuh uh. Be As Evil As Possible:tm:
Is this Chrome only or something the other browsers are working on, too? A quick web search does not seem to produce any relevant hits.
At the very least, Firefox's position on the similar <geolocation> element is positive.[0] I would assume their position for other permissions elements would be the same.
[0]: https://github.com/mozilla/standards-positions/issues/1288
Seems Chrome-only for now. But the spec (Working draft) has an editor from Mozilla as well, so maybe someday... https://w3c.github.io/mediacapture-extensions/#the-usermedia...
I seldom see visibility for any releases in popular browsers. The only time I notice any is if I don't use it for years, then get handed a work laptop that uses X browser. It's at least cool to see these docs even if I likely won't ever see/appreciate the element in use.
Apple and Firefox are running tests on the previous parts of this that recently came out (geolocation), so they will be doing the same with this one.
> Cisco observed that users who initially denied permissions were only about 10% likely to successfully grant permissions using legacy prompts, but that rate jumped to more than 65% with the new element.
Meaning they tricked more people into granting permissions they would have otherwise not granted.
Anything new I have to block so my ass can't be fingerprinted?
I'm not sure how the element itself increases fingerprinting surface more than the status quo. Not to mention manually blocking it makes you even fingerprintable
So that your ass get fingerprinted you would need to use the Usermedia control and then hold the camera behind your back ... Okay, I let myself out.
Chrome basically is abusing its market position, 69.65% globally, and becomes the new IE. Implementing its own HTML/JS standard.
The sad truth is, some companies will look at Statcounter[0] and say because Firefox does not reach 5% global population and decided not supporting it, actively or passively.
[0]: https://gs.statcounter.com/
This is literally how the standards are meant to work, at least on the JS side. The tc39 process requires at least two live implementations to exist before a spec can move to finished.
In this case, there's also people from Mozilla onboard, so there's no guarantee that it'll remain chrome only or that chrome will keep it if the spec doesn't go anywhere.
In fact, much of the web as we know it evolved this way. We have IE to thank for AJAX, after all.
Standards are democratic controls for democratic institutions, not "organizations" that are entirely captured by corporate interests. Absolutely despise how private entities have ruined software engineering by pursuing things that favor themselves rather than people in general.
3 replies →
Another reason why this is problematic is that their proposed standards follow Google's priorities for its own products, particularly Google Meet.[0][1]
[0]: https://developer.chrome.com/docs/web-platform/element-captu...
[1]: https://developer.chrome.com/docs/web-platform/document-pict...
Another example is QUIC. What is the benefit of QUIC? On one hand Google boasts it greatly increases page load speed, which is contextually arguable. On the other hand, Google’s design priorities were to introduce UDP to the browser because UDP supports multicast, which lowers CPU utilization in data centers.
11 replies →
IE was bad because Microsoft let it stagnate, not because they were creating new things.
Stop getting history twisted.
It was both.
If you wanted to do dynamic stuff in IE, you had to use ActiveX. Which was IE-only. So many sites only used ActiveX, because IE was the 900lb gorilla, so why support anything else?
Interesting to see that on Desktop, Firefox (5.8%) just overtook Safari (5.0%) for third place. It doesn’t feel statistically significant but it’s a bit of data at least.
(I’m a big Firefox fan and idealist.)
This has been happening for a while now, basically anywhere there’s room for a potential compatibility issue there will be one. As if any time some observable behavior is an implementation choice the Chrome team policy is “not what Firefox does”. The result is that if you develop on Chrome and don’t test on Firefox your stuff is very likely broken on Firefox.
TIL that Firefox has less than 5% market share. When and why did people stop using Firefox?
--
Submitted from Firefox
The use started to decline when Google started the extreme marketing campaign of Chrome around 2010 or so. All Google services had huge banners and included all sorts of dark patterns to get people to install it.
TBF, Chrome probably also had some better features and performance over FF, but I don't think most people think much about their browser quality.
> When and why did people stop using Firefox?
Approximately at the time when majority of the Mozilla resources started going into non-browser projects. And pretty much for the same reason.
1 reply →
Chrome basically is abusing its market position, 69.65% globally, and becomes the new IE. Implementing its own HTML/JS standard.
Embrace. Extend. Extinguish.
We went to this rodeo a generation ago. Nothing was learned.
New is old and old is new. Back in 2010 the W3C had originally proposed camera access via the `<device>` tag. Opera even shipped a build supporting it.
[dead]
This won’t get abused. /s
How do you see it being abused?
"Press here to view the content", there's already plenty in the wild that grant access to notifications with deceptive buttons.
4 replies →
The immediate thought is re-prompt spam, for eternity, even with an appropriate signal sent from the user agent. This is the same as cookie banners - keep flushing the cookies after each session if the user agent doesn’t accept and wait until they do.
It’s a techbros wet dream on consent. Just keep asking until they say yes.
3 replies →