Hacker News Reader

Comment by hakre | Hacker News Reader

Additionally there should be a sandbox mode. While you give the app access to Photos and Contacts, it's an actual sandbox not containing any photo nor any contact. So the app gets what it asks for (the permission) while the user can still control the data.

View on HN

This is how photos access on iOS works. An app can ask for access to photos and you can choose 3 options:

- no photos - only specific photos (the system picker will appear to select them) - all photos

Regretfully, it seems on iOS apps can tell they’ve been given access to only specific photos. Googles Photo app refuses to work unless it gets access to all photos.

WeChat will loudly grumble every time you try to send a photo if you haven't given access to all photos. But at least it works.

And if you tell me now, that it works without having access to contacts, its lightyears ahead of WhatsApp.

But still, these moaning dialogs aren't trust-building. I wish there would be better guidance with UX in the industry.

WhatsApp works without access to contacts now, no?

WhatsApp still uses your contacts as its "friends list", i.e.: people appearing in "new chat". You can still text any number with wa.me links but the UI doesn't offer number input IIRC.

No, you can't initiate a session with someone you know the number of, it demands access to contacts so "you can stay in contact with your friends". The usual weasel words.

It was the case before, but I can do it now. It says "enable contact access to make it easier" but I can also just punch in a number and start chatting... Contact access is off.

This is not the case in WhatsApp on Android, at least as of a couple months ago when I last checked.

I think it's a good design decision that just lacks control during the app review process.

There are apps that need full access to your photo gallery to be really useful (i.e. where limited pool of photos may have little sense in those contexts), photo deduplication apps being a case on point. At least that piece of information gives the app a chance to tell the user that it may not work as expected.

Now, if an app misbehaves based on photo sharing permissions (i.e. Google Photos not being able to work), that is a decision that the product team took. They're the ones responsible and that should be judged.

If anything there should be tighter controls during the app review process on how those apps use that info and avoid the ones that only work when sharing the full gallery.

I am the user, and if I allow only Screenshot and Whatsapp images folder to be accessed by your deduplication app, I want it to work on these 2 folders only, without accessing my camera. Same for lets say backup app.

Yeah sure, that's what should happen. I'm not saying otherwise, read the comment again.

YMMV, but IMHO it is preferable that the fundamental execution model of the app stays in control of the app-executing user and should not be affected or be dependent on the app review process. Rationale is to prevent single point of failures, especially those that are out of control of the user (compare with the emergency off switch on some bigger machinery).

What is regretful about that?

This was an annoying issue with one of the Twitter competitors a while ago; their app asked for photo access, I gave it partial access, it grumbled that it needs ALL of it, and refused to let me upload any photo. I thought it was a "total photos < X" heuristic, so I went back and picked like 30 old photos, and it still knew that wasn't all of it.

Probably because it's file based. Don't they have a feature to paste a picture from clipboard or photocamera?

That still works regardless of file permissions, own-app storage is always allowed on both iOS and Android since ever on iOS and since Android ~6. And clipboard access is all API-based, at least.

That was a change that seemed to add inconvenience but no additional security. Now I have to first approve an individual photo, then search the pre-approved photos for the photo I just added (they will be sorted by time). Why can't they just let me approve and add a photo at the same time?

But it absolutely provides more security... the app can see only the exact photos you allow. It is a bit annoying as an extra step, but I'll happily give apps access to a single photo selectively versus the all-or-nothing approach where I might choose to completely stop using an app.

Sorry, yes, the segmenting out of permissions on a per-picture basis adds security. What I mean is, the additional hassle added, but the way iOS and apps currently do it, is not necessary for that security. There should be an interface directly from the prompt for pictures on the app's side, to the selection of photo's on my phone's side, to the point that adding pictures is just as easy as it was before. There's no reason for the extra steps to get this added security.

You can unselect all from the dialog every time, iirc, as a work around for this.

I'm not sure, if it works as advertised. I've been playing with one of the apps and despite selecting "No photos" option, I was still able to upload photos from my gallery. Perhaps some metadata is not shared in this case, but photos definitely were accessible.

There are two APIs in iOS for the photo browser, the API where the app gets access to your photos so it can draw the list view of “all the pictures” is gated with the permission.

The newer API that pops up a system control that lets you select a photo (or more) and only then if you select one, it returns that picture (only) to the application, that API does not need permission, because unless you select a photo, the app does not have access to anything.

Yes, you are right, thank you. After I have posted my comment, I started reading about PHPickerViewController and it totally makes sense.

GrapheneOS supports this with a feature called Storage Scopes. Instead of giving an app access to your entire photo library and files, you can limit its scope to an individual folder of your choice.

That way the app still gets the permissions it asked for, but they're specifically what you want it to see.

> GrapheneOS supports this with a feature called Storage Scopes

Thanks for the pointer, adding the missing reference: https://grapheneos.org/features#storage-scopes

This looks pretty interesting (and there's more GrapheneOS has to offer):

> GrapheneOS provides Storage Scopes as a fully compatible alternative to the standard Android storage permissions. Instead of granting storage permissions, users can enable Storage Scopes to make the app assume that it has all storage permissions that it asked for. On Android, an app that doesn't have any storage permissions is still allowed to create files and directories, and is allowed to access the files that it created. Users can optionally add files and directories as storage scopes to permit the app to access files created by other apps.

This comes pretty close to what I imagined, thanks a lot for providing this living example!

This is the obvious solution, it’s really annoying that it is not available for every permission. (Contacts is the big missing one in iOS, but you could even have a fake GPS that returns random positions.)

LineageOS used to patch this on top of android afew years ago, not sure if its still there.

Reply on news.ycombinator.com