26 ms·

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) for requesting/providing filesystem, networking, graphics, etc resources (if you think this sounds like java, see [0]). And I think there's room for diversity here. I can imagine a world where it's normal to have 3-4 different app runners installed on your system. Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app. [0]: https://steveklabnik.com/writing/is-webassembly-the-return-of-java-applets-flash https://steveklabnik.com/writing/is-webassembly-the-return-o...

bastawhiz 6y ago
> Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app. We had this. ActiveX, Flash, Director, Air, Silverlight, Java. It was a mess, and I think you'd be hard pressed to find very many folks who found it desirable.
- anderspitman 6y ago
  There are reasons each of those failed that have little to do with the core concept. And to be honest, I think Flash was killed before there was a suitable replacement to fill the gap. It took more than 10 years since it "died" to actually get rid of it, because HTML5 isn't actually up to the task. I think the fact that it survived so long proves there's a use for these types of runtimes.
  - danShumway 6y ago
    I've commented before on this subject, but Flash didn't survive because it took HTML5 10 years fill in the gap. Flash survived because: A) enterprises don't upgrade or move away from technologies period (we still support IE11 and old Windows Server deployments at my current company). B) Flash the authoring tool never got replaced. It's not about whether or not HTML5 is up to the task of being a Flash-equivalent runtime, nobody built a replacement for Macromedia/Adobe Flash targeting any runtime anywhere. To this day, there is not a vector animation tool on par with Flash for any platform, and that has nothing to do with the capabilities of the web. People blame HTML5 when what really happened was Adobe abandoned their authoring tools and nobody built an alternative because we expected the W3C or somebody to do it for us. But a programming language will never be a replacement for a full-featured content creation tool and IDE. Even WASM is not going to replace Flash unless some company or group somewhere actually sits down and writes a native program that can target it and that is actually competitive with what Flash the authoring tool offered devs. I have not seen serious effort in that direction, so if you're hoping WASM just magically makes these problems go away, I'm a little less optimistic about that. WASM is just going to be another runtime target -- a good one, but not a replacement for an IDE.
    - anderspitman 6y ago
      Yes, my point would more accurately be made by replacing "HTML5" with "HTML5 platform/ecosystem". Your point about Wasm not automatically guaranteeing this is important. But it would be much easier to build such a tool for a simple greenfield runtime than for a modern browser.
      - danShumway 6y ago
        I have reasonably high hopes for WASM as a runtime, so I'm trying to thread a line between agreeing with you and disagreeing with you. I do think that compiling C code to WASM is easier than compiling C code to Javascript, and I do think that WASM is going to open some doors to sandboxed native applications that the web just can't handle. But at the same time, even forgetting about the cross-platform part, I have not seen an application framework for any platform -- even closed-down, highly consistent platforms like game consoles -- that offers the same feature-set as Flash. So WASM may make this easier, but we have platforms already today that are extremely easy to target. If you're targeting PS4/XBox, you know exactly what drivers, software, and graphics stacks are going to be installed. And a Flash replacement doesn't exist for any of those devices. So I urge some caution about assuming that the tools you want are going to be quickly built for WASM. In some ways, this is exactly the mistake that HTML5 advocates made with Flash. They assumed that all they needed to do was have APIs, and Adobe would do something to save Flash. But Adobe never really seemed to care. They had some half-hearted efforts to target devices like Android, but the Air runtime was never really good at that, and it didn't take over as a cross-platform desktop target the same way that modern Electron has. It seems intuitively obvious that if a cross-platform runtime existed that everyone loved, somebody would make a good graphics stack for it that was easy to use and that didn't require programming, but I'm not 100% certain that's actually true.
        anderspitman 6y ago
        I think we're disagreeing less than you think, mostly just focusing on different things. I'll defer to you on Flash. I've never programmed in it directly. My observations are purely from the outside. I was just using it as an example for why I see potential in app runtimes.
