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

21–30 of 59 posts

Re: The <usermedia> HTML element

#21

Post by wahern »

austin-cheney wrote: post #16
sheept wrote: post #15

Earlier quoted context omitted.

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

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.

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.

Re: The <usermedia> HTML element

#22

Post by gorgoiler »

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/

Interesting to see that on Desktop, Firefox (5.8%) just overtook Safari (5.0%) for third place. It doesn’t feel statistically significant but it’s a bit of data at least.

(I’m a big Firefox fan and idealist.)

Re: The <usermedia> HTML element

#23

Post by akersten »

sheept wrote: post #11
unfocso wrote: post #5

Earlier quoted context omitted.

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

The similar 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/HTMLGeoloca... [1]: https://mdn.github.io/dom-examples/geolocation-element/basic... (requires Chromium)

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

Re: The <usermedia> HTML element

#24

Post by akersten »

zamadatix wrote: post #13
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?

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 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 `` element that they mentioned in the article - but then we decided to throw that out, but don't worry, specific `` and `` elements are coming soon.

I'm probably getting too old for this...

Re: The <usermedia> HTML element

#26

Post by qingcharles »

usr1106 wrote: post #4

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.

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.

Re: The <usermedia> HTML element

#27

Post by shimman »

zdragnar wrote: post #10
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/

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…

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.

Re: The <usermedia> HTML element

#28

Post by darig »

shimman wrote: post #27
zdragnar wrote: post #10

Earlier quoted context omitted.

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…

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.

[dead]

Re: The <usermedia> HTML element

#29

Post by oaiey »

shimman wrote: post #27
zdragnar wrote: post #10

Earlier quoted context omitted.

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…

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.

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

Post reply on HN