Hacker News Reader

Every web developer is fine with 10% of the feature set, it’s just a different 10% for each dev. I am regularly annoyed by the inconsistent browser support for Web MIDI, something 99% of web devs probably don’t care about at all.

It would be easier to sandbox if there were fewer features of course, but in practice we rarely see exploits even in complicated low-level APIs like webgpu (which must be a nightmare to make secure given how many buggy drivers and different devices it has to support). So it seems like in practice we are able to sandbox these APIs securely, and having them provides an incredible benefit to users who are able to securely and easily run applications (how else do you recommend people do this on desktop platforms?).

> we rarely see exploits

I can't think of an analogy that doesn't come off crass.

I posit the likelihood the morass that is webgpu not having exploitable bugs approaches 0 approximately 25 seconds after the first public release of the code, if not months prior.

Its only when one of two things occur that publishing happens, basically: intelligent frustration, and "for the lols".

Someone hits a bug and gets pissed that the authors of the libraries blame everyone but the library authors. When working around the bug discover its not just a bug. Warn devs. Sometimes responsible disclosure means a quiet fix and then disclosure, but usually it means "here's the exploit they don't care ig"

If there's not enough curious people poking things, exploitable stuff could remain hidden too long.

> The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake...

There's an obscure use case for this called "Watching Video"

Recipe sites will keep themselves awake also, which is nice.

Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)

That's because there used to be this thing called flash/silverlight that could do this instead. Now, video is done completely differently than it was.

> Now, video is done completely differently than it was.

Which is a thing that happened long before Firefox 126, too. (Browsers have simply requested the screen wakelock themselves when a video was playing. So this API is mainly for use cases that aren't playing a video.)

Indeed. I work on the Firefox media stack and we have been grabbing wake locks when video playback is happening for a long time. Occasionally e.g. on some linux desktop variant this has malfunctioned and we're alerted in no time and fix it.

The Wake Lock API is for other use cases, such as recipe websites, or other document for which you don't want the screen to go away / dim, the kind where you happen to need to look at the screen for long period of time without touching it/interacting w/ mouse and keyboard.

Prior to this API being introduced, websites used to play an inaudible/almost invisible looping media file to keep the screen awake. This has power usage implication, a small single digit number of watts (1 to 3.5 depending on os, hardware, mobile or not) is required to keep audio running (because of high priority threads, frequent wakeups, and simply because the audio hardware itself needs power).

One of those libraries source, for illustration: https://github.com/richtr/NoSleep.js/blob/master/src/index.j...

Bless you. I was driven a little mad once trying to figure out why certain websites would steal audio focus away from music playing on my phone, it must have been some clumsy implementation of this.

> idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous)

I am not a web developer but I completely agree with you. To me, adding more complex points of failure in humongous piles of code that we absolutely need to run in a modern life is not a great risk assessment. It’s like we never learnt from the security issues with the JVM.

> The amount of obscure APIs being added just boosts the surface area for vulnerabilities

It’s often the ancient APIs from around 1995-2001 that are the most vulnerable ones, with information leaking across origins (like todays) needing hacky fixes to stay secure and compatible.

window.open(), target=_blank, cross site request forgery, etc.

IE6 from 2001 had a ton of these modern security issues, and Netscape before it probably had them too.

At that time there were tons of buffer overflow security holes so no on cared about side-channel attacks.

I fully agree, as someone also doing Web development in a similar timeframe, for plenty of stuff we would be better with native apps talking over Internet protocols, no need to transform a platform for interactive documents into a OS.

Well, for better or worse, the web is an application platform these days.

I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely.

There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.

What? I thought Apple was trying to quietly kill pwas, probably bc they don't go thru their app store. And also bc if you make a good enough sandbox then you don't need to pay for "all the wooork we put in"

They certainly don’t have a lot of love for them as a first-class app development environment, but they are also their fig leaf of “open access” to the platform.

Regardless of that, I do like the idea of PWAs getting access to a higher tier of web APIs, especially those increasing the attack surface, as “installing an app” makes even non-sophisticated users do more of a double take than “visiting a website” in terms of access to their system.

iOS just really improved support for pwas sometime in the last part of last years. It's much better.

The first two, screen wake lock and web serial have good use cases imo. I wouldn’t be surprised if some in-use assistive technology uses serial communication - think screen readers or custom input devices. Keeping the screen from locking is also useful from a purely accessible standpoint as well for users who move slower or need more time to read things.

I agree with you, particularly when 90% of sites people visit are to read, watch, or engage with content.