The other aspect is that programs are traditionally really bad at being conscientious about your system, even when not being malicious. Windows programs have a tendency to put files wherever they feel like, although UAC has helped this to some degree. Plus, every program and its brother has its own update system that absolutely must run in the background constantly, even when I'm not using it.

As a desktop user I need little to none scrtuiny. My web browser, IDE, toolchains, IM, video player and computer games all work together well and while technically any one could own any other, this simply does not happen. It takes some (little) skill to avoid obvious malware, and then generally you're fine. On the other hand, I get to open my video file in my IDE, edit IM's data files in a word processor, and move things around seamlessly with OS; everything is expected to work and no program tries to lock me in.

> The other aspect is that programs are traditionally really bad at being conscientious about your system, even when not being malicious.

I don't think much has changed here. Phone apps are also not conscientious; they fight for your attention with other apps and with the entire operating system. The changelog of both Android and iOS is full of things done against app developers, because many popular app developers are willing to do anything imaginable to get your attention (and thus ad money).

My point is - the problem isn't with sandboxing itself; it's with the web and mobile ecosystem that makes developers work against the interest of users, instead of for it. The sandboxing is just a symptom - something that is being done to mitigate the damage of greedy "entrepreneurs". Desktop environments don't need that much sandboxing because there isn't that much crap going on.

I think the fact that desktops originally weren't connected to the Internet is a reason we've started with an open system, but it may be worth preserving this flexibility even in the Internet era.

It's not just downloading malware that is an issue; you also have to worry about security flaws in the apps you trust. Web browsers are a perfect example; they are constantly downloading untrusted code and executing it. Even when the javascript engine doesn't have a flaw, you have exploits like Rowhammer.js[1] which sidestep them entirely.

> It takes some (little) skill to avoid obvious malware, and then generally you're fine.

I think you're underestimating the knowledge needed to secure your computer properly, and overestimating the savy of the majority of users. The current state of computer security (huge botnets, etc.) is a testament to the fact that the current model isn't cutting it.

> On the other hand, I get to open my video file in my IDE, edit IM's data files in a word processor, and move things around seamlessly with OS; everything is expected to work and no program tries to lock me in.

If the lock in is an open file dialog, or passing a filename by command line, all of the examples you list would work fine.

> Desktop environments don't need that much sandboxing because there isn't that much crap going on.

You are missing an important difference; most users are far more liberal in downloading apps for mobile than for desktop, and if they were just as liberal on their desktops they would be pretty much guaranteed to get malware. Because of this, many apps which are only used in a browser on a computer are used as apps on mobile (which is needed at the very least for performance reasons). Sandboxes aren't perfect, but they move the ability to infect a device via installation from "totally trivial" to "requiring significant vulnerability".

[1]: https://github.com/IAIK/rowhammerjs

  > Desktop environments don't need that much sandboxing because there isn't that much crap going on

You're safe if you install only paid-for software from big companies and open-source software that hasn't been bundled with installer malware. And never install Flash or Adobe Reader. And keep your browser, AV, and anti-malware up to date.

The plural of unsandboxed desktop is "botnet".

Yes, this is tragic and a real threat to open software development.

There's something with web/mobile that makes people afraid to do anything without sandboxing the living hell out of every app, even though we've managed to live with unsandboxed desktops without many such incidents. I can't exactly put my finger on what is going wrong (it has definitely something to do with installing random crap and the new business model of companies trying to monetize user's eyeballs and data), but the push towards sandboxing is a symptom of that problem.

Antivirus is mandatory on desktops

You might not be able to do absolutely everything you could with unfettered access, but that hardly leads to "mostly toys." The nature of mobile apps stems far more from the use case of the devices (user attention measured in seconds, rather than minutes) than limitations of the software development platforms.

If you have any suspicion that installing an app will cause your phone call with your grandmother to be interrupted, you will really scrutinize what you install.

Early Android devices tended to have more problems than iOS devices when it came to phone calls getting interrupted, so whether this was marketing making an excuse for something Apple wanted on s technical level, it seems sandboxing was with the use case of "keep the phone working" firmly in mind.

I don't doubt that - but the problem is that everything you do with one app must almost always stay within that one. It's only when you want to exchange data between apps that all the power of the traditional full-access model really shines, and the reason why people have resorted to some horribly inefficient workarounds (e.g. upload to some server on the Internet from one app, then download the data in another) to do this.

That said, the notion of a file system isn't inherently incompatible with sandboxing. If you allow the user to grant permission on a per-app basis whether those apps can read/write to a common data store, you essentially have the benefits of a local file system in a way that does not break sandboxing.

You only want to sandbox apps to keep them from touching the OS and other private app data. If it is user-permitted for them to touch a common data store then that means data does not always have to stay within the app in which it was created.

http://plash.beasts.org/powerbox.html

I believe that Apple's desktop sandbox does use powerboxes, in that the Open dialog is privileged code and hands the app an open file handle. But it means that you can't tell Emacs to edit an entire source code directory. BBEdit had exactly this complaint about the sandbox.

But there's no reason such apps can't live side-by-side. I use Emacs to edit my hosts file, it's pretty convenient. A sandboxed Emacs would not be.

But I don't mind if the painting app I download is sandboxed because I'm going to be dragging-and-dropping my artwork into that program and I don't want it having access to my disk or network outside its sandbox.

I consider mobile apps toys because they're designed to contain and own your data, and that impares both the ergonomy of work and limits your capability for doing things to whatever is available in the MVP some startup released. Most apps don't evolve past the point of MVP.

Real scissors are toys but plastic scissors are not toys since you can't hurt yourself with them.

Definitely not a "toy".

[0] - most desktop software doesn't need Internet access; even most mobile software doesn't need it in principle, it's only because of lazy business models that they have to have it.

OS X solves this quite elegantly. If an application is sandboxed, it cannot access files outside the sandbox directly. However, when an Open (or Save) dialog is requested, it is handled by a privileged daemon outside the process (it used to be pboxd). This daemon then makes the file or directory available in the sandbox after selection.

You still get app isolation, but it does not impede the user experience. (Of course, it does not apply for every scenario, but sandboxing is not a requirement outside the App store.)

E.g. Finder replacements, tools like Alfred, BootChamp, etc.

Maybe you misunderstood my post but that's exactly what I meant should not be misunderstood as sandboxing. Sandboxing api calls is not the same as hiding the file system.