8 ms·

I find the push to turn web browsers into VMs for running sandboxed JavaScript/WebAssembly applications fascinating. WebUSB, WebGPU, WebTransport, etc etc. I th

I find the push to turn web browsers into VMs for running sandboxed JavaScript/WebAssembly applications fascinating. WebUSB, WebGPU, WebTransport, etc etc. I think it's really cool, and enables cool things, but I have 1 problem with it. I wish we separated the browser application from the VM application. ie, let us make simple, secure content with HTML and minimal CSS. For things like Wikipedia and even a lot of YouTube that's all you need. People can use an extremely simple (and private/secure!) program to access this kind of content. A text version of my personal site is browsable with cURL or even netcat[0]. Make the VM a separate program that people use for fancy web apps. [0]: https://anderspitman.net/19/#netcatable https://anderspitman.net/19/#netcatable

ar-nelson 7y ago
This is how the Web was originally designed, which is why we had Flash and Java applets. But it's hard to make those VMs secure, and yet somehow it's been easier to keep modern browsers reasonably secure as they keep adding features.
- anderspitman 7y ago
  One problem is that browser vendors are using the complexity of modern browsers to create an oligopoly. When even Microsoft doesn't want to maintain their own browser, something is wrong. A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.
  - api 7y ago
    The driver is the desire by web app builders to build more and more niftiness into web apps. The browser vendors and standards bodies are attempting to satisfy this desire and that's leading down a path that is having the effect of creating an oligopoly because a browser must become this enormous OS-inside-an-OS. I don't think it's a conspiracy. Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems. A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.
    - redwall_hp 7y ago
      Flash reached a point where it was basically unmaintainable spaghetti, and not something that was going to be trivially reimplemented by a third party. Sadly, that's exactly what's happening to the Web now. Instead of being standards-first, and browsers implement it, we've basically shifted to descriptive standards that attempt to formalize what a corporate cabal unilaterally decides. And we're in inch away from a homogeny of browser engines...
      - bawolff 7y ago
        Well multilaterally decide. Its a small group but firefox isnt totally irrelavent yet. And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.
    - anderspitman 7y ago
      You're not wrong, but people have been pointing these issues out for years, and browser vendors are very aware of these opinions, and have taken no serious action I can see to realign their incentives. EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.
- thu2111 7y ago
  There's no mystery to it. Look at Firefox. It's actually not more secure than old Java used to be. It has CVEs all the time. Chrome constantly patches security bugs too. The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing. But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.
deleted 7y ago
[deleted]
JohnFen 7y ago
I really wish this is the direction the web would go. This "browser as OS" stuff isn't something that I'm even a little OK with, and I'd love to have a browser that simply didn't have the support for any of it.
- VoxPelli 7y ago
  Deactivate javascript: Done
  - progval 7y ago
    And then you can't see the article, because its CSS hides the text and Javascript un-hides it; and people call you an extremist.
    - VoxPelli 7y ago
      That's not a good way to handle it, harmful to the web :/
    - gpderetta 7y ago
      I wish there was a reader mode only browser. You would need to somehow extract navigational links though.
    - deleted 7y ago
      [deleted]
  - JohnFen 7y ago
    Yes, I do that already, but that doesn't remove the code in the browser. Also, I'd really love a JS interpreter that was restrictive enough that I could leave it on without exposing me to this stuff.
    - VoxPelli 7y ago
      Not just an interpreter – unless there's a standardized subset that one can look for as a web developer then one can't really adopt to it (through either graceful degradation or progressive enhancement). Same reason why eg. Noscript addons creates havoc at times. Web sites expects a certain baseline and when it's not there, they expect that javascript will be disabled altogether and <noscript>-tags to get executed, but just disabling some code prohibits that fallback, making it less usable than fully disabling js.
untog 7y ago
And it's entirely possible to do that today. Things like WebUSB require permission prompts, which you can say no to or disable entirely.
roca 7y ago
> let us make simple, secure content with HTML and minimal CSS. Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS. Your problem isn't with browsers, it's with Web developers who don't share your priorities.
- clSTophEjUdRanu 7y ago
  *it's users who don't share your priorities.
  - javajosh 7y ago
    *it's Capital that doesn't share your priorities.
  - roca 7y ago
    That too.
- anderspitman 7y ago
  Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>
  - roca 7y ago
    Sorry but this vision is totally unrealistic. You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site. Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.
svnpenn 7y ago
You used to be able to do this: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application
- at_a_remove 7y ago
  Don't laugh but I made one of these last year, just needed something dead simple.
  - svnpenn 7y ago
    For a more modern solution, you could use PHP or similar: https://cup.github.io/rosso/html-application https://cup.github.io/rosso/html-application
    - at_a_remove 7y ago
      No, I mean I made something that I didn't have to install anything for. PHP wasn't on the machine. But I could do .hta. Boom.
- bawolff 7y ago
  And now we have electron. Everything old is new again.
baroomba 7y ago
HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least). Example: Table sorting. Hell, maybe table pagination, too. This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript. Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that. Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources. There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening. I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".
- anderspitman 7y ago
ptx 7y ago
That text protocol is pretty much what HTTP looked like originally[1]. If you just support an optional "GET " before the document path, you'll essentially have an implementation of HTTP 0.9. [1] https://www.w3.org/Protocols/HTTP/AsImplemented.html https://www.w3.org/Protocols/HTTP/AsImplemented.html
- anderspitman 7y ago
  Yup. Once I got to the point I was considering adding support for range requests for streaming videos, I figured it would make more sense to implement a subset of HTTP. HTTP started as a pretty dang good protocol and I really hope we never full ditch HTTP/1.1 in favor of the newer binary versions. I'm all for progress, but simple things should remain simple.
