Every binary I run could delete all my data or steal my passwords or whatever else. That's not something to be afraid of --- it's something to cherish and be proud of[1], and it's why you don't run anything you don't trust. This "free-for-all" sharing and access encourages the sort of ad-hoc and unpremeditated interactions which are beneficial to the software ecosystem as a whole.

I usually have a magnifier, color identifier, and clipboard-listening-translator running. None of those would be easily implementable or may not even exist, had computers started out as locked-down systems from the beginning.

[1]https://boingboing.net/2012/08/23/civilwar.html

In the macOS sandbox, an app can access any old file, but only ones the user has implicitly told the app it can access - through the system "open file" dialog, double-clicking, drag & drop, etc.

It was meant as a souped up iPod platform, tethered to iTunes.

I just wish we didn't have to way for Windows 8/10 to get "sane" file management on tablets, after Google mangled Android from 3.1 onwards.

Now you're completely screwed. All of your emails, pictures, medical information, other embarrassing personal information/media, bank logins, and so forth are compromised. Maybe you have two-factor authentication for all of your accounts (doubtful), but who cares? It can just read the memory of your browser process, quietly wait for you to login to the various services, and then hijack your sessions in the background.

So tell me: how in the world is this an acceptable situation?

[1] I sure hope you never use any of these new-school package managers for various programming languages, text editors, and such. You know, the ones that grab the latest commit from GitHub repositories run by total strangers and then run them with full privileges.

It is benefit vs cost: for me it is acceptable because i want to be able to do whatever i want with my computer using applications that can freely interact with each other without the OS getting in my way. I want the underlying system to provide the functionality for the applications to perform their tasks but not add unnecessary barriers that make features practically impossible.

Also FWIW personally as a developer i highly dislike the idea of signed software. First of all i do not like the idea of having to ask (let alone pay) anyone to have my program be runnable by others and second i do not like the idea of my name being carried alongside my programs unless i explicitly add it.

It is not the eighties anymore. Software is exploited through malicious files that exploit vulnerabilities in file readers (e.g. malicious PDFs). Software distribution sites get compromised (Handbrake, Transmission, Linux Mint), etc. Signatures and proper sandboxing reduce the attach service considerably.

Also, to address your point: sandboxing does not have to be binary. For instance, on macOS, a sandboxed app can request the user access to the calendar or address book. In that way some random app can't just steal your address book. [1] By default an application cannot open any files from the user's home directory, unless the user e.g. choses it using a file opening dialog (which runs out-of-process). On Flatpak on Linux, you as a user can decide to run an application with more entitlements (AFAIK currently only through the command-line).

We need to go to a world where the power lies with the user and not the developer to decide what an app can access, upload, etc. macOS sandboxing and Flatpaks on Linux are now providing part of that solution.

Also FWIW personally as a developer i highly dislike the idea of signed software. First of all i do not like the idea of having to ask (let alone pay) anyone to have my program be runnable by others

Flatpaks on Linux are normally signed, but they can be signed using GnuPG key. No need to pay or ask permission. Of course, the downside of this model is that it puts the burden on the user to check that the key is owned by a reputable person.

second i do not like the idea of my name being carried alongside my programs unless i explicitly add it

Most users should not want to run a program by a random person.

[1] Don't say that free software is not vulnerable to such problems. A popular free software documentation browser embeds a Google Ad, some open source applications use Google Analytics. I do not want to upload any data to Google. Unfortunately, as a user, I can only avoid that by inspecting all my outgoing connections. Of course, this is out of the reach of a normal user. I would absolutely be in favor of sandboxes where by default an app could not make any network connection.

I do not see those as placing power in the hands of the user, i see it more as placing power in the hands of the platform holder the developer develops for and the user uses. The user should be able to do whatever he pleases, even at the cost of the developer's wishes and to do this, the platform must allow the user to subvert both the platform's restrictions and the program's requests.

Anything that doesn't put the user in a position of utmost authority and trust is not something that places powers in the hands of the user.

