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

11–20 of 59 posts

Re: The <usermedia> HTML element

#11

Post by sheept »

unfocso wrote: post #5
saagarjha wrote: post #3

Earlier quoted context omitted.

How do you see it being abused?

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

Re: The <usermedia> HTML element

#13

Post by zamadatix »

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.

Re: The <usermedia> HTML element

#14

Post by sheept »

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.

At the very least, Firefox's position on the similar 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

Re: The <usermedia> HTML element

#15

Post by sheept »

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/

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

Re: The <usermedia> HTML element

#16

Post by austin-cheney »

sheept wrote: post #15
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/

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.

Re: The <usermedia> HTML element

#18

Post by chrisweekly »

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.

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.

Re: The <usermedia> HTML element

#19

Post by ameliaquining »

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)

To be sure, evil websites will still be able to put misleading content around the element, and hope that the least savvy users will be fooled or will click the button out of confusion. But they can already do that with the existing JavaScript-triggered permission prompt.

Re: The <usermedia> HTML element

#20

Post by doodlesdev »

chrisweekly wrote: post #18
austin-cheney wrote: post #16

Earlier quoted context omitted.

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.

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

Post reply on HN