skybrian 6y ago
It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete implementations exist. (Such as in browsers and operating systems.) And they need to keep moving as the culture changes; you want to support the latest emojis, right? Well maybe you don't, but your users will. Furthermore, these implementations are at least partially specific to particular programming languages. If you want something portable, you might build on the Skia graphics library but that won't give you a way to build an app on its own.
- Ajedi32 6y ago
  Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg. For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential management, etc; the list goes on. That isn't to say there couldn't some day be a simpler alternative to the web offering similar features; but it has some pretty stiff competition. The only thing that even comes close today are modern operating systems like iOS and Android; and none of those are open standards like the web is.
  - anderspitman 6y ago
    Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.
    - Ajedi32 6y ago
      They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.
nynx 6y ago
A significant point of wasm is runtime-independence. If a runtime implements the right apis, any wasm module that uses them should be able to run (performance aside).
- eitland 6y ago
  Don't underestimate programmers and especially web developer when it comes to making software dependent on IE or Chrome just because they can't be bothered to do any QA ;-) Full disclosure: I am a developer, and I use and always used Firefox, for both pragmatic and ideological reasons.
  - devwastaken 6y ago
    Chrome impliments the necessary features for wasm and webgl. Here's a test: checkaux.github.io Mobile firefox lacks simd, i haven't been able to get its shared memory to work on a local or deployed environment because of bugs in what it thinks is a 'secure context' Desktop and mobile Firefox does not support OffscreenCanvas without turning on flags. It's been years since this was meant to be made. Therefore you cannot use seperate threads to render to webgl without using less performant workarounds. Lack of proper threading means bad page performance. There's lots more dumb bugs and features firefox said it would support and simply never did. Understand there's real reasons as to why chrome is the preferred. it works and it actually puts in the necessary features.
    - kaba0 6y ago
      Then there is no point in having a browser platform, because we are back where we started from. Then why don’t we simply run JVM apps, there are at least a handful of implementations, and it has at least a decent GUI (half joking here). But really, the JVM is where WASM may be several years later.
      - devwastaken 6y ago
        VM's are not all the same, and a VM does not at all guarantee security. The JVM is not designed to run arbitrary code and/or is not as well designed to do it as Javascript or Wasm is. If it were as simple as plug JVM into browser it would be done. However it's not, because the memory and execution safety measures are better in Javascript and Wasm. Wasm should actually have better isolation than JS. If you want to know the details go read the spec and look at the implimentations.
syrusakbary 6y ago
Completely agree with that. I think Wasm has the potential to become the lingua franca for software. It allows containerization in a much lighter way than virtualization (KVM), but also in a platform-agnostic way. We have a very interesting future ahead of us!
hctaw 6y ago
You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and they're big and complicated like OSes by necessity, not accident.
- amelius 6y ago
  All the things you mention could be available as a shared library, to be run inside the sandbox along with the application. Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.
  - nynx 6y ago
    While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. Perhaps that's not a bad thing. Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.
    - reader_mode 6y ago
      >While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. You can compile existing GUI libraries you just need to port the rendering backend and input. Flutter, Qt, GTK, etc.
      - dagmx 6y ago
        For example, Qt already has a port to wasm
  - hctaw 6y ago
brundolf 6y ago
As others are pointing out here: the cross-platform value-add of browser based apps is the GUI layer, not the code runtime. We've had the JVM for decades, and it even has a GUI layer, it's just a much less powerful GUI layer than today's web. People have been trying to create a simple, native, platform-agnostic GUI layer for as long as GUIs have existed. Nothing but the web has ever come close to succeeding. It may be a flawed solution, but it's what we have, and it works, and I wouldn't hold my breath for a greenfield alternative supplanting it any time soon.
- josephg 6y ago
  The other big thing the web provides a standard way to do distribution. Unlike JVM apps, I don’t need to install Gmail to use it on my computer.
  - anderspitman 6y ago
    The web is a great way to distribute native programs. Click a URL to download, then run.
    - charrondev 6y ago
      I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.
      - anderspitman 6y ago
        That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.
        josephg 6y ago
