The <usermedia> HTML element(developer.chrome.com) |
The <usermedia> HTML element(developer.chrome.com) |
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...
[0]: https://github.com/mozilla/standards-positions/issues/1288
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.
Meaning they tricked more people into granting permissions they would have otherwise not granted.
It’s a techbros wet dream on consent. Just keep asking until they say yes.
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.
[0]: https://developer.chrome.com/docs/web-platform/element-captu...
[1]: https://developer.chrome.com/docs/web-platform/document-pict...
(I’m a big Firefox fan and idealist.)
Stop getting history twisted.
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?
Embrace. Extend. Extinguish.
We went to this rodeo a generation ago. Nothing was learned.
--
Submitted from Firefox
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.
Approximately at the time when majority of the Mozilla resources started going into non-browser projects. And pretty much for the same reason.
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.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLGeoloca...
[1]: https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)
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.
There are surely exceptions (maybe the IEEE; which are professionals union).
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.
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?
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.
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.
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.
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.