10 ms·

The <usermedia> HTML element

90 points by twapi 3mo ago

usr1106 3mo ago
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.
- qingcharles 3mo ago
  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.
- asqueella 3mo ago
  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-html-element https://w3c.github.io/mediacapture-extensions/#the-usermedia...
- sheept 3mo ago
  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 https://github.com/mozilla/standards-positions/issues/1288
- bescob_ar 3mo ago
  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.
rho138 3mo ago
This won’t get abused. /s
- saagarjha 3mo ago
  How do you see it being abused?
  - unfocso 3mo ago
    "Press here to view the content", there's already plenty in the wild that grant access to notifications with deceptive buttons.
    - cwmoore 3mo ago
      “targeted and functional controls for accessing camera and microphone streams”
    - sheept 3mo ago
      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/HTMLGeolocationElement/invalidReason#value https://developer.mozilla.org/en-US/docs/Web/API/HTMLGeoloca... [1]: https://mdn.github.io/dom-examples/geolocation-element/basic-watch-example/ https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)
      - ameliaquining 3mo ago
        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.
      - akersten 3mo ago
        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
  - 3mo ago
phantomathkg 3mo ago
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/ https://gs.statcounter.com/
- zdragnar 3mo ago
  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.
  - shimman 3mo ago
    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.
    - darig 3mo ago
      [dead]
    - oaiey 3mo ago
      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).
      - shimman 3mo ago
akersten 3mo ago
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?
- zamadatix 3mo ago
  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.
  - akersten 3mo ago
    > 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...
    - tancop 3mo ago
      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.
felooboolooomba 3mo ago
Anything new I have to block so my ass can't be fingerprinted?
- gruez 3mo ago
  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
- oaiey 3mo ago
  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.
wackget 3mo ago
[dead]
a_paddy 3mo ago
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.
hiccuphippo 3mo ago
> 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.
hollow-moe 3mo ago
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:

90 points by twapi 3mo ago

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.

qingcharles 3mo ago
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.
asqueella 3mo ago
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-html-element https://w3c.github.io/mediacapture-extensions/#the-usermedia...
sheept 3mo ago
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 https://github.com/mozilla/standards-positions/issues/1288
bescob_ar 3mo ago
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.

rho138 3mo ago

This won’t get abused. /s

saagarjha 3mo ago
How do you see it being abused?
- unfocso 3mo ago
  "Press here to view the content", there's already plenty in the wild that grant access to notifications with deceptive buttons.
  - cwmoore 3mo ago
    “targeted and functional controls for accessing camera and microphone streams”
  - sheept 3mo ago
    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/HTMLGeolocationElement/invalidReason#value https://developer.mozilla.org/en-US/docs/Web/API/HTMLGeoloca... [1]: https://mdn.github.io/dom-examples/geolocation-element/basic-watch-example/ https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)
    - ameliaquining 3mo ago
      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.
    - akersten 3mo ago
      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
- 3mo ago

phantomathkg 3mo ago

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/ https://gs.statcounter.com/

zdragnar 3mo ago
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.
- shimman 3mo ago
  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.
  - darig 3mo ago
    [dead]
  - oaiey 3mo ago
    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).
    - shimman 3mo ago

akersten 3mo ago

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?

zamadatix 3mo ago
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.
- akersten 3mo ago
  > 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...
  - tancop 3mo ago
    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.

felooboolooomba 3mo ago

Anything new I have to block so my ass can't be fingerprinted?

gruez 3mo ago
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
oaiey 3mo ago
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.

wackget 3mo ago

[dead]

a_paddy 3mo ago

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.

hiccuphippo 3mo ago

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

hollow-moe 3mo ago

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: