5 ms·

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

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). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browser that can load almost nothing", and basically nothing in between. I had to stop using Firefox on my old ThinkPad because after opening a few windows, it churns the CPU so hard it's not usable for a solid minute+. Let that finish up, and I have to wait again if I dare to open another page. i5-3220m, 8gb of RAM (where the OS uses like 200mb of RAM)... there's no excuse for this to not be able to browse the web. Some fun examples of "your browser is an OS on top of your OS": 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_Lock_API https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake... The Web Serial API provides a way for websites to read from and write to serial devices. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_... The Window Management API allows you to get detailed information on the displays connected to your device and more easily place windows on specific screens, paving the way towards more effective multi-screen applications. https://developer.mozilla.org/en-US/docs/Web/API/Window_Management_API https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana... The Compute Pressure API is a JavaScript API that enables you to observe the pressure of system resources such as the CPU. https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pressure_API https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pre... (my thesis is, not all web developers want this stuff, and usually when I talk to people in the industry they agree, it's excessive)

lxgr 2y ago
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.
- fennecbutt 2y ago
  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"
  - lxgr 2y ago
    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.
  - indymike 2y ago
    iOS just really improved support for pwas sometime in the last part of last years. It's much better.
Khaine 2y ago
I agree with you, particularly when 90% of sites people visit are to read, watch, or engage with content.
ChadNauseam 2y ago
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?).
- genewitch 2y ago
  > 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.
not_kurt_godel 2y ago
> 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 https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake... There's an obscure use case for this called "Watching Video"
- mikepurvis 2y ago
  Recipe sites will keep themselves awake also, which is nice.
- amatecha 2y ago
  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)
  - withinboredom 2y ago
    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.
    - iggldiggl 2y ago
      > 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.)
  - padenot 2y ago
    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.js https://github.com/richtr/NoSleep.js/blob/master/src/index.j...
collinmanderson 2y ago
> 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.
pjmlp 2y ago
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.
kergonath 2y ago
> 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.
phatskat 2y ago
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.

lxgr 2y ago

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.

fennecbutt 2y ago
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"
- lxgr 2y ago
  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.
- indymike 2y ago
  iOS just really improved support for pwas sometime in the last part of last years. It's much better.

Khaine 2y ago

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

ChadNauseam 2y ago

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

genewitch 2y ago
> 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.

not_kurt_godel 2y ago

> 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 https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake... There's an obscure use case for this called "Watching Video"

mikepurvis 2y ago
Recipe sites will keep themselves awake also, which is nice.
amatecha 2y ago
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)
- withinboredom 2y ago
  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.
  - iggldiggl 2y ago
    > 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.)
- padenot 2y ago
  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.js https://github.com/richtr/NoSleep.js/blob/master/src/index.j...

collinmanderson 2y ago

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

pjmlp 2y ago

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.

kergonath 2y ago

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

phatskat 2y ago

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.