←back to thread

397 points opengears | 3 comments | | HN request time: 0.001s | source
Show context
jasonjayr ◴[] No.41896030[source]
From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064

> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.

replies(1): >>41896431 #
izacus ◴[] No.41896431[source]
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.

Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.

replies(8): >>41896508 #>>41897183 #>>41897242 #>>41897307 #>>41897422 #>>41898178 #>>41899343 #>>41900928 #
1. NotPractical ◴[] No.41899343[source]
SAF is a slow, buggy mess, and it only works in Java/Kotlin, so it's understandable that they don't want to use it. GrapheneOS manages to allow native access (via Java or machine code) to only specific user-selected directories through its Storage Scopes feature [1]. They basically did SAF but correctly and without the funding of a megacorp.

[1] https://grapheneos.org/features#storage-scopes

replies(1): >>41899435 #
2. gruez ◴[] No.41899435[source]
>They basically did SAF but correctly and without the funding of a megacorp.

It's also way more clunky for the user than using the file picker, and has the potential for user confusion because the app is silently denied access so it thinks the file/folder doesn't exist.

replies(1): >>41899474 #
3. NotPractical ◴[] No.41899474[source]
You're right, it's far from perfect, but it shows that it's not difficult to restrict native access to specific files/folders using the kernel and not weird Java IPC (which I guess should be obvious anyway). Google could've opted to provide native access to files, in addition to access via SAF, when you select a file via the picker, but they didn't. Graphene did it correctly from the low-level implementation side, not the UX side (but they can't really make the UX easier without breaking compatibility with standard Android apps AFAIK).