The <Usermedia> HTML Element

The <Usermedia> HTML Element(developer.chrome.com)

34 points by twapi 2 hours ago | 15 comments

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/

zdragnar 1 hour 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.

sheept 1 hour ago | |

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

austin-cheney 33 minutes ago | | |

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.

akersten 1 hour 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 1 hour 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.

usr1106 2 hours 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.

sheept 1 hour 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

asqueella 2 hours 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...

felooboolooomba 1 hour ago |

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

rho138 2 hours ago |

This won’t get abused. /s

saagarjha 2 hours ago | |

How do you see it being abused?

unfocso 2 hours ago | | |

"Press here to view the content", there's already plenty in the wild that grant access to notifications with deceptive buttons.