As a user, this makes me want to get apps from the app store rather than downloading directly. It bothers me that apps can write arbitrary files. I'd much rather they be sandboxed so that when I tell the OS to delete the app, everything goes with it.
-download from App Store; app runs normally
-function in app hits boundary
- OS: "app Example has request access to <files: all/this directory/this folder> this time/always/not now/never"
Would solve this problem pretty quick right?
I don't want handbrake to have access to my photos, I'd love Native fine-tuned permissions like this.
For example, the first time I use Chrome to visit a website, it would trigger a dialog requesting permission to “Connect to websites” (i.e. initiate outbound TCP connections toward ports 80 and 443).
The first time I tried to use WebRTC, the dialog would appear for that.
I mean, yes, that's what it's doing. But a permission system that allowed it to say "Rewrite URL references for a, img, style, video, etc. tags, modifying the protocol, except where you also need to modify other things like s|^http://(\w{2})\.wikipedia\.org/wiki|https://secure.wikimedia... would essentially be presenting me with the source code for HTTPS Everywhere to approve.
And I certainly don't want it prompting on each website, which would be the natural way to implement a permission dialog system. Remember in the late '90s when web browsers would ask you for every cookie, or prompt you when going from HTTP to HTTPS?
Meanwhile, if a remote-code-execution bug is ever found in HTTPS Everywhere, it will have access to literally everything I do on the web. So it's not clear the permission system is really helping anything.
Another browser extension might want to automatically save images I come across to a directory. That one would prompt for access to my Documents folder. It wouldn’t request URL rewrite privileges, or camera, etc.
EDIT: So to answer your question, what is “something”? In this case, that would be: “HTTPS Everywhere wants to be able to edit the web addresses you visit”. Or something like that.
It can't just be the web addresses you visit, since it needs to change embedded tags inside the page to request https urls.
Unfortunately, with the state of the macOS dev team at Apple (merged into iOS?) chances for a feature like this are kinda slim.
If you put an exit door on a sandbox and give the user the key, it isn't a sandbox anymore.
But this sort of thing is universally considered a bad idea: https://i.imgur.com/H0uVqFe.jpg
http://nshipster.s3.amazonaws.com/core-location-always-autho...
Anecdotally, my tech-adverse friends choose Don't Allow when in doubt.
Access /foo?
Access /bar?
Access /baz?
But you have the seed of a great idea, which is that the app developer should explicitly request permission, so that they can request it once in a way that covers all the folders they need, rather than one by one. Like:
if requestAccess("~/Documents") == ALLOWED {
// Do the work.
} else {
print "Sorry, the app needs access to your documents"
}
The key thing is that all apps start with zero permissions, and escalate their access only when needed, rather than starting with full permissions, as happens today, which is insecure.
That doesn't work for all of your use cases, but it solves some of them (the backup app and file compressor, if you're only backing up your own stuff and not the whole laptop).
I think there are two forces at work here. One is the increasing lack of trust in any piece of software downloaded on phones and computers. This because advertising, spyware, spies, etc. The other one is the habit of renting vs owning. People is used not to really own music, books, apps, etc and even files to some extent. They are in the cloud and we can lose access to them if the owner of the cloud terminates our account. So we're growing accustomed with the idea that less and less of what we use and produce is really ours. Pieces of the hw, sw and data we paid for are somebody's else property. That's bad IMHO.
I'm not on a Mac and I'm backing up all my laptop, included configuration files owned by root and other system users. I understand that non technical users are fine with appliance like laptops that can be returned to the manufacturer and replaced with a new one as I do with a refrigerator. As a developer I prefer to keep control over my stuff. If I were in the refrigerator industry I would probably like to service my fridge myself.
It is ridiculous we are having this conversation about strictness of a sandbox requirements in the App Store and in another thread people bitch about Dropbox acting like an out of control virus.
As a user: I want it all sandboxed.
In general though, the idea is not to grant extra permissions to one process but to run other programs that DO have the required permission. This can all "appear" to be happening in one application on macOS even though multiple subprocesses are involved.
• On every new computer/device, I don't want to visit multiple sites and separately download every app that I use/prefer to keep available.
• Likewise for updates.
• I don't like obnoxious developers being "too smart"; There are things that I do not want apps to be able to do by default, on any of my devices, and I don't want you to attempt them unless I unambiguously allow each specific action.
• I prefer to look in one place for new apps and games.
• I prefer to link my payment and personal info to as few places as possibles.
However, I definitely agree that both the Mac and iOS App Stores suck at discoverability, the MAS especially so. It's baffling that such high profile storefronts are missing many basic filters in 2017.
Mac OS X and laptop and desktop hardware will become more and more of a distraction. We've seen them stagnating already. As a unix, Mac OS X is a rather elderly BSD.
They may keep a laptop device in the mix, but it will be more like a chromebook and run iOS.
Again, I'm speculating.
[Citation needed]
We know it's not happening because Tim Cook has explicitly said so. Additionally, it doesn't make financial or engineering or UX sense.
http://fortune.com/2015/10/13/apple-merge-ios-os-x/
(They also said they would not launch a small tablet and so on...)
The real question is should those who really care about security and are fine with the limitations of an sandboxed app really be defining the OS X ecosystem.
Otherwise you have to do the hack he was talking about where you download and install the helper from the internet and the controller is installed from the Mac App Store.
Wouldn't this work?
-download from App Store; app runs normally -function in app hits boundary - OS: "app Example has request access to <files: all/this directory/this folder> this time/always/not now/never" Would solve this problem pretty quick right?
I don't want handbrake to have access to my photos, I'd love Native fine-tuned permissions like this. Seems like you could adapt this to any functionality be it location/file access/ability to do certain things etc etc. you know... just like iOS does
There are exceptions, of course, and that's where things get nasty, but there's surely an optimum compromise encompassing some level of sand boxing and some level of permission management, rather than the extreme of 'everything goes' or the opposite extreme of 'no functionality'.
- There is no way to provide automatic software updates for sandboxed apps. For Mac App Store apps, that doesn't matter (MAS takes car of updates), but for apps distributed outside the MAS, this is pretty much a deal breaker.
- Many technologies are not available for sandboxed apps, eg. shared memory. This makes it hard hard to distribute some popular software on the Mac App Store (eg. PostgreSQL)
- Unix Socket Connections outside the sandbox are not possible. This makes connecting with a lot of services (eg. SSH Agent) impossible.
- the whole sandbox mechanism is buggy, poorly documented, poorly supported, and error logging in insufficient.
I currently distribute a sandboxed app outside the Mac App Store, and I'm considering to remove the sandbox for the above reasons.
Allowing automatic software updates requires leaving a big fat hole in your Sandbox...
(And what's the point of restricting your app to a sandbox, when it can replace itself with a non-sandboxed app?)
You raise an interesting point about security. It's about what you trust. Do you trust the app, or do you trust the developer of the app and their update infrastructure too. To have auto updates you need to do the latter.
Although strictly true, Unix DAC is a security model that stems from the 60/70ies. When a malicious actor gets read (or write) access to your home directory, it is pretty much game over (think cryptolocker, identity theft, loss of sensitive files, etc.). With vulnerabilities in internet-facing software being a fact of life, you want compromises to be restricted to their own little sandbox, not all the files in your home directory.
Hence, I have decided to always purchase the App Store version of an application when available and to think twice if there is no App Store version. I do not want to give a random developer full access to my filesystem.
Surely an app can only do that if it requests escalated privileges. By default, I would expect it to have the same filesystem permissions as the user that launches it.
There's the scale issue. Apple served perhaps low single-digit percentages of the PC market, which ranged from the tens to hundreds of millions overall, so millions to tens of millions of users, most affluent and educated. Computer usage is highly democratised now.
Which gets to the third point: mobile OSes are targeting user populations in the billions, across the globe, and at all manner of educational and literacy levels. If you think there's any possible way that's not going to target the lowest possible skill level, or that that skill level isn't tremendously low (see a recent OECD computer skills survey across the G-20: about half of all users have either no or the very most basic computer skills), well, I'm sorry.
There's a reason wide adoption leads to generally de-skilled products.