Most active commenters
  • stavros(4)
  • devmor(4)
  • apitman(4)

←back to thread

The recently lost file upload feature in the Nextcloud app for Android

(nextcloud.com)
410 points morsch | 30 comments | 14 May 25 05:38 UTC | HN request time: 1.435s | source | bottom
Show context
AmazingTurtle ◴[14 May 25 11:06 UTC] 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 #
1. stavros ◴[14 May 25 15:09 UTC] 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 #
2. TheNewsIsHere ◴[14 May 25 15:44 UTC] 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 #
3. nolist_policy ◴[14 May 25 15:55 UTC] 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 #
4. johnmaguire ◴[14 May 25 16:19 UTC] No.43986316[source]▶
This is basically exactly how Android MediaStore API works too: https://developer.android.com/training/data-storage/shared/m...

The difference is that Android also has APIs (which require user permission and are, at this point, mostly deprecated or heavily discouraged through Play Store policy, hence what happened to NextCloud) which offer filesystem-level access to files created by other apps. This has historically allowed for apps like NextCloud and SyncThing to offer automatic backup or syncing.

SyncThing ran into similar problems recently: https://news.ycombinator.com/item?id=41895718

5. devmor ◴[14 May 25 18:06 UTC] No.43987486[source]▶
>Apple's customers generally have more of a "save us from ourselves" mentality.

FWIW, this could also be described as a "My phone is a tool and not a hobby project" mentality. That is half of what prompted me to change daily drivers from Android to iOS.

I do not get as much freedom for my apps to do whatever I want - but I don't need to do as much work vetting developers or tinkering either. It's a tradeoff of time priority.

replies(4): >>43988128 #>>43988439 #>>43989635 #>>43992554 #
6. immibis ◴[14 May 25 18:50 UTC] No.43987957[source]▶
In a way, it is. You decided to use Google Drive, which means you decided to make your files practically inaccessible to yourself. This isn't a monopolized market, so you have options.
replies(1): >>43992125 #
7. stavros ◴[14 May 25 19:06 UTC] No.43988128[source]▶
I don't know if I agree, my Android phone is a tool just fine. I can make it a hobby project, if I want, but I can just keep it a tool if I don't.
replies(2): >>43988306 #>>43990751 #
8. foobiekr ◴[14 May 25 19:27 UTC] No.43988306{3}[source]▶
Unfortunately, it isn't really practical to have free for all alongside secure by default. Apple is doing the latter, the various non-Google Androids focus on the former.
replies(1): >>43988465 #
9. SahAssar ◴[14 May 25 19:44 UTC] No.43988439[source]▶
I strongly disagree. The difference is "I control my phone vs. my phone is controlled by the vendor".

Or "My phone is a computing device vs. my phone is vendor-specified use-case tool".

