Is it? I've heard voices, but I didn't realize it's a very popular opinion. Personally, I think it's a feature and what makes desktop useful as a tool, as opposed to mobile devices being mostly toys.
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".
> 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.
You shouldn't download and run random executables on your Desktop OS though. Ideally, you only install open-source software, from a fairly secure repository, using a package manager which knows exactly which package is responsible for each and every file outside your home dir ... That's a not-quite-attainable ideal, but some people get quite close to it.
From what I've heard, a lot of them really are websites, as all they do is wrap the OS's browser control and open it to the specified website. In other words, they're nothing more than enormously bloated browser bookmarks. That is a problem, but I think it's more attributable to the lack of support for adding browser bookmarks to the home screen than anything else since the only reason they exist is so people can go to some company's website more easily.
That said, a sandboxing feature for the apps you don't necessarily trust is certainly a good idea; nevertheless, I personally don't see much value in keeping around those which I only somewhat trust, but don't trust with full access. It's either apps I trust completely, or ones I find alternatives to which I can.
But social network or advertising apps are unwelcome on a desktop, and in fact are usually referred to as malware when outside of a browser. I don't have much software on my desktop which isn't either a license I paid for or open source software.
The thing we're grumpy about is the lack of respect for the central dogma behind the personal computing revolution: one machine, one owner, one user.
Recently, for example, Apple has literally granted themselves higher access privileges than the admin/owner of a machine running the OS X file system. There are files on the hard drive that they can write to and delete that you, the owner, can't, without extraordinary (and nonstandard) efforts. Naturally, it will only be a matter of time until Microsoft notices this innovative feature and copies it, more or less verbatim, into Windows. At that point, it's no longer "My Computer" -- it's theirs.
And all of this is accompanied by the sound of thunderous applause. Because, you see, it's For Our Security.
In addition, no Intel Macs have any means of operating system lock-in. You can run Windows, Linux, or anything else that can handle standard x86 hardware. So you seem to have full control over the hardware at least (except maybe the SMC, which is not easily modifiable on standard PC hardware either). And given the fact that the Darwin kernel is open source[1], you are free to patch out SIP entirely and run that instead.
Yes, that's what I meant by "nonstandard." Apple has invented a brand-new access control mechanism to keep people from tinkering with files that reside on their own computers. For now you can work around this feature. Once they close that particular gap, I'm guessing we'll still be able to use a debugger to get the job done... and I'm guessing you'll move the goalpost accordingly.
[0] - It's not really "coming" anymore.
So, probably one of the most dangerous things you can do (opening the door to rootkits and an infected BIOS) doesn't take just a click and an undistinguished warning dialog? Also, this has been around since at least Windows 7, its not evidence of us sliding down a slope.
Yes, rebooting Windows one time to do it isn't that bad, but it's a start. I won't be surprised if the next version of Windows (next after Win10) removed that feature completely.
Forcing users to run only signed drivers is a problem because only Trusted Vendors can get proper certification (after paying proper amount of $$ to Trusted Certification Providers). Such restriction will basically kill hardware tinkering, which is one of the goals of the War on General-Purpose Computing.
It's slightly more difficult than turning of UAC on Windows. In addition, they didn't even try to hide the ability to turn it off; it's available in the documentation [1].
The only way they could seal the more difficult workaround I detailed above would be to either:
1. Rewrite their kernel so they don't have to open source it. In this case, I have no doubt the Hackinitosh community will have a patched version within a week. Goalposts moved I guess. Note you can still edit those files by restarting in another OS, which shouldn't be a problem for anyone who knows enough that they should be messing with such things.
2. Modify the hardware so it can only boot signed OS X. At this point, SIP is pretty irrelevant to the issue, and there doesn't seem to be any strategic advantage in even having it.
Also, I'm not sure what the motive is here. I can still install and run whatever binaries I want, signed or otherwise. I have El Capitan and I'm even using a custom shell. If Apple planned to require signatures for even command line programs to further their evil anti-Turing plan, SIP would again become irrelevant. So what slippery slope are we sliding down?
[1]: https://developer.apple.com/library/watchos/documentation/Se...
Not if the Trusted Computing Group has their way; it's already happening with things like Secure Boot. Hopefully things will change for the better, before we get to outlawing debuggers[1]...
This is widely considered a mistake, but it's also an implication of steady backwards-compatibility in app design -- and in many cases, code -- since the late 1980s. No one expected Lotus 1-2-3 to steal your WordStar documents, partially because neither of these were networked. So the OSes told Lotus 1-2-3, WordStar, and anyone else who came along that they had access to the entire drive and they could be designed as if they had that access, even though they didn't need it. Apps could ship their own Open dialogs; the OS trusted that they would only open files they were told to. A quarter-century later, the Windows and Mac App Stores are trying to reverse this, but the app developers are understandably grumpy because they have a quarter-century of code that never had to deal with such a design principle.
And the Windows and Mac App Stores are attempting to reverse this by reference to mobile app stores. Mobile platforms, being an entirely new mental model for both developers and users, could abandon lots of the design principles that make sandboxing hard. There is absolutely a reason why no mobile app has a desktop-style Open dialog: the OS doesn't trust it with that power. There is also a reason that the mobile AV industry is a tiny fraction of the desktop AV industry, despite mobile use having outpaced desktop use.