pjmlp 7y ago
I agree, but at this stage the Chrome VM has won. Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it. Ironically it were the IE haters that kind of helped this to happen.
sandoooo 7y ago
So what you're saying is we should build a browser inside the browser sandbox?
boring_twenties 7y ago
Not exactly related but you might enjoy curling this website: https://wttr.in https://wttr.in

ar-nelson 7y ago

This is how the Web was originally designed, which is why we had Flash and Java applets. But it's hard to make those VMs secure, and yet somehow it's been easier to keep modern browsers reasonably secure as they keep adding features.

anderspitman 7y ago
One problem is that browser vendors are using the complexity of modern browsers to create an oligopoly. When even Microsoft doesn't want to maintain their own browser, something is wrong. A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.
- api 7y ago
  The driver is the desire by web app builders to build more and more niftiness into web apps. The browser vendors and standards bodies are attempting to satisfy this desire and that's leading down a path that is having the effect of creating an oligopoly because a browser must become this enormous OS-inside-an-OS. I don't think it's a conspiracy. Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems. A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.
  - redwall_hp 7y ago
    Flash reached a point where it was basically unmaintainable spaghetti, and not something that was going to be trivially reimplemented by a third party. Sadly, that's exactly what's happening to the Web now. Instead of being standards-first, and browsers implement it, we've basically shifted to descriptive standards that attempt to formalize what a corporate cabal unilaterally decides. And we're in inch away from a homogeny of browser engines...
    - bawolff 7y ago
      Well multilaterally decide. Its a small group but firefox isnt totally irrelavent yet. And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.
  - anderspitman 7y ago
    You're not wrong, but people have been pointing these issues out for years, and browser vendors are very aware of these opinions, and have taken no serious action I can see to realign their incentives. EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.
thu2111 7y ago
There's no mystery to it. Look at Firefox. It's actually not more secure than old Java used to be. It has CVEs all the time. Chrome constantly patches security bugs too. The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing. But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.

deleted 7y ago

[deleted]

JohnFen 7y ago

I really wish this is the direction the web would go. This "browser as OS" stuff isn't something that I'm even a little OK with, and I'd love to have a browser that simply didn't have the support for any of it.

VoxPelli 7y ago
Deactivate javascript: Done
- progval 7y ago
  And then you can't see the article, because its CSS hides the text and Javascript un-hides it; and people call you an extremist.
  - VoxPelli 7y ago
    That's not a good way to handle it, harmful to the web :/
  - gpderetta 7y ago
    I wish there was a reader mode only browser. You would need to somehow extract navigational links though.
  - deleted 7y ago
    [deleted]
- JohnFen 7y ago
  Yes, I do that already, but that doesn't remove the code in the browser. Also, I'd really love a JS interpreter that was restrictive enough that I could leave it on without exposing me to this stuff.
  - VoxPelli 7y ago
    Not just an interpreter – unless there's a standardized subset that one can look for as a web developer then one can't really adopt to it (through either graceful degradation or progressive enhancement). Same reason why eg. Noscript addons creates havoc at times. Web sites expects a certain baseline and when it's not there, they expect that javascript will be disabled altogether and <noscript>-tags to get executed, but just disabling some code prohibits that fallback, making it less usable than fully disabling js.

untog 7y ago

And it's entirely possible to do that today. Things like WebUSB require permission prompts, which you can say no to or disable entirely.

roca 7y ago

> let us make simple, secure content with HTML and minimal CSS. Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS. Your problem isn't with browsers, it's with Web developers who don't share your priorities.

clSTophEjUdRanu 7y ago
*it's users who don't share your priorities.
- javajosh 7y ago
  *it's Capital that doesn't share your priorities.
- roca 7y ago
  That too.
anderspitman 7y ago
Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>
- roca 7y ago
  Sorry but this vision is totally unrealistic. You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site. Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.

svnpenn 7y ago

You used to be able to do this: https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application

at_a_remove 7y ago
Don't laugh but I made one of these last year, just needed something dead simple.
- svnpenn 7y ago
  For a more modern solution, you could use PHP or similar: https://cup.github.io/rosso/html-application https://cup.github.io/rosso/html-application
  - at_a_remove 7y ago
    No, I mean I made something that I didn't have to install anything for. PHP wasn't on the machine. But I could do .hta. Boom.
bawolff 7y ago
And now we have electron. Everything old is new again.

baroomba 7y ago

HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least). Example: Table sorting. Hell, maybe table pagination, too. This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript. Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that. Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources. There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening. I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".

anderspitman 7y ago

ptx 7y ago

That text protocol is pretty much what HTTP looked like originally[1]. If you just support an optional "GET " before the document path, you'll essentially have an implementation of HTTP 0.9. [1] https://www.w3.org/Protocols/HTTP/AsImplemented.html https://www.w3.org/Protocols/HTTP/AsImplemented.html

anderspitman 7y ago
Yup. Once I got to the point I was considering adding support for range requests for streaming videos, I figured it would make more sense to implement a subset of HTTP. HTTP started as a pretty dang good protocol and I really hope we never full ditch HTTP/1.1 in favor of the newer binary versions. I'm all for progress, but simple things should remain simple.

pjmlp 7y ago

I agree, but at this stage the Chrome VM has won. Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it. Ironically it were the IE haters that kind of helped this to happen.

sandoooo 7y ago

So what you're saying is we should build a browser inside the browser sandbox?

boring_twenties 7y ago

Not exactly related but you might enjoy curling this website: https://wttr.in https://wttr.in