7 ms·

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, th

by 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
  The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know what Microsoft recommends today, since no developer is going to use it and that rec will change tomorrow. While technically, complexity is not necessary, pragmatically the sandbox offers next to nothing for users or developers without OS vendors enforcing its usage, or the sandbox being so compelling a target for developers they accept the limitations of the sandbox - which is why the only platforms with robust sandboxes are mobile and the browser.
  - anderspitman 6y ago
    IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices. Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad. I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.
    - remexre 6y ago
      I think proper sandboxing on a traditional Unix is hard enough that ~nobody does it right; you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them. I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think it'd make more sense to do it with network namespaces or iptables rules or something, but /shrug.
- josephg 6y ago
  Text rendering and accessibility APIs both need to access the host OS’s APIs to work correctly. (Text rendering is subtly different on macos and windows, and app rendering behaviour should follow the platform.) I think we can expose standardised APIs to applications for this stuff, but the API will probably need on the order of hundreds of methods.
- modeless 6y ago
  I like this vision of shared libraries sandboxed inside a minimal runtime to replace the browser. But there are some serious problems with it (that I hope can be resolved somehow). Replicating a significant fraction of the functionality of a browser ends up being a lot of code and data. For a web-like experience with instant navigation between apps it will be necessary for these shared libraries to be really shared, as in almost all apps use the same libraries and the same version of those libraries. Otherwise you'd be downloading and unpacking and JIT compiling dozens or hundreds of megabytes of code and data before you could display a single line of text, every time you click a link to a new site. The linkable nature of the web would be lost. (Yes, many websites are dozens of megabytes already, but the bulk of that is delay-loaded and happens in the background after the initial content is displayed). In order for the standard libraries to be actually shared, everyone would have to agree on the standard libraries to use, and the standard libraries would have to be designed to be backwards compatible so that older sites could be force-upgraded to use newer versions. This is essentially the role that browser updates play today. But the browser evolved over decades and it's not clear how you'd get everyone to adopt a new set of standard libraries today, nor how you'd get everyone to agree on what functionality to add over time (the role that W3C plays today). For libraries outside of the standard set, it sounds tempting to allow them to be shared too. But this is actually an unavoidable privacy violation. If you have a shared cache, then any app can discover the set of previously loaded libraries with a timing attack, thus revealing information about the user's browsing history. This is why all browsers are now moving to partition all caches by site: https://www.jefftk.com/p/shared-cache-is-going-away https://www.jefftk.com/p/shared-cache-is-going-away. Even if multiple sites reference the same wasm blob, it must be downloaded and JITed separately with no sharing. As I said, I like the vision of a tiny low-level runtime executing shared libraries inside a sandbox. But I'm not sure how it could be done in an efficient and privacy-respecting way if you want to replace the Web with it.
  - deleted 6y ago
    [deleted]

by hctaw 6y ago

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
The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know what Microsoft recommends today, since no developer is going to use it and that rec will change tomorrow. While technically, complexity is not necessary, pragmatically the sandbox offers next to nothing for users or developers without OS vendors enforcing its usage, or the sandbox being so compelling a target for developers they accept the limitations of the sandbox - which is why the only platforms with robust sandboxes are mobile and the browser.
- anderspitman 6y ago
  IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices. Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad. I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.
  - remexre 6y ago
    I think proper sandboxing on a traditional Unix is hard enough that ~nobody does it right; you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them. I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think it'd make more sense to do it with network namespaces or iptables rules or something, but /shrug.
josephg 6y ago
Text rendering and accessibility APIs both need to access the host OS’s APIs to work correctly. (Text rendering is subtly different on macos and windows, and app rendering behaviour should follow the platform.) I think we can expose standardised APIs to applications for this stuff, but the API will probably need on the order of hundreds of methods.
modeless 6y ago
I like this vision of shared libraries sandboxed inside a minimal runtime to replace the browser. But there are some serious problems with it (that I hope can be resolved somehow). Replicating a significant fraction of the functionality of a browser ends up being a lot of code and data. For a web-like experience with instant navigation between apps it will be necessary for these shared libraries to be really shared, as in almost all apps use the same libraries and the same version of those libraries. Otherwise you'd be downloading and unpacking and JIT compiling dozens or hundreds of megabytes of code and data before you could display a single line of text, every time you click a link to a new site. The linkable nature of the web would be lost. (Yes, many websites are dozens of megabytes already, but the bulk of that is delay-loaded and happens in the background after the initial content is displayed). In order for the standard libraries to be actually shared, everyone would have to agree on the standard libraries to use, and the standard libraries would have to be designed to be backwards compatible so that older sites could be force-upgraded to use newer versions. This is essentially the role that browser updates play today. But the browser evolved over decades and it's not clear how you'd get everyone to adopt a new set of standard libraries today, nor how you'd get everyone to agree on what functionality to add over time (the role that W3C plays today). For libraries outside of the standard set, it sounds tempting to allow them to be shared too. But this is actually an unavoidable privacy violation. If you have a shared cache, then any app can discover the set of previously loaded libraries with a timing attack, thus revealing information about the user's browsing history. This is why all browsers are now moving to partition all caches by site: https://www.jefftk.com/p/shared-cache-is-going-away https://www.jefftk.com/p/shared-cache-is-going-away. Even if multiple sites reference the same wasm blob, it must be downloaded and JITed separately with no sharing. As I said, I like the vision of a tiny low-level runtime executing shared libraries inside a sandbox. But I'm not sure how it could be done in an efficient and privacy-respecting way if you want to replace the Web with it.
- deleted 6y ago
  [deleted]