Hacker News new | ask | show | jobs
by yieldcrv 1452 days ago
right, since the popup for permissions is in the app when its requested

I would like more permissions to be different than all or nothing though. I wish you could segregate contacts. like, if I don't tell people around me that I know a high ranking official, why should a random app just because one of us uploaded our contact list.

4 comments

That's only for 'dangerous' permissions as defined by Android.

As an example: NFC is defined as a 'normal' permission.[0]

As far as I'm aware [not an expert here], there's nothing stopping an app developer from updating their app with the ability to steal credit card/passport information (if the card is tapped against the phone).

[0] https://developer.android.com/reference/android/Manifest.per...

Credit cards can not be duplicated wirelessly. I’m not familiar with passports but if they can then I’d say that’s a flaw of the cards rather than phone permissions. It’s possible to read nfc cards from quite a distance with a high power reader.
Do you have a source on that [credit cards]?

From a casual further inspection, there are videos on YouTube which demonstrate this: https://www.youtube.com/watch?v=K_6oMZb8UOI

Someone else can probably give the technical details but from my understanding, all but the most primitive NFC cards use a challenge/response system rather than just an ID. So there is no way to actually clone the secret stored internally as this is never transmitted.

I'm willing to bet that video is just plain fake. Especially given it only has 2k views.

I'd put stock in the video, it's using https://github.com/devnied/EMV-NFC-Paycard-Enrollment which seems reasonably popular.
I mean Apple still manages to list all IAPs even those only happen on prompt.

The thing users want isn’t what permissions the app could possibly request, but what permissions are required to use what specific features of the app.

Absolutely! And if the features are at all usable/trial-able or need an in app purchase, and is useless without. I feel tricked so often. Currently I need to install an app and try it before I can have much idea if it does what I need. Reviews are of limited use.

I very much appreciate apps where I can trial or subscribe for a short period for a small price. If they do what I need I always end up buying or not cancelling the sub.

This sounds a little contradictory (too tired to word it better right now) but I hope the general feeling is conveyed.

Users don't want to have to understand a permission model to use an app.
I want to know if an app will launch itself on device startup, and I can't see that any longer with "data safety". There are other permissions that are now similarly hidden. I appreciate that less tech savvy Android users might benefit from a simplified view, but I wish they'd give the advanced user an option to view details (and, ideally, the ability to reject ANY permission).
I agree. An inportant one for me ia the filesystem. Why can't I segregate Whatsapp to a single directory?
Google made scoped storage mandatory in Android 11 and later[1], this can restrict to just the app's own directory but people usually want to share media from outside the app's directory so they request the additional access.

[1] https://source.android.com/devices/storage/scoped

Google "solved" this by making storage access between apps no longer a thing:

https://developer.android.com/about/versions/11/privacy/stor...

3rd parties solved this with optional Storage Isolation:

https://play.google.com/store/apps/details?id=moe.shizuku.re...

Well, that would imply one of two things:

- Whatsapp keeps all its internal data in your Photos folder.

- Whenever you want to send someone an image, you need to manually copy the image from wherever it is to the Whatsapp folder.

Nonsense. Selecting a file to share without giving access to all files is already a solved problem via file pickets.
The basic use case works, but quite a few things beyond that are broken. None of the various sandboxing attempts (not just Android, but everything) properly handles multi-file file formats [1], so that alone is very much not a solved problem!.

Keeping an LRU list for files that were opened from outside of your own app becomes needlessly complicated [2].

Access gained that way isn't directly compatible with things expecting classic File API access (and sometimes those things are outside of your immediate control, like external libraries and even parts of the Android framework itself), and unfortunately the easiest workaround to that problem is just copying the file into your own private storage.

[1] As far as I'm aware, only macOS attempts to at least handle related files that only differ in their file extension, but even that still doesn't cover more complex file formats like playlists, or HTML or DWG files or whatnot that can reference arbitrary other files.

[2] If the same file is shared via different apps, the way things have been implemented on Android it becomes more complicated for the receiving to check whether those two incoming file shares actually refer to the same underlying file or not. Plus for an LRU list to make sense you need to try persisting the file permissions so you can still access the file later on [3] and also especially take care not to leak those permissions when you clean up the LRU list.

[3] Which also leads to some strange scenarios like when you switch to a new file manager and uninstall the previous app, all LRU entries in other apps that were originally opened via that previous file manager now suddenly become invalid.