Hacker News Reader

Comment by cortesoft | Hacker News Reader

But what about apps that you are downloading that are SUPPOSED to do things to files outside of the 'sandbox'? I can think of a million use cases that require access to arbitrary files or system functions - a backup app, an app that compresses infrequently used files, a network analyzer, etc. The blog post talks about an app that needs access to things beyond the sandbox - the jettison app requires the ability to eject disks. Sure, there are a lot of apps that CAN work in a sandbox, but not all of them. There should be a way to grant apps permissions beyond the sandbox.

View on HN

An iOS-like approach seems natural.

-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.

The problem is that permissions only work for the most basic things.

What complicated things would a permissions system not be able to handle?

Basic Internet Access. How often will you read the dialog for Chrome before you just go "Screw it, set to Always"?

Just once, the first time the application runs into a particular sandbox boundary. The application can decide for itself what granularity it wants to request, then I accept or decline.

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.

Here's an analogy: HTTPS Everywhere wants to, quote, "Read and change all your data on the websites you visit."

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.

I don’t think the prompt should continually appear. It would just appear the first time an app needs to do something that’s currently out-of-bounds for its sandbox. You then accept it or decline it. Much how the iOS system works.

But what is "something"? Is saying "yes, you can modify google.com" permission to modify news.ycombinator.com too? If so, then you're giving every extension permission to mess with every website, which defeats the point of a permission scheme. If no, HTTPS Everywhere is prompting on each new website, which is unbearable.

It doesn’t defeat it. I expect a browser extension—whose job it is to rewrite URLs—to be able to rewrite URLs. But I don’t expect HTTPS Everywhere to want access to my camera, or to my filesystem, or to the microphone. So I allow the first one, and get very worried if I’m ever even asked about any of the others.

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.

Something like "Read and change all your data on the websites you visit."

It can't just be the web addresses you visit, since it needs to change embedded tags inside the page to request https urls.

This would be great! Little Snitch, but for file access.

This sounds like a great thing to implement in a desktop OS, if you could do it in a sensible manner with sane defaults.

Unfortunately, with the state of the macOS dev team at Apple (merged into iOS?) chances for a feature like this are kinda slim.

Haven't we learned that users will click "yes" on any dialogs that get in the way of what they want to do?

If you put an exit door on a sandbox and give the user the key, it isn't a sandbox anymore.

Have we learned that? I don't have any data, but my impression is that granular permission dialogs in iOS (and Android) are considered good things, at least in the tech community.

iOS's permission dialogs are great, but they're not very granular; it's just stuff like "Foo wants to use your camera", "Foo wants access to your calendar", etc. It doesn't ask you about individual files, and the questions are very clear.

But this sort of thing is universally considered a bad idea: https://i.imgur.com/H0uVqFe.jpg

The image you've linked to doesn't really imply that iOS' dialogs are a bad idea because, as you said, Apple's dialogs ask very clear questions. They don't intimidate the user with tech voodoo.

http://nshipster.s3.amazonaws.com/core-location-always-autho...

Anecdotally, my tech-adverse friends choose Don't Allow when in doubt.

You don't have granular control over these permissions. You can either accept or refuse, you can't select which ones to grant or not. I think this is a terrible way to do permissions and poor security. I'd like to see true user-level granular permissions down to the level of being able to specify what hosts the app is allowed to connect with (if any).

This is roughly what Little Flocker[1] does on macOS.

[1]: https://www.littleflocker.com/

That's too granular, as others have pointed out. It will lead to too many prompts.

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.

The dev clearly stated he didn't want to do the work to support doing things 'the right way'. He didn't want to do the extra work to keep the same functionality and work within a sandbox.

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.

I'm the developer. Jettison and HistoryHound have always been available as direct purchases as well as through the Mac App Store. Given the sales volume I got from the Mac App Store vs sales through my website (see the comments about lousy discoverability), it wasn't worth investing more time jumping through Apple's hoops to ship products that would be inferior to what I can write outside the App Store. That doesn't mean I "didn't want to do the work" - it means it doesn't make sense for my situation and my apps. And that's just the case for those two. Two other popular apps I've written - Default Folder X and App Tamer - are impossible to implement in the sandboxed environment. In cases like that, Apple's sandboxing constrains what devs can viably do - not everyone can take the risk of bypassing the App Store, and if they can't, the Mac community misses out because those apps just never get written.

There was no way to do what i wanted to do "properly", I actually did put in all the work of getting it to work by the rules of the sandbox only to be faced with that annoying spinning gear in the top menu, which all my customers complained about.

DaisyDisk handles this pretty well. It pops up a window and you drag your Macintosh HD into the window, and that gives it access to that drive and all files inside of it (as your user only, so it can't backup system files or anything).

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 couldn't help noticing the difference you made between "your own stuff" and "the whole laptop", which is still your own stuff. You probably meant what's owned by your user id and what's owned by system user ids. Still that made me think.

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.

The Open and Save panels were modified in macOS to automatically extend the application's sandbox to include files selected by the user. It is a somewhat clever way to ensure the user has given permission to access something new without actually asking (no question prompt).

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.

Reply on news.ycombinator.com