phkahler 6y ago
>> Browsers are not the right tool for sandboxing applications. Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.
- enos_feedler 6y ago
  When the browser first came out, the OS didn't even have a native TCP/IP stack! The internet was an app you installed. For a long time the core purpose of the browser was to pickup the slack/gap in the OS treating the internet as a first class thing. Now, as the internet clams down a bit, the OS handles everything natively, including the security primitives (at least on mobile) and so the purpose of the browser is sadly diminishing. It's a less useful experimental side channel to the OS.
cortesoft 6y ago
It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.
- anderspitman 6y ago
  Ha, you're actually kind of right. That article doesn't quite say what I remembered it saying. Been a while since I read it. I'd say about half the points are still applicable, but it is more pro-browser than me for sure. Too late to edit, but Steve's previous blog post probably presents my point better, though with less focus on the vs Java argument: https://steveklabnik.com/writing/webassembly-is-more-than-just-the-web https://steveklabnik.com/writing/webassembly-is-more-than-ju...
higerordermap 6y ago
A JIT is just more attack surface. Change my mind.
flohofwoe 6y ago
The idea makes a lot of sense, but it all comes down to the system-level APIs that this application-runner would provide. Should it be Web-APIs? Then you're essentially rewriting the browser, maybe minus the DOM, CSS and JS. Should it be the Windows APIs? Then you're essentially rewriting Windows above the kernel. Just POSIX? Then what about applications that need rendering and sound. Do you invent your own cross-platform APIs? It's a massive undertaking, and without the momentum that the web had and has, it'll be tough to make this application runner popular among devs and users.

bastawhiz 6y ago

> Developers would target one of these runners for their app, depending on needs (performance, GUI libs provided, security guarantees, etc), and tell you which app runner you need for the app. We had this. ActiveX, Flash, Director, Air, Silverlight, Java. It was a mess, and I think you'd be hard pressed to find very many folks who found it desirable.

anderspitman 6y ago
There are reasons each of those failed that have little to do with the core concept. And to be honest, I think Flash was killed before there was a suitable replacement to fill the gap. It took more than 10 years since it "died" to actually get rid of it, because HTML5 isn't actually up to the task. I think the fact that it survived so long proves there's a use for these types of runtimes.
- danShumway 6y ago
  I've commented before on this subject, but Flash didn't survive because it took HTML5 10 years fill in the gap. Flash survived because: A) enterprises don't upgrade or move away from technologies period (we still support IE11 and old Windows Server deployments at my current company). B) Flash the authoring tool never got replaced. It's not about whether or not HTML5 is up to the task of being a Flash-equivalent runtime, nobody built a replacement for Macromedia/Adobe Flash targeting any runtime anywhere. To this day, there is not a vector animation tool on par with Flash for any platform, and that has nothing to do with the capabilities of the web. People blame HTML5 when what really happened was Adobe abandoned their authoring tools and nobody built an alternative because we expected the W3C or somebody to do it for us. But a programming language will never be a replacement for a full-featured content creation tool and IDE. Even WASM is not going to replace Flash unless some company or group somewhere actually sits down and writes a native program that can target it and that is actually competitive with what Flash the authoring tool offered devs. I have not seen serious effort in that direction, so if you're hoping WASM just magically makes these problems go away, I'm a little less optimistic about that. WASM is just going to be another runtime target -- a good one, but not a replacement for an IDE.
  - anderspitman 6y ago
    Yes, my point would more accurately be made by replacing "HTML5" with "HTML5 platform/ecosystem". Your point about Wasm not automatically guaranteeing this is important. But it would be much easier to build such a tool for a simple greenfield runtime than for a modern browser.
    - danShumway 6y ago
      I have reasonably high hopes for WASM as a runtime, so I'm trying to thread a line between agreeing with you and disagreeing with you. I do think that compiling C code to WASM is easier than compiling C code to Javascript, and I do think that WASM is going to open some doors to sandboxed native applications that the web just can't handle. But at the same time, even forgetting about the cross-platform part, I have not seen an application framework for any platform -- even closed-down, highly consistent platforms like game consoles -- that offers the same feature-set as Flash. So WASM may make this easier, but we have platforms already today that are extremely easy to target. If you're targeting PS4/XBox, you know exactly what drivers, software, and graphics stacks are going to be installed. And a Flash replacement doesn't exist for any of those devices. So I urge some caution about assuming that the tools you want are going to be quickly built for WASM. In some ways, this is exactly the mistake that HTML5 advocates made with Flash. They assumed that all they needed to do was have APIs, and Adobe would do something to save Flash. But Adobe never really seemed to care. They had some half-hearted efforts to target devices like Android, but the Air runtime was never really good at that, and it didn't take over as a cross-platform desktop target the same way that modern Electron has. It seems intuitively obvious that if a cross-platform runtime existed that everyone loved, somebody would make a good graphics stack for it that was easy to use and that didn't require programming, but I'm not 100% certain that's actually true.
      - anderspitman 6y ago
        I think we're disagreeing less than you think, mostly just focusing on different things. I'll defer to you on Flash. I've never programmed in it directly. My observations are purely from the outside. I was just using it as an example for why I see potential in app runtimes.

