←back to thread

410 points morsch | 1 comments | | HN request time: 0.204s | source
Show context
AmazingTurtle ◴[] No.43983064[source]
We feel your pain at Nextcloud. Our team at Everfind (unified search across Drive, OneDrive, Dropbox, etc.) has spent the past year fighting for the *drive.readonly* scope simply so we can download files, run OCR, and index their full-text for users. Google keeps telling us to make do with *drive.file* + *drive.metadata.readonly*, which breaks continuous discovery and cripples search results for any new or updated document.

Bottom line: Googles "least-privilege" rhetoric sounds noble, but in practice it gives Big Tech first-party apps privileged access while forcing independent vendors to ship half-working products - or get kicked out of the Play Store. The result is users lose features and choices, and small devs burn countless hours arguing with a copy-paste policy bot.

replies(6): >>43983826 #>>43984105 #>>43984961 #>>43985478 #>>43986485 #>>43987706 #
stavros ◴[] No.43985478[source]
As a user, this should be up to me to decide, not up to Google. However, I do find it odd that Apple can get away with it much more, because Apple's customers generally have more of a "save us from ourselves" mentality.
replies(5): >>43985889 #>>43987486 #>>43987957 #>>43989252 #>>43990188 #
TheNewsIsHere ◴[] No.43985889[source]
Apple’s implementation of enabling access to files is entirely different. I actually much prefer it because it sidesteps the self-dealing permissions bomb that Google just set off.

In iOS, applications can use the File Provider API to present themselves in the Files app. You can move/copy/delete data there using the normal human interface constructs native to iOS, including mouse support and keyboard shortcuts on iPadOS.

Apps can also present the same directory internally (inside the app). Cloud-backed applications can then do useful things like materialization, eviction, and dataless file presence.

It doesn’t allow standing access to the entire filesystem, though. iOS only has support for applications reading outside their sandbox if the apps are from the same developer, and then they can call a pooled storage location for all apps that share the same “Team ID” (e.g., top level developer account/organization).

It’s actually far easier (functionally) to grant access to your entire photo library, so for example you can have an app query and backup your photo library.

“True” filesystem-wide backup requires hooking into the iOS backup/MobileFile hooks. Apple isn’t as hostile to third parties doing that as Google is to anyone accessing their own device data. But the process is more cumbersome by far.

replies(3): >>43986039 #>>43986316 #>>43989198 #
nolist_policy ◴[] No.43986039[source]
> In iOS, applications can use the File Provider API to present themselves in the Files app. You can move/copy/delete data there using the normal human interface constructs native to iOS, including mouse support and keyboard shortcuts on iPadOS.

> Apps can also present the same directory internally (inside the app). Cloud-backed applications can then do useful things like materialization, eviction, and dataless file presence.

In Android apps can do all this with the SAF API.

More importantly, on Android the user can give multiple apps access to the same directory, allowing apps to work together with files. iOS doesn't allow this AFAIK.

replies(1): >>43989607 #
apitman ◴[] No.43989607[source]
SAF doesn't work with native code, which really sucks if you're trying to make a cross-platform app.
replies(2): >>43996925 #>>43998309 #
1. nolist_policy ◴[] No.43996925[source]
Native code can work with files inside the app data folder. Then you can expose that folder with SAF in a separate Activity. Termux does this and it works really well.