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.
right now sites cant retry prompts because they could just spam annoying permission dialogs in a loop until the user hits allow. thats a problem for legit sites because you have to manually go and grant the permnission from site settings if you change your mind. it adds friction you cant avoid with a script based design.
with a special element dialogs can only show once for every user action. even if the site uses "click to get bitcoin" style misleading prompts users will notice and not click on that button again. none of this is about security in a strict sense, just better ux on both good and bad sites.
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.
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.
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.
That is not how standards work. Some for sure, but the majority are established by groups of companies / a guild establishing rules. The law pressures them often into it (e.g. the EU did not say USB-C port, they said: one standard, you industry figure it out).
There are surely exceptions (maybe the IEEE; which are professionals union).
No, this is how good standards bodies works. It require collaboration across nations, sorry but this is like small d democracy stuff here. What isn't good are corporate interests rat fucking engineering practices to pursue greater profits.
I agree all about company creed and also in many cases the standard is the lowest common denominator of their implementations. I am also a fan of putting national sovereignity over profit, but that does not change that in most cases only companies have the interest, the need and the insights to standardize stuff.
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.
They claimed and showed QUIC slightly-to-moderately reduced latency, particularly for mobile. This benefits Google by loading pages with third-party content, i.e. ads, faster.
But QUIC significantly increases CPU utilization on servers, at least the widely used userland stacks do. Unless/until Google deploys QUIC in the kernel (or puts the whole network stack in userland, a la DPDK), this won't change.
The multicast claim is kinda bizarre. I can see how QUIC could help eliminate UDP client barriers, but those barriers pale in comparison to multicast. Multicast routing just doesn't exist on the Internet; it's only supported within some independent, typically small networks. Most ISPs don't support it. Wherever you could manage to distribute content with multicast, you'd necessarily also be resolving the collateral routing problems which QUIC support resolves, whereas even ubiquitous QUIC doesn't materially improve the multicast situation.
I couldn't find any evidence Google pushed QUIC with the aspiration of utilizing IP multicast.
In 2022 an RFC for adding multicast support to QUIC was published, but backed by Akamai, not Google. And of course the RFC has the caveat that it would only be useful over multicast networks, e.g. edge servers colocated at an ISP. It seems this effort has picked up some steam over 2025 and 2026.
But I didn't look too hard. Can you share sources?
The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards to transmission, so the solution in the browser is always open more sockets. However, on the server, the advantages are huge.
You have to understand that multicast is OSI layers 2, 3, and 4. Its layer 2 because it uses a NIC as a local identifier for management apart from other multicast sockets available, UDP and TCP are layer 4 protocols, and it also takes on some layer 3 capabilities for congestion management. This is where the CPU advantage comes in, because you are offloading some of the traffic processing elsewhere in the stack and to network devices, like switches/routers.
Yes, Google has said that part of the motivation was reducing CPU load but I cannot remember where I saw that.
Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.
IIRC, QUIC was also the precursor to HTTP/3. I don't like Google's motivations for wanting a faster web, but many of the things they've encouraged and/or provided have made things faster and more efficient. I'm not a google apologist, there's so much wrong and so much harm done... just saying it's maybe worth separating the tech from the motives.
HTTP/3 uses QUIC as the transport layer, which in turn relies on UDP. QUIC replaces TCP while allowing a reduction of handshake exchanges in HTTP/3 first requests. Finally, even though UDP supports multicast, I believe QUIC doesn't. GP saying Google has developed it to use multicast thus is nonsense. Furthermore, QUIC takes much more CPU than TCP right now, due to running in userland.
In my opinion, QUIC and HTTP/3 are technical marvels, but are perhaps way too complicated and don't really serve the interest of most internet users.
There will be a point in the development of web browsers and associated technologies where we should just stop a bit to get things stable instead of churning protocol version after protocol version after new API. Will it ever stop?
Eventually, it all becomes so complicated no company can manage it all. Honestly, we might already be past this point, with Chromium at almost 40mi LOC, more than the Linux kernel itself, including all its drivers. When will the madness stop? Do we really need such complicated software to see Instagram posts, comment on a few Hacker News threads and mess around with Google Sheets?
The biggest reason I worry so much about this is that in the web, adding new features, APIs and protocols is easy. Removing and deprecating is basically impossible.
It's not very complicated to import the QUIC library, or to import the HTTP library with HTTP/3 supported. For the library authors, QUIC isn't more complicated to implement than TCP. Doomsaying about the complexity of Google Sheets is completely unrelated to whether QUIC is good tech and superior to TCP, which it is; the only remaining complaint is that it's too new to have been part of the kernel yet, and if that makes technology somehow illegitimate then I guess we're just stuck with the mistakes of the 90s forever, why ever invent anything new at all.
That is also entirely incorrect. There are many challenges to implementing an original QUIC library. The Node.js project is developing and evaluating for this right now and the effort is extensive.
> Finally, even though UDP supports multicast, I believe QUIC doesn't.
Don’t confuse the browser for the server. QUIC is UDP but UDP is not QUIC. Unlocking UDP for the browser allows capabilities on the remote end that aren’t available to the browser.
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.
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?
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.
So when would that be exactly? Firefox was first released in 2004 and Mozilla Corporation was founded in 2005.
According to https://gs.statcounter.com/browser-market-share#yearly-2014-... the high point for adoption was 2010 and it has been falling since then. (However, they only have data from 2010 onwards, so the high point could have been even earlier.) This coincidentally [sic] aligns to the launch of Chrome with a massive marketing push in 2008, promising speed, ease of use and security.
I find it hard to believe that there are enough people who closely follow the drama around the internal financial management and politics of Mozilla Corporation that they can be measured in the tens of percentage points of total internet market share.
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:
> 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.
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 similar <geolocation> element has clickjacking prevention enforced by the browser[0], and even if the website finds a way around it, it still shows the normal permission prompt.[1]
To be sure, evil websites will still be able to put misleading content around the element, and hope that the least savvy users will be fooled or will click the button out of confusion. But they can already do that with the existing JavaScript-triggered permission prompt.
It's kind of insane to me that effort was put into all these fuzzy make-your-site-randomly-not-work heuristics and at the end of the day it still pops open the permission dialog anyway. It's like the worst of both worlds
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.
Opacity is fixed at 1. and obviously you can just break your own site until you get permission, but then people will probably leave before they give your website which has no business accessing the camera permission.
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...
right now sites cant retry prompts because they could just spam annoying permission dialogs in a loop until the user hits allow. thats a problem for legit sites because you have to manually go and grant the permnission from site settings if you change your mind. it adds friction you cant avoid with a script based design.
with a special element dialogs can only show once for every user action. even if the site uses "click to get bitcoin" style misleading prompts users will notice and not click on that button again. none of this is about security in a strict sense, just better ux on both good and bad sites.
I don’t think you can decide the text shown on the permissions element. That’s set by the browser, no?
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.
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.
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.
That is not how standards work. Some for sure, but the majority are established by groups of companies / a guild establishing rules. The law pressures them often into it (e.g. the EU did not say USB-C port, they said: one standard, you industry figure it out).
There are surely exceptions (maybe the IEEE; which are professionals union).
No, this is how good standards bodies works. It require collaboration across nations, sorry but this is like small d democracy stuff here. What isn't good are corporate interests rat fucking engineering practices to pursue greater profits.
I agree all about company creed and also in many cases the standard is the lowest common denominator of their implementations. I am also a fan of putting national sovereignity over profit, but that does not change that in most cases only companies have the interest, the need and the insights to standardize stuff.
[dead]
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.
They claimed and showed QUIC slightly-to-moderately reduced latency, particularly for mobile. This benefits Google by loading pages with third-party content, i.e. ads, faster.
But QUIC significantly increases CPU utilization on servers, at least the widely used userland stacks do. Unless/until Google deploys QUIC in the kernel (or puts the whole network stack in userland, a la DPDK), this won't change.
The multicast claim is kinda bizarre. I can see how QUIC could help eliminate UDP client barriers, but those barriers pale in comparison to multicast. Multicast routing just doesn't exist on the Internet; it's only supported within some independent, typically small networks. Most ISPs don't support it. Wherever you could manage to distribute content with multicast, you'd necessarily also be resolving the collateral routing problems which QUIC support resolves, whereas even ubiquitous QUIC doesn't materially improve the multicast situation.
You can invent your own conclusions all you want. Google’s evidence and motivations are what I stated. Their words, not mine.
I couldn't find any evidence Google pushed QUIC with the aspiration of utilizing IP multicast.
In 2022 an RFC for adding multicast support to QUIC was published, but backed by Akamai, not Google. And of course the RFC has the caveat that it would only be useful over multicast networks, e.g. edge servers colocated at an ISP. It seems this effort has picked up some steam over 2025 and 2026.
But I didn't look too hard. Can you share sources?
Here is a Google Chrome discussion about it from 2018: https://groups.google.com/a/chromium.org/g/proto-quic/c/pAQz...
Here is a quick overview (undated) from Google about it: https://peering.google.com/#/learn-more/quic
The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards to transmission, so the solution in the browser is always open more sockets. However, on the server, the advantages are huge.
You have to understand that multicast is OSI layers 2, 3, and 4. Its layer 2 because it uses a NIC as a local identifier for management apart from other multicast sockets available, UDP and TCP are layer 4 protocols, and it also takes on some layer 3 capabilities for congestion management. This is where the CPU advantage comes in, because you are offloading some of the traffic processing elsewhere in the stack and to network devices, like switches/routers.
Yes, Google has said that part of the motivation was reducing CPU load but I cannot remember where I saw that.
I don't understand the conflation of multiplexing and multicasting. Are we talking about the same multicasting? (https://en.wikipedia.org/wiki/IP_multicast)
Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.
IIRC, QUIC was also the precursor to HTTP/3. I don't like Google's motivations for wanting a faster web, but many of the things they've encouraged and/or provided have made things faster and more efficient. I'm not a google apologist, there's so much wrong and so much harm done... just saying it's maybe worth separating the tech from the motives.
HTTP/3 uses QUIC as the transport layer, which in turn relies on UDP. QUIC replaces TCP while allowing a reduction of handshake exchanges in HTTP/3 first requests. Finally, even though UDP supports multicast, I believe QUIC doesn't. GP saying Google has developed it to use multicast thus is nonsense. Furthermore, QUIC takes much more CPU than TCP right now, due to running in userland.
In my opinion, QUIC and HTTP/3 are technical marvels, but are perhaps way too complicated and don't really serve the interest of most internet users.
There will be a point in the development of web browsers and associated technologies where we should just stop a bit to get things stable instead of churning protocol version after protocol version after new API. Will it ever stop?
Eventually, it all becomes so complicated no company can manage it all. Honestly, we might already be past this point, with Chromium at almost 40mi LOC, more than the Linux kernel itself, including all its drivers. When will the madness stop? Do we really need such complicated software to see Instagram posts, comment on a few Hacker News threads and mess around with Google Sheets?
The biggest reason I worry so much about this is that in the web, adding new features, APIs and protocols is easy. Removing and deprecating is basically impossible.
It's not very complicated to import the QUIC library, or to import the HTTP library with HTTP/3 supported. For the library authors, QUIC isn't more complicated to implement than TCP. Doomsaying about the complexity of Google Sheets is completely unrelated to whether QUIC is good tech and superior to TCP, which it is; the only remaining complaint is that it's too new to have been part of the kernel yet, and if that makes technology somehow illegitimate then I guess we're just stuck with the mistakes of the 90s forever, why ever invent anything new at all.
That is also entirely incorrect. There are many challenges to implementing an original QUIC library. The Node.js project is developing and evaluating for this right now and the effort is extensive.
There are also many challenges to implementing an original TCP library.
> Finally, even though UDP supports multicast, I believe QUIC doesn't.
Don’t confuse the browser for the server. QUIC is UDP but UDP is not QUIC. Unlocking UDP for the browser allows capabilities on the remote end that aren’t available to the browser.
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.
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?
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.
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.
So when would that be exactly? Firefox was first released in 2004 and Mozilla Corporation was founded in 2005.
According to https://gs.statcounter.com/browser-market-share#yearly-2014-... the high point for adoption was 2010 and it has been falling since then. (However, they only have data from 2010 onwards, so the high point could have been even earlier.) This coincidentally [sic] aligns to the launch of Chrome with a massive marketing push in 2008, promising speed, ease of use and security.
I find it hard to believe that there are enough people who closely follow the drama around the internal financial management and politics of Mozilla Corporation that they can be measured in the tens of percentage points of total internet market share.
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:
> 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.
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.
The similar <geolocation> element has clickjacking prevention enforced by the browser[0], and even if the website finds a way around it, it still shows the normal permission prompt.[1]
[0]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLGeoloca...
[1]: https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)
To be sure, evil websites will still be able to put misleading content around the element, and hope that the least savvy users will be fooled or will click the button out of confusion. But they can already do that with the existing JavaScript-triggered permission prompt.
It's kind of insane to me that effort was put into all these fuzzy make-your-site-randomly-not-work heuristics and at the end of the day it still pops open the permission dialog anyway. It's like the worst of both worlds
“targeted and functional controls for accessing camera and microphone streams”
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.
But it’s only showing a button and then the prompt when you click the button. Unless you click the button, it can’t spam you with permissions.
Just make the button transparent over the whole site and make it so you have to accept before it will let you do anything.
Opacity is fixed at 1. and obviously you can just break your own site until you get permission, but then people will probably leave before they give your website which has no business accessing the camera permission.