skybrian 6y ago

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete implementations exist. (Such as in browsers and operating systems.) And they need to keep moving as the culture changes; you want to support the latest emojis, right? Well maybe you don't, but your users will. Furthermore, these implementations are at least partially specific to particular programming languages. If you want something portable, you might build on the Skia graphics library but that won't give you a way to build an app on its own.

Ajedi32 6y ago
Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg. For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential management, etc; the list goes on. That isn't to say there couldn't some day be a simpler alternative to the web offering similar features; but it has some pretty stiff competition. The only thing that even comes close today are modern operating systems like iOS and Android; and none of those are open standards like the web is.
- anderspitman 6y ago
  Most of the things you listed apply to web documents more than web apps. I'm an advocate for separating the two. The UX for browsers is great for what they were designed to do. Running apps is not it.
  - Ajedi32 6y ago
    They apply to both documents _and_ web apps, and the behavior is standard across both. When I hit "Back" or Ctrl+F in a web-based chat application the result is the same as when I do those actions while browsing a news article, and that's a good thing.

nynx 6y ago

A significant point of wasm is runtime-independence. If a runtime implements the right apis, any wasm module that uses them should be able to run (performance aside).

eitland 6y ago
Don't underestimate programmers and especially web developer when it comes to making software dependent on IE or Chrome just because they can't be bothered to do any QA ;-) Full disclosure: I am a developer, and I use and always used Firefox, for both pragmatic and ideological reasons.
- devwastaken 6y ago
  Chrome impliments the necessary features for wasm and webgl. Here's a test: checkaux.github.io Mobile firefox lacks simd, i haven't been able to get its shared memory to work on a local or deployed environment because of bugs in what it thinks is a 'secure context' Desktop and mobile Firefox does not support OffscreenCanvas without turning on flags. It's been years since this was meant to be made. Therefore you cannot use seperate threads to render to webgl without using less performant workarounds. Lack of proper threading means bad page performance. There's lots more dumb bugs and features firefox said it would support and simply never did. Understand there's real reasons as to why chrome is the preferred. it works and it actually puts in the necessary features.
  - kaba0 6y ago
    Then there is no point in having a browser platform, because we are back where we started from. Then why don’t we simply run JVM apps, there are at least a handful of implementations, and it has at least a decent GUI (half joking here). But really, the JVM is where WASM may be several years later.
    - devwastaken 6y ago
      VM's are not all the same, and a VM does not at all guarantee security. The JVM is not designed to run arbitrary code and/or is not as well designed to do it as Javascript or Wasm is. If it were as simple as plug JVM into browser it would be done. However it's not, because the memory and execution safety measures are better in Javascript and Wasm. Wasm should actually have better isolation than JS. If you want to know the details go read the spec and look at the implimentations.

syrusakbary 6y ago