This is demonstrably not true. Most users will go out of their way to run any software if they believe that it will do what they’re looking for.

It's very depressing to be transitioning into a world where you can't use a small trusted open-source mail client and IM client etc, where you have to install crazy huge untrusted piles of flaky and inefficient code in order to interact with real-world people and institutions, and you can't easily control which version you have installed, and mobile devices become obsolete after just 3 years. (Even iPhones - not because of Apple, but because Instagram and Snapchat got too heavy/shitty for the older models! This does not happen for communication over SMTP or XMPP!)

So I see the "we need super sandboxes around every little thing" as a sort of bandaid on a much bigger problem which is not going to be fixed in the foreseeable future.

The only reason Debian didn't distribute some really bad malicious code (that we know of) yet is because they got lucky and no developer tried to mess with them.

The sandbox has always been completely different from iOS e.g. it doesn't ask permission to access photos, microphone, webcam.

1) Your webcam turns a light on. Not permission, but you know what's going on.

2) "People must grant permission for an app to access personal information, including the current location, calendar, contact information, reminders, and photos."

https://developer.apple.com/macos/human-interface-guidelines...

But you can always go straight to the files themselves for cases like Photos and Calendars and also to the SQLite databases that back a lot of user data.

And current location is easy to get on OSX. You can simply look up the user's IP address and WiFi networks to triangulate the user's location with about the same accuracy as Apple can do.

With webcam you can easily switch the camera on, take the photo and switch it off. Could easily trick people into thinking it was a hardware fault rather than something nefarious with the app.

The fact is that none of what I listed above is possible on iOS.

Sure, if you download software from the web, it can do whatever it pleases.

But if you download apps only from the Mac App store, you should be safe.

On iOS, Apple checks all your software. On the Mac, they give you a choice: If you want "safe" software, go to the Mac App Store. If you want any software, go somewhere else.

The sandbox isn't as complete as on iOS, but the stuff you listed requires special permissions and confirmations when you get your software from the Mac App Store.

The thing that bugs me is there’s no indication an app is connected to my microphone.

Better safe than sorry!

Having said that, plenty of useful apps can't ship in sandboxed form because of limitations in the current sandboxing model. And of course the fact that sandboxing is required for store distribution makes the store less useful. The implementation has much room for improvement, as do the store distribution policies.

If an app has to ask me permission in order to access my keystrokes, I think it's fair to assume that the same would be true of apps that read (anything outside their window regions) from my screen. The fact that macOS doesn't require this is discoverable by sleuthing (browsing the Privacy pane, or remembering that screenshot apps don't ask for it), but there's reasonable, and probably common, mental models that don't make it obvious.

It would be like renting a house with four locks on the front door and none on the back. Yes, you could audit the house, but it's a weird asymmetry to have to look for.

(P.S. I'm older than you, FWIW :-)

Edit: It seems you a many of the others replying to the GP are talking about apps from the App Store, which I basically never use. And that's sort of the parent's point, I think. I get apps from the internet, install them, and use them, like and old-school desktop/PC computer user. I rarely need to use the app store (except for updates, and it's weird UX that OS updates are in the app store to begin with) and have no compelling reason to do so.

You're right that this isn't super fine-grained. This single checkbox seems to govern several unrelated things, such as keystroke logging and insertion (Dash and Keyboard Maestro), mouse recording and control (Keyboard Maestro), and whatever APIs are used to badge Finder icons (Google and Dropbox). My belief is that an app that I haven't checked off there doesn't have access to my keystrokes. (Maybe this is wrong?) In which case I'm surprised there's nothing like this for recording the screen.

A lot of users got tired of the on-screen badge being on all the time and probably set it to hidden (very easy to do) so not everyone is actually aware of when an HTML5 application is accessing a microphone/camera/screen.

[1] https://www.obdev.at/products/microsnitch/index.html

How does he think that desktop app can do many different things?

Now, sandbox is a different issue. But of course, yes it have access to the screen.

If apps on desktop is going to be as restrictive on mobile, why use desktop at all?