[IChrisI]

Requesting permissions for everything your app can possibly do at install time makes apps look scary. Here's an example.

Imaging a messaging app. It needs permission to read and write to your text messages - not so bad.

Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.

Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".

Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.

Contact integration? Camera integration? Access storage? These are all things that a messaging app might reasonably want to do. But seeing a big list of permissions, including things like "draw over other apps" and "make and manage phone calls" is scary to an end user. Especially for an app that's only supposed to be handling SMS.

[amelius]

I really hate it when I need to send a single file or photo, an app suddenly "needs access to my filesystem" and I have to grant that access.

OSes should allow me to create a sandbox for an app, so I can grant them access (and the app will not "break"), while still being secure.

[cesarb]

> I really hate it when I need to send a single file or photo, an app suddenly "needs access to my filesystem" and I have to grant that access.

There's another way: the app could instead use Android's Intent system to request a file chooser. This switches to a separate app which already has access to the filesystem (like the built-in Gallery app), which after the user has chosen the file, returns something which allows the original app access to just that file. This mechanism exists since the first version of Android.

[amelius]

I think this won't work because the app can get away by asking (insisting) for more permission than it actually needs.

[devxpy]

exactly.

[scarface74]

That shows the larger problem with Android. An app shouldn’t need access to your file system to send a photo. It should bring up a system provided photo picker and once the user chooses a set of files, the OS should give it a read only access to the file.

If a photo management app needs access to your photos, you should be able to give it access to your photo library.

[amelius]

I don't think that's the solution because apps may easily "bribe" the user into giving the app more access than it strictly needs. The bribing goes like: "sorry, but if you don't give me full access, then you can't use me". Simple, but very effective in most cases.

A better solution (imho) is to make the app think it has access, while in reality its access is limited to a sandbox.

[scarface74]

That’s still a problem with the OS. Why does any app need access to the file system instead of the users photo library or access to certain files in a document store where the app only has read access to files that the user explicitly chooses in a system provided file picker or can write files to a location that the user chooses?

[devxpy]

https://developer.android.com/training/secure-file-sharing/r...

read up!

[scarface74]

It’s fine that it’s an option but there is still nothing on the OS stopping an app from getting more permission. Why is the other permission even an option?

[devxpy]

Just a matter of freedom vs security I guess?

[HappyRobot]

I thought Android apps were sandboxed [1]. The "needs access to my file system" is the way for data to transfer into that sandbox.

Android should add the option for temporary data access. I would prefer turning on the access temporarily to send 1 photo, then turning it off a few minutes later.

https://developer.android.com/training/articles/security-tip...

[amelius]

The problem is that apps want access to my entire filesystem, otherwise they break. So a solution is to make them think they have access, while in reality they only have access to the sandbox filesystem (containing just the files I want to manipulate with that app).

[trash_panda]

What is the "file system permission" you are referring to?

See: https://developer.android.com/reference/android/Manifest.per...

If you don't mind sharing, what app are you referring to?

The file system itself should be well protected (on a non-rooted phone) as to prevent any unauthorized access to important data. Any app can only do whatever on the SD card if you give it permission to do so, but on the OS file system itself there isn't much they can do (again, on a non-rooted phone).

[scarface74]

That doesn’t help. No app should need general access to the sd card.

[trash_panda]

Completely agree.

[devxpy]

I believe this is what you're looking for?

https://developer.android.com/training/secure-file-sharing/r...

[taneq]

That's basically what Privacy Guard does. It was available at one point in stock Android and is a major selling point (IMO) of LineageOS.

[felix_nagaand]

Your solution is too simple and intuitive.

[chasil]

Linux does have this feature. It is the chroot() system call.

Linux can also allow limited access to select filesystem data within a chroot() - this is done with a "bind mount."

Why these two security features were not designed around all Android apps from the beginning is beyond me.

[TeMPOraL]

Didn't chroot() become secure / usable only late in the era of smartphones, way past creation of Android? Containers are a pretty new development, after all.

[hedora]

Neither linux containers nor linux chroot provide meaningful security. They’re useful for other things, but the kernel itself isn’t particularly well hardened against local privilege escalation attacks.

OpenBSD is one of the best on that front, but it is a defense-in-depth mechanism, not something designed to run known-malicious code.

[JTbane]

That's no different than running programs in userspace on a PC- if you trust the app, it makes no sense to decline.

At least you can turn it off later.

[duiker101]

And then you need to app to the sandbox? Seems even more complex

[mobilio]

Actually isn't. And this was already implemented in iOS and Windows Mobile.

[scarface74]

Maybe there's a feature where you can quick-reply from the message notification. Now it needs permission to draw over other apps.

iOS has a framework to take actions directly from notifications without requesting permission.

Maybe it's smart enough to not DING! during a phone call. Now it needs permission to "make and manage phone calls".

Or that could be provided by the operating system without needing the feature....

Maybe there's a feature where it suggests a "here's my location" response when somebody texts you "where are you?". Now it needs permission to access your location.

Fair enough.

Contact integration? Camera integration? Access storage?

Why would it need to access storage outside of its own sandbox?

[TeMPOraL]

> Why would it need to access storage outside of its own sandbox?

To allow you to send and receive attachments.

Name any one permission, I'm pretty sure I'll find a reasonable case for it to be used in a messenger app.

However, a pretty strong case can be made that current permissions allow for way too much. For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker, so that the app only gets temporary, read-only access to the selected file. Similarly, for saving attachments the app needs only a virtualized location with write access.

[nothrabannosir]

Is it the responsibility of the app to display the file browser? I’m not an app developer but I’d expected you could essentially call “osGiveMeAFile(constraints...)”, and it would pop up a native file picker dialog without your app ever having access to the full FS?

Then again I wouldn’t be surprised if google had botched this. They did it wrong for Google Drive apps, and as a result any app that wants to do something as outlandish as, say, opening a file requires read access to all files on your entire google drive, just to display a file picker.

Sometimes I wonder if anyone at Google actually thinks about these things, like, at all. How does this happen? What are those meetings like? Surely someone noticed? Ho do they think about “trust”? It never ceases to amaze me.

[TeMPOraL]

I agree. IMO, what should happen is: the app request for file(s), an isolated (as in, separate sandbox) file picker is shown to select those files, and only stream handles + metadata (size, file name without path) is returned.

[scarface74]

The app still shouldn’t need access to the entire file system. The app should be able to launch a file browser, the user chooses a file and the OS gives it acccess to only that file or set of files.

[TeMPOraL]

Yeah, I agree.

Really, the problem is that all of that gets ridiculously complicated for an average smartphone users, which makes it trivial for app developers to "bribe" users by having the app essentially tell "give us permissions or else it won't work".

I'm all for aggressively delisting applications that refuse to work when non-essential permissions were not given. Something like PlayStore GDPR, only for permissions.

[scarface74]

For instance, I should be able to send attachment by picking them through another (OS or third-party) file picker

The native file picker on iOS works with iCloud and third party storage providers like Dropbox, OneDrive, Google Drive, and Box. Any storage provider can integrate with it including apps that store everything locally.

[mannykannot]

> Requesting permissions for everything your app can possibly do at install time makes apps look scary.

There's another point in favor of requiring it. The only downside I can see is that the people who most need to be scared by it would not be.

[cesarb]

There's another downside: optional functionality. For instance, Firefox can use the camera, but if I never access a website which needs to use the camera, there's no need to allow Firefox to access the camera. Many Android apps have optional functionality which would require extra permissions, but if you never use these optional functions, the apps work just fine without the extra permissions.