The <Usermedia> HTML Element(developer.chrome.com)
41 pointsby twapi3 hours ago6 comments
  • phantomathkg3 hours 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/

    • gorgoiler2 minutes ago
      [delayed]
    • zdragnar2 hours 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.

    • sheept2 hours 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-cheneyan hour 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.
        • wahern10 minutes ago
          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.

        • chrisweekly33 minutes ago
          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.
          • doodlesdev18 minutes ago
            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.

            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.

  • akersten2 hours 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?
    • zamadatix2 hours 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.
  • usr11063 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.
  • felooboolooomba2 hours ago
    Anything new I have to block so my ass can't be fingerprinted?
  • wackget34 minutes ago
    [dead]
  • rho1383 hours ago
    This won’t get abused. /s
    • saagarjha3 hours ago
      How do you see it being abused?
      • unfocso3 hours ago
        "Press here to view the content", there's already plenty in the wild that grant access to notifications with deceptive buttons.