Completely agree with that. I think Wasm has the potential to become the lingua franca for software. It allows containerization in a much lighter way than virtualization (KVM), but also in a platform-agnostic way. We have a very interesting future ahead of us!

hctaw 6y ago

You've just described the hardest parts of a web browser, while ignoring the necessity of a JIT compiler for your bytecode. To give proof by counterexample, the "simple wrapper" is a graphics stack like GTK alongside the POSIX APIs. It turns out this is insufficient for application development. Some things you're missing are text layout and accessibility. Neither are small or simple. The browser is the new OS and they're big and complicated like OSes by necessity, not accident.

amelius 6y ago
All the things you mention could be available as a shared library, to be run inside the sandbox along with the application. Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.
- nynx 6y ago
  While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. Perhaps that's not a bad thing. Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.
  - reader_mode 6y ago
    >While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. You can compile existing GUI libraries you just need to port the rendering backend and input. Flutter, Qt, GTK, etc.
    - dagmx 6y ago
      For example, Qt already has a port to wasm
- hctaw 6y ago

brundolf 6y ago

As others are pointing out here: the cross-platform value-add of browser based apps is the GUI layer, not the code runtime. We've had the JVM for decades, and it even has a GUI layer, it's just a much less powerful GUI layer than today's web. People have been trying to create a simple, native, platform-agnostic GUI layer for as long as GUIs have existed. Nothing but the web has ever come close to succeeding. It may be a flawed solution, but it's what we have, and it works, and I wouldn't hold my breath for a greenfield alternative supplanting it any time soon.

josephg 6y ago
The other big thing the web provides a standard way to do distribution. Unlike JVM apps, I don’t need to install Gmail to use it on my computer.
- anderspitman 6y ago
  The web is a great way to distribute native programs. Click a URL to download, then run.
  - charrondev 6y ago
    I think you missed a step: - click a URL to download an installer. - run the installer that has access to large portions of your system (or if it’s an older windows program probably needs to be run as an administrator so it can add an auto updated or some nonsense like that). - run your program.
    - anderspitman 6y ago
      That's unnecessary. I ship my apps as single-file executables that are ready to go. In the worst case you can use a directory like zoom does (on Linux at least) which contains all the libraries and dependencies you need.
      - josephg 6y ago

phkahler 6y ago

>> Browsers are not the right tool for sandboxing applications. Browsers have been picking up the slack where OS and desktop developers have fallen down. The OS is supposed to handle process isolation and resource access, but here we are. Tabbed browsing became a thing because GUI toolkits didn't do multiple app instances (or MDI) in a way people liked.

enos_feedler 6y ago
When the browser first came out, the OS didn't even have a native TCP/IP stack! The internet was an app you installed. For a long time the core purpose of the browser was to pickup the slack/gap in the OS treating the internet as a first class thing. Now, as the internet clams down a bit, the OS handles everything natively, including the security primitives (at least on mobile) and so the purpose of the browser is sadly diminishing. It's a less useful experimental side channel to the OS.

cortesoft 6y ago

It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.

anderspitman 6y ago
Ha, you're actually kind of right. That article doesn't quite say what I remembered it saying. Been a while since I read it. I'd say about half the points are still applicable, but it is more pro-browser than me for sure. Too late to edit, but Steve's previous blog post probably presents my point better, though with less focus on the vs Java argument: https://steveklabnik.com/writing/webassembly-is-more-than-just-the-web https://steveklabnik.com/writing/webassembly-is-more-than-ju...

higerordermap 6y ago

A JIT is just more attack surface. Change my mind.

flohofwoe 6y ago

The idea makes a lot of sense, but it all comes down to the system-level APIs that this application-runner would provide. Should it be Web-APIs? Then you're essentially rewriting the browser, maybe minus the DOM, CSS and JS. Should it be the Windows APIs? Then you're essentially rewriting Windows above the kernel. Just POSIX? Then what about applications that need rendering and sound. Do you invent your own cross-platform APIs? It's a massive undertaking, and without the momentum that the web had and has, it'll be tough to make this application runner popular among devs and users.