replies(1): >>43995065 #
10. stavros ◴[14 May 25 19:46 UTC] No.43988465{4}[source]▶
Why isn't it? I think Android is doing a good enough job doing both, and Apple could have simply allowed unlocking the bootloader. Nothing else would need to change.
11. antman ◴[14 May 25 21:04 UTC] No.43989198[source]▶
Cloud applications can do nil, because the api for the background transfers is only working for iCloud, Nextcloud and other apps in the background get a couple of kb/s effectively pushing you to pay apple. Great Dark pattern from Apple that has been going on for years.
replies(1): >>43997512 #
12. pmdr ◴[14 May 25 21:09 UTC] No.43989252[source]▶
As a user, you're to be no longer trusted with such a thing as full and unconditional access to the device you bought. Browsers are headed the same way. And a large crowd here on HN is okay with this, because "security."
replies(3): >>43989321 #>>43989622 #>>43992510 #
13. stavros ◴[14 May 25 21:16 UTC] No.43989321[source]▶
Yeah, exactly, it's a really worrying trend and one that I really don't want to see continue.
14. apitman ◴[14 May 25 21:54 UTC] No.43989607{3}[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 #
15. apitman ◴[14 May 25 21:56 UTC] No.43989622[source]▶
I was under the impression browsers have been implementing more hardware access, not less, if slowly. What are you referring to?
replies(1): >>43989818 #
16. apitman ◴[14 May 25 21:58 UTC] No.43989635[source]▶
Isn't the process of vetting a developer a subset of the process for finding a good app for doing a certain task?
17. DecentShoes ◴[14 May 25 22:25 UTC] No.43989818{3}[source]▶
Manifest V3? No ad blockers in Chrome?
replies(1): >>43989854 #
18. apitman ◴[14 May 25 22:30 UTC] No.43989854{4}[source]▶
I'm embarrassed I didn't immediately think of that, thanks.
19. ◴[14 May 25 23:18 UTC] No.43990188[source]▶
20. devmor ◴[15 May 25 00:53 UTC] No.43990751{3}[source]▶
Perhaps the ecosystem has changed now, but when I made the switch in 2017, having an Android phone felt like a hobby project. I was regularly dealing with flagship phones stuttering and lagging, apps crashing, media formats not displaying properly, etc.
21. dxuh ◴[15 May 25 05:28 UTC] No.43992125[source]▶
Isn't the submission about this being a monopolized market, because options are being removed (NextCloud - a popular option).
22. franga2000 ◴[15 May 25 06:57 UTC] No.43992510[source]▶
This has been true for a while, but the OP isn't even about full and unconditional access (like root access, which is all but impossible for normal use), it's literally just "sync my files".
23. franga2000 ◴[15 May 25 07:07 UTC] No.43992554[source]▶
This is not about tinkering. My phone is a toolbox, the apps are the tools and Google keeps breaking them in order to make their tools seem better. I need to get real work done using my phone and being able to sync files with a server is a critical part of that. I can't use Google Drive instead for many reasons, but that's besides the point, because this is illegal anticompetitive behaviour.

As far as I know, Apple also doesn't let you sync folders like this, so that's not a solution. And regardless, Apple cripples many other tools that I rely on.

replies(1): >>43993876 #
24. Klonoar ◴[15 May 25 11:26 UTC] No.43993876{3}[source]▶
Your use case is not tinkering. For many others it undoubtedly is.

The person you’re responding to is seemingly just pushing back on the weird idea that iOS users don’t have technical acumen or whatever.

25. devmor ◴[15 May 25 13:48 UTC] No.43995065{3}[source]▶
> I strongly disagree. The difference is "I control my phone vs. my phone is controlled by the vendor".

How many Android phones can be used without Google services?

replies(1): >>43997491 #
26. nolist_policy ◴[15 May 25 16:55 UTC] No.43996925{4}[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.
27. SahAssar ◴[15 May 25 17:48 UTC] No.43997491{4}[source]▶
Most of them? You trade off a lot of features, but you have the choice and can install/do what you want. Sure, I don't like the reliance on google play services but at least there is more choice.
replies(1): >>43997724 #
28. TheNewsIsHere ◴[15 May 25 17:52 UTC] No.43997512{3}[source]▶
I’ve heard this admonishment from the developer community, but I haven’t run into this issue myself. I expect there is some kind of dynamic at play rather than a strict hard and fast rule in the OS.

I’ve got multiple independent apps that do background sync to various destinations and I’ve never had any problems. Depending on how much data and processing is needed for a sync, sometimes they do get stopped by the OS, especially when on battery power, but they resume when the app is opened. This hasn’t been a big issue for me.

Almost all of the problems I’ve had with this kind of workload have been specific to the OneDrive app, and it doesn’t seem to matter whether it’s a SPO/business or MSA/personal account, or whether via the Files app or native app UI.

29. devmor ◴[15 May 25 18:15 UTC] No.43997724{5}[source]▶
No, Google Play services are baked into Android by default. You have to install an alternative operating system to go without them. You cannot use Android in a way Google does not want you to without hacking on it.
30. pjmlp ◴[15 May 25 19:14 UTC] No.43998309{4}[source]▶
Yes it does, nothing forbids someone to write a bit of Java, invoked via Android IPC, no need to be allergic.

Too many folks keep pretending Android is GNU/Linux