Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTML element

developer.chrome.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: The <usermedia> HTML element

#41

Post by austin-cheney »

doodlesdev wrote: post #20
chrisweekly wrote: post #18

Earlier quoted context omitted.

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 a…

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

Re: The <usermedia> HTML element

#42

Post by austin-cheney »

pie_flavor wrote: post #32
doodlesdev wrote: post #20

Earlier quoted context omitted.

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 a…

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 ma…

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.

Re: The <usermedia> HTML element

#43

Post by echoangle »

akersten wrote: post #24
zamadatix wrote: post #13

Earlier quoted context omitted.

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 conten…

I don’t think you can decide the text shown on the permissions element. That’s set by the browser, no?

Re: The <usermedia> HTML element

#44

Post by echoangle »

rho138 wrote: post #40
saagarjha wrote: post #3

Earlier quoted context omitted.

How do you see it being abused?

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.

Re: The <usermedia> HTML element

#45

Post by dividuum »

akersten wrote: post #8

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?

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.

Re: The <usermedia> HTML element

#46

Post by wahern »

austin-cheney wrote: post #39
wahern wrote: post #21

Earlier quoted context omitted.

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…

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?

Re: The <usermedia> HTML element

#47

Post by timando »

echoangle wrote: post #44
rho138 wrote: post #40

Earlier quoted context omitted.

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.

Re: The <usermedia> HTML element

#48

Post by austin-cheney »

wahern wrote: post #46
austin-cheney wrote: post #39

Earlier quoted context omitted.

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

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.

Re: The <usermedia> HTML element

#49

Post by reaperducer »

phantomathkg wrote: post #7

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/

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.

Re: The <usermedia> HTML element

#50

Post by echoangle »

timando wrote: post #47
echoangle wrote: post #44

Earlier quoted context omitted.

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.
Post reply on HN