Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Web browsers are turning into giant, poorly designed operating systems. My current operating system can already run binaries, this is reinventing the wheel in a massively over engineered way.


Your current (desktop) operating system allows these binaries to run with your full user privileges. Any software you download and run has complete access to all of the data from your user account, no matter which software created it. Software can interfere with other software (spyware), can affect anything on the account (malware), and can even harm the system itself (e.g., by consuming resources). Worst of all, because there's no isolation you can't get rid of bad software: once you run software from the internet on your PC, you are boned. There is no way you can get rid of something that doesn't want to be gotten rid of since it can literally rewrite other executables to be itself.

Current (desktop) operating systems were not designed for a world where you routinely run code from someone on the other side of the planet who you have no relationship to, and don't trust, so you can see cat pics or read a forum.

Browsers have a lot of problems, but their security model and ephemeral install model are inspired designs, which directly enable the safety of the modern internet.

Having to fall back to classic desktop apps for real speed or power is a terrible thing for end-user security. Either browsers need to get more powerful, or desktop OSes need to take on a browser-like security model.


The process model is a sandbox. Every process runs as if alone, with seemingly continuous processor time and memory addresses starting at zero. The ailments you described are all system calls, special access granted by the kernel.

So the process model is not fundamentally different than the browser model, but WebAssembly enjoys two advantages:

1. The browser security model sagely segmented privileges by origin rather than user.

2. Like bytecode, WebAssembly AST does not target a specific processor.


Totally agree. The process model is actually a better sandbox than, e.g., Firefox per-origin one (because it sandboxes CPU time and memory as well). But the shape of the sandbox is incorrect for the modern era.


It seems like the real solution is to have proper sandboxing in the OS's, though it would take much more coordinated effort to accomplish.

I see no reason why each domain couldn't have a chroot for example, the browser doesn't need to implement those things.


> Your current (desktop) operating system allows these binaries to run with your full user privileges.

Actually it can sandbox them already.


But doesn't, by default. And that's crucial. On the web I can just run any random program from anyone and there's a very strict limit on what it can do to me and to other software.


We should have had a standard like WebAssembly from the beginning. The lack of it is the reason for the outrageous explosion of features in web browsers. At first html made sense: it was ideal for quick transfer and rendering of documents. But today that's not enough. So we keep tacking on layers atop already fat abstractions. And all this fat is trying to support a moving target. At first it was about rendering text, but then it was animations, and then videos, and 2D games, and advertisements, and now 3D games and full fledged apps. Notice that operating systems don't play this game trying to build an abstraction for every possible use of a computer because it's unwinnable. And now, some 25 years since its inception, the web is learning the same lesson.

Web browsers have been like operating systems all along, because they execute programs, albeit with different performance and safety characteristics. That the two are converging upon the same solution to the problem of hosting apps should be reassuring, not concerning.


There was. It's Java. I remember when it was first released and it promised the ability to "write once, run anywhere" but delivered via the Web to run as web applets.

And before that in the 80s, there was UCSD Pascal. I know it was available for the Apple ][ (used it in high school) and the IBM PC (one of three operating systems available when IBM launched the IBM PC in August of 1981) and probably a few other platforms I'm blanking on. A defined VM and "executables" could run on any platform running UCSD Pascal.

And even before that, IBM pioneered VMs for their own hardware, which is probably what inspired UCSD Pascal in the first place.


Web applets are terrible because

  - The JVM takes forever to spin up  
  - The JVM tries to do too much with tons of class libraries  
  - The JVM is insecure  
  - The JVM is proprietary. While there are open source
    implementations, it is still tethered to Sun and now
    Oracle. They call the shots on the features and have
    sued both Google and Microsoft for implementing their
    own versions.
Similar arguments can be made against Flash.

We shouldn't expect WebAssembly to have the same pitfalls, since

  - WebAssembly does not take forever to spin up  
  - WebAssembly doesn't try to do too much. There is no huge
    standard library. For now it doesn't even include a GC.  
  - WebAssembly isn't insecure. Why would it be? I assume
    applet exploits are a product of the large standard 
    library (more attack vectors) and privilege escalation
    (certain exploits let you break out of its security
    settings to gain control). All of this seems like it's
    because web applets are monkeypatched on top of the 
    existing JVM.  
  - WebAssembly isn't proprietary.


And I don't understand why. Take the two most popular mobile platforms, iOS and Android: people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use. My own preference would be something based off of Nix so that you can avoid many problems related to library versions and whatnot, but anything where a user could be pretty much guaranteed that if he clicks "install", he'll be able to use his application in the next couple of minutes.


> Why should the situation be different on the desktop? I feel that the efforts should not be going into making the browser into an OS that can run general-purpose software, but rather getting a packaging system that is cross-platform and easy for users to use.

Cross platform is a red herring. The iOS and Android app stores are not cross platform. Ease of use is also increasingly a red herring. The Windows and Mac app stores have been around for a long time and are quite easy to use. Yet they have not ushered in a shift away from Web apps on the desktop.

I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.


> I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.

I think there is a perception of "try before you buy" with web apps that is appealing. Even when apps/programs are free, you feel like you are giving something away by installing them.


It's like the old "How do you get an untested drug on the market? Pretend it's a dietary supplement". How do you get corporates and users to install a remote application runtime that lets them run programs from the internet? Pretend it's a document viewer.


I think you are right, this is a high technical debt solution for letting lay persons install software more easily. App stores already did a pretty good job at this anyway, and have the added benefit of curation.

The number of layers of in our software stacks grow faster than Moore's law can handle.


> App stores already did a pretty good job at this anyway

Then why isn't the Mac App Store (to name an example) a runaway success?


I kind of answered this with a comment above that mentions "try before you buy". Of course I am just guessing.


Mobile app stores are junkyards with terrible discoverability and they have a captive audience.


> people there routinely download and install new applications and typically never interact with Facebook, Twitter, Gmail or Instagram via their browsers. Why should the situation be different on the desktop?

Er, because that would be really silly.

I like reading HN from time to time. I would never install an app, because I don't use it frequently enough. I definitely would never go through the pain of installing a HN app every time I wanted to read HN. I really doubt I'm alone or even abnormal in that regard.

That's the beauty of a browser: I can be reading HN in under a second when I want to, with no cluttering of my desktop just so I can read HN from time to time.


I don't imagine HN requires web assembly or javascript to work, so it isn't a good example. But your point is right.

I think maybe application sandboxing is an OS job, and the browser should do the caching and invoking of the operating system sandbox.


I'll go a step farther, I typically don't install apps on my phoens.. why, because most of them have additional spyware and ask for permissions they should never need... I uninstalled Facebook over a year ago, as it was the biggest battery user... I get annoyed at websites that don't work on my phone, and more so for sites that try to get me to install an app, where there's no advantage to the stand alone app.


> Why should the situation be different on the desktop?

Because users want it to be. Whenever there isn't a significant performance hit people will always choose the browser solution. The only reason people download apps is because of performance and data limitations. Take those away and people will use the web based version.


> people there routinely download and install new applications

You should look at the data on that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: