Hacker News Reader

Comment by llm_nerd | Hacker News Reader

Google specifically allows the use of the permission[1] if the app falls in a set that truly require it to function.

File managers Backup and restore apps Anti-virus apps Document management apps On-device file search Disk and file encryption Device-to-device data migration

This Nextcloud app seems to be an app that mirrors your Nextcloud storage to your device, and I cannot understand why it would need all access to any other data stored on the external device -- with the enormous risk that entails -- much less that can't be selectively picked by the user. It isn't a file manager, it isn't a backup utility, it's a cloud provider with local mirroring. I get why Google told them to do things otherwise.

Another comment mentions this is "bad faith" security and that's just overly cynical. Android and iOS both suffered from basically trusting app developers, and both were burned for it. Hardening down and making apps only request precisely what they actually need seems to be a massive user positive.

[1] - https://developer.android.com/training/data-storage/manage-a... - the exclusions can be found at the bottom.

View on HN

Depends how you use it: I suspect people want their entire photo folders mirrored into Nextcloud from the device, which would fit under the "backup utility" category.

> what they actually need seems to be a massive user positive

So positive for the user that they filed a bug report about it?

It is a long-standing policy, not a "bug"[1]. Further it isn't the users complaining, it's a company of a fringe "cloud" product. I'm going to be gentle here and say their app looks incredibly shitty, and I suspect they saw an opportunity to get some free press on the "Google the monopolist" angle.

>I suspect people want their entire photo folders mirrored into Nextcloud from the device

That isn't remotely the contention, nor do photos even qualify for this as they use a different API. Further, the reason this company gives for refusing to use the obviously more suitable structured storage API is that they don't want their files -- presumably mirrored from the cloud storage -- visible to other apps. Their complaint is technical nonsense and doesn't pass an ounce of scrutiny.

The argument by this company is nonsensical, and their argument seems to be "we did it this way before and we don't want to change". Firstly they can have their own app storage without granting access to any other app, and they can go through a system UI process to get access to additional folders (for instance "I want to back up my WhatsApp folder to this cloud provider"). They argue against the latter because they seem to think it somehow reveals the former, but that isn't the case whatsoever.

[1] - Well it's a bug in the Nextcloud product where they seem to just ignore that the instance lacks a permission

It is the users complaining, or rather specifically a user: https://github.com/nextcloud/android/issues/14135

The user is complaining that the app isn't using the proper APIs. For instance in the case of the "exactly" guy, the app would use structured storage APIs to let the user grant permissions to backup their WhatsApp folder. Instead of fixing their app the company instead whines to the press and gives technically nonsensical rationale for why they can't just do the work necessary because "we did it this way before and they let us for a while, so..."

9 years of the api working, then Google shuts them down. I expect an interface to be consistent after working for 9 years.

I think they're trying to keep their story simple, for the sake of clarity. I believe the nextcloud team when they say they need the permission.

Part of the issue is that nextcloud has many use cases, including ones where your files don't get synced to your mobile device until you touch the file, replacing them with a reference to a file. It's cool cause you can access and manage a tb of pictures or documents from a 64gb android.

> I believe the nextcloud team when they say they need the permission.

I don't (and I do use NC). The sentence "SAF cannot be used, as it is for sharing/exposing our files to other apps" is simply wrong and llm_nerd is right that SAF should be able to handle that use case,see

https://developer.android.com/training/data-storage/shared/d...

There are some restrictions regarding which directories you can access, but for most use-cases it should be perfectly fine. It's also not that this should come as a surprise to them. In fact, there's an issue about this from the NC team themselves from August '22:

https://github.com/nextcloud/android/issues/10123

Why they still think SAF cannot be used is a mystery to me.

> I expect an interface to be consistent after working for 9 years

Even if that interface is insecure and harmful to users ?

As an industry we've learnt a lot about how apps siphon and sell your data. And I appreciate this probably doesn't apply to NextCloud but it can be difficult to build an API that is flexible and secure so you will get casualties.

How is this interface "insecure and harmful to users" ?

Shady apps use file access to do tracking of various sorts and simply ingest private data that has nothing to do with their nominal purpose. Sophisticated users probably wouldn't install those apps, and certainly wouldn't agree to their request for filesystem access, but that's not who Google is trying to protect here.

It's obviously not a security problem or a harm when used by an open source file synchronization app, and Google is being unsophisticated with its policy here.

Do you have links to stories about any of these shady apps that have now been stopped by this policy?

Most of the time, when apps are caught doing something really shady, they're removed from the Play Store for doing the shady thing. A story wouldn't report that they stopped working because of a policy change, but some of these wouldn't make it into the store now:

https://www.bleepingcomputer.com/news/security/apps-with-15m...

https://www.zdnet.com/article/phantomlance-spying-campaign-b...

https://www.welivesecurity.com/2023/05/23/android-app-breaki...

There are also examples of apps using the filesystem to try to detect rooted devices, an invasion of user privacy:

https://www.reddit.com/r/Android/comments/g6cdl6/apps_have_a...

Thanks, definitely looks like it's been abused.

But does the policy solve this problem? The first link is a file explorer app. In theory that app should be granted the permision by Google. They could get established and then start collecting data later. So how does the policy help?

In practice the only way it helps is by Google basically telling everyone other than big trusted orgs no, and that's not an open ecosystem.

Why not just give the user a big fat warning, even telling them that apps which request this permission have been known to steal data in the past, then let them decide for themselves?

It reduces the attack surface area, and in theory allows more thorough vetting of apps that are eligible to use the permission without spending additional resources. I say in theory because I have the impression Google wants this to be almost entirely automated and isn't actually doing a good job vetting apps that use risky permissions.

> that's not an open ecosystem

No, it is not. Did someone claim it was?

The open ecosystem of Android is that users can choose to install apps from any source they like. Apps like Syncthing-Fork and (full-featured) Nextcloud are available from other sources including F-Droid. Google does a couple things to privilege its own store, though I think those are being mitigated due to legislation and litigation.

> No, it is not. Did someone claim it was?

No, we said that's what we want it to be.

Maybe they should not remove APIs for open source apps then. If you can vet the source code and the app has been built from the source code you vetted, then there is no point in removing capabilities for reasons other than market monopolization and extinguishing features for non-Google developers. After all, these security rules don't apply to Google themselves.

(btw, not singling out Google - IMHO Apple is bad here too. This duopoly in the smartphone space is a major PITA)

It really could.

> to let the user grant permissions to backup their WhatsApp folder

So a backup app should add support for every Android application that the user is likely to back up?

No, not at all. The new API simply presents a directory picker to the user. The user can give your app access to any directory.

Any directory that Google lets you access, which is very far from every directory.

For example, without using Google'' backup you can't backup the data of other apps, such as games' progress.

I'm a user. I install through fdroid, but I am complaining. This also makes corporate roll-outs more difficult.

> I suspect people want their entire photo folders mirrored into Nextcloud from the device, which would fit under the "backup utility" category.

Exactly. Many people use Nextcloud's auto-upload to backup important data from their phone. In addition to photos, I use it to backup FreeOTP and WhatsApp, for instance. This does not work with the version from Google Play, see

https://github.com/nextcloud/android/issues/14334

EDIT: After some research, I think even that use case should be possible with SAF, you just need to move your backups to external storage that you can access via SAF.

yes, exactly - it has an "AutoUpload" function that worked super well. Make a photo and by the time you put the phone down its on a folder on your desktop read for say putting something on eBay.

it stopped working well or at all over the last 2 years or so. I think if a simple "allow access to the photo folder" would have fixed it they out have used it. maybe it doesn't get the events when a photo is made?

> people want their entire photo folders mirrored

Then request access to their media folder. You don't need full disk access.

WhatsApp media lives in separate folder.

PDFs that I download live in downloads folder (which you can't give access to for some reason anyway).

Music lives elsewhere and so on.

You can grant permission to multiple folders you know.

Downloads is blocked because it would include everything you download, possibly including private stuff you don't want other apps to access. Just save the stuff that you want synced to a different folder.

I guess if you really want everything synced (e.g. doing a full device backup) then that would fall under Google's exception for backup apps and it would be allowed full disk access. Those are kinda separate use cases though. Maybe Nextcloud could make a separate "Nextcloud Device Backup" app which does that?

> You can grant permission to multiple folders you know. I had to deal with another application (the only one that I found that for using my webdav solution does not automatically want to collect data and send it somewhere else) which instead of make backup of SD card was backup one folder - set server, password etc. for ONE folder PER backup action.

- If you want to lose time for 2 hours, please do yourself this questionable favour but I do not want to do that because some "wise" people cannot comprehend that some people want copy of entire thing, not one folder, entire thing.

> Downloads is blocked because it would include everything you download, possibly including private stuff you don't want other apps to access. The point: This is cloud application that connects to server that sits on my desk on NUC.

Do you understand that in the (Google)-(Open Source)-(Own Server) the Google part is one that most reasonable people consider not private.

> Just save the stuff that you want synced to a different folder.

Do you move entire folders or every file each time you download something because app cannot backup it - or do you change app. What if that's the only app that does it privately?

> Those are kinda separate use cases though.

Maybe it is not system developer job to decide for me that I want to give application the permission to do what I want application to do. It is not system nor developer job to stop owner (administrator) from what owner decides to do.

> Maybe Nextcloud could make a separate "Nextcloud Device Backup" app which does that?

Maybe competitors should not have permission on deciding what their competitors should do.

Google essentially makes everything private so cumbersome to use that it own solution seems easy.

The app is a competitor to google drive (app). It is used to upload/download, backup, syncronize (one or two way) files, media and documents between the device and the cloud. Doesn't that cover more than one of the mentioned uses? Why would FilesyncPro (example) get to have the permission but not nextcloud client? Even for media files specifically there are a lot of gotchas without full file access, like risk of location being stripped from all images synced trough the app (unless user gives media location permission) or similarly missing exif.. To upload on change it needs to be allowed to watch the filesystem

Meanwhile google drive gets to be installed as a system app

It's not just mirroring of your remote storage, you can also upload local files manually, turn on auto-upload for some directories (the main use case is uploading pictures) ant there was recently work being done to enable two-way-synchronization for directories that the user would like to sync. IMO it makes sense to let the users give it access to all the files on the phone, if they whish to do so.

For those scenarios, structured storage fits the bill. The app requests folder permission and the user, using system UIs, grants permissions on the folders they want to enable.

>it makes sense to let the users give it access to all the files on the phone

It doesn't even pretend to be a backup app, and further the permission we're talking about is limited to external storage (though that is a nebulous term on many Android devices where internal storage is split-brained on being internal and partly external).

Further saying "let the user decide" works great in theory and with a considered, rational userbase. In reality it means that everyone just says sure to everything, and soon all of the user's data is exfiltrated and everyone is whining that Google/Apple/et al should have forseen this.

> For those scenarios, structured storage fits the bill. The app requests folder permission and the user, using system UIs, grants permissions on the folders they want to enable.

I see your point, but why isn't this the case for document management apps? Also, Nextcloud can be extended with plugins, some of them falling in the document management category.

> Further saying "let the user decide" works great in theory and with a considered, rational userbase.

Nextcloud is mostly used by people that like to self-host their services, so in this case we fall into the rational userbase category.

It is what e.g. Simple Gallery does. It works well. Nice API.

https://play.google.com/store/apps/details?id=com.simplemobi... or on github.

What are you referring to? Looking at that link, I see little overlap with what Nextcloud offers. There's a lot more in it than just a pretty gallery.

The overlap is precisely that part which matters: The directory access portions. Both need to ask the user to choose which directories to access, and access all the files in those directories.

What they do after opening the files is very different, and irrelevant. FWIW I use both Nextcloud and that gallery app.

FYI: The Simple Mobile Tools suite was acquired by an ad network and is pretty much discontinued, see

https://www.androidauthority.com/simple-mobile-tools-acquisi...

Use the Fossify fork instead:

https://play.google.com/store/apps/details?id=org.fossify.ga...

It seems I escaped, by paying the original developer €1 a long time ago. https://play.google.com/store/apps/details?id=com.simplemobi...

The problem lies that in newer Android versions (11 or higher) you cannot give permissions to arbitrary folders, it's only "shared folders" or "all the files" [0][1] (It's also explained in TFA)

I'm sure they would happily allow you to select the folders you want to give permissions to, but I think that's not possible anymore.

So if you want to sync a local data folder that stores, for example, the tracks you record with your GPS, you cannot do it without full access unless your GPS app allows you to select a shared folder to store its data.

  0: https://developer.android.com/about/versions/11/privacy/storage
  1: https://www.theregister.com/2025/05/13/nextcloud_play_store_complaint/

edit: restructured a confusing sentence

You're misrepresenting things I think.

You can select any file you could before on shared external storage. You can't select private app directories which were always off limits from other apps just like on iOS.

From what I see (and what I've experienced on different sync apps when upgrading Android versions, although I'm not a developer, just a user), access to /Android/data and /Android/obb changed on Android 11:

---

  [0] On Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT_TREE intent action to request access to the following directories:
  - The root directory of the internal storage volume.
  - The root directory of each SD card volume that the device manufacturer considers to be reliable, regardless of whether the card is emulated or removable. A reliable volume is one that an app can successfully access most of the time.
  - The Download directory.

  Furthermore, on Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT_TREE intent action to request that the user select individual files from the following directories:
  - The Android/data/ directory and all subdirectories.
  - The Android/obb/ directory and all subdirectories.

---

  [1] On Android 11 (API level 30) and higher, you cannot use the ACTION_OPEN_DOCUMENT intent action to request that the user select individual files from the following directories:
  - The Android/data/ directory and all subdirectories.
  - The Android/obb/ directory and all subdirectories.

---

  0: https://developer.android.com/training/data-storage/shared/documents-files#document-tree-access-restrictions
  1: https://developer.android.com/training/data-storage/shared/documents-files#document-access-restrictions

---

edit: fixed readability and a link

/Android is a private app storage and is documented as such.

Yeah, yeah, I know. I'm not saying that it's good or bad, I just say that some people like to sync/backup/copy their apps data (that sometimes it's located on private directories, or in the Downloads folder...), and they were able to do it before. And that the new API has less permissions than the one that Google wants them to use.

Google Play, or at least that's what they say in their docs, might allow the use of the MANAGE_EXTERNAL_STORAGE "all files" API call "...if your app includes a use case similar to any of the following: File managers, Backup and restore apps, [...] Document management apps ..." [0][1]. And the Nextcloud app sounds very similar to that.

Of course, it's all "Subject to Google Play review and approval.", but why they used to grant that permission to Nextcloud with no problem and revoked it suddenly... I have no idea.

---

  0: https://developer.android.com/training/data-storage/manage-all-files#all-files-access-google-play
  1: https://support.google.com/googleplay/android-developer/answer/10467955#zippy=%2Cpermitted-uses-of-the-all-files-access-permission

Note that `MANAGE_EXTERNAL_STORAGE` permission doesn't allow access to /Android anymore either (it's blocked by OS permisisons) so it won't help Nextcloud to retain it either.

Thing is, Nextcloud doesn't need that permission since they can do what they do now with SAF which is how Google determines eligibility for the exception. That is - if you can do it with SAF, you don't need complete access to all private data via MANAGE permission.

I think TFA is wrong.

It is correct that you cannot access private app folders, meaning stuff like /data/data, /Android/data, /Android/obb. But this is nothing new and you basically need a rooted device to access them. You can however access anything on external storage, which is typically where apps would store data you would want to sync and which would cover by far most use cases from users. At the moment, users are mostly complaining that only media files are synced, but not documents. SAF would solve this.

> I'm sure they would happily allow you to select the folders you want to give permissions to, but I think that's not possible anymore.

That is absolutely possible:

https://developer.android.com/training/data-storage/shared/d...

Well, it used to be possible before Android 11, that's the thing.

So, following a bit the example I was giving, if you want to sync data from another app to backup it (or whatever), and that App stores its data in the default data folder assigned by Android, since Android 11 it's going to be very difficult to do it.

I used to sync some of those folders with Syncthing in Android, and since Android 11 things have gotten complicated (meaning, you need 'all files' access, and even then, some things might not be accessible). [0]

  0: https://forum.syncthing.net/t/android-11-and-syncthing-what-can-be-synchronised/17100/2

Hello, we and TFA are talking about the new API where the user picks what directory an app has access to vs. the old API where the app has access to almost everything as you pointed out.

The Google Play store (not Android the OS) is now limiting access to the old API, it has nothing to do with Android 11.

The new API does not work with Linux open(). Some projects (like Syncthing) don't want to put in the work to switch to the new API.

I hope that clears things up.

Yeah, I'm not saying that you're in the wrong, I'm saying that they might want to access further than the new `ACTION_OPEN_DOCUMENT_TREE` API call allows. For example, the Downloads folder (you can only open individual files with ACTION_OPEN_DOCUMENT, not the whole folder). And that can be reached with the `MANAGE_EXTERNAL_STORAGE` (all files) API. Is that OK? Well, it's not intrinsically bad, but it clashes with Google's Android hardening directives.

Not very familiar with the NextCloud client, as I haven't used it much, but in the case of Syncthing (and this is totally guessing from what I remember from reading the forums back when the Android 11 upgrade happened): I don't think they don't want to put the work to switch to the new API, I think they want to access places they won't be able to access with the new API, so that's why they won't change the calls.

It's doesn't work with native code.

Yes, you'll need a little bridge to get a ParcelFileDescriptor. Lots of stuff in Android does not work directly with native code (Permissions, Camera/Media recording, HttpURLConnection, sensors/location services, ...), and storage access is now sandboxed in a similar way and needs a few lines of Java/Kotlin. I fully see that this is annoying, and Android is tiring developers with constant changes like these, but on the other hand, I guess most people would agree that securing storage access is a good thing.

It would not be much effort at all for google to make native hooks into these APIs. Certainly less effort than dealing with constant complaints from developers. It feels like they're trying to force lock-in.

With file access, the sensible solution would have been of course to just overlay the permissions onto the regular files API (like I think every other sandboxing solution does), so everything that uses files could keep working as usual and you'd just have to add some limited code to request the appropriate permissions [1], but I guess that would have been too sensible, and when all you've got is a SAF, everything looks like a nail or something…

From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that, doubly so when you're using a library that expects regular files, plus performance is somewhat lacking, too (judging from complaints and bug reports I've seen, both in that it is easy to run into performance pitfalls, but also that even best-case performance is still worse than classic file access).

[1] I think something like that was actually implemented for Android 11 onwards, judging from https://source.android.com/docs/core/storage/scoped#using-sc...? Although possibly still at some noticeable performance cost.

> From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that

That pretty much matches my experience. Single file picker flows can often be implemented with a simple callback.

But for folders it falls apart.

Thanks for mentioning scoped storage. Maybe that provides some sort of solution. I vaguely remember when I was first dealing with this circa 2021 that they had some sort of a low-performance solution that was supposed to work for NDK code.

KDE Connect allows me to browse the folder I picked and upload/download files just fine, using SAF. You point the app at a directory, click "grant access", and you have permanent access. The only problem I can think of is that some directories are restricted (https://developer.android.com/about/versions/11/privacy/stor...) because they're a dumping ground for files already.

SAF provides both provider and consumer APIs, and from the language NextCloud uses, I get the feeling they might've missed the consumer API here. Had NextCloud said "we want the user to be able to select the Download folder and certain external media directories" then I would've thought the restrictions are the main problem, but that doesn't seem to be the case here.

This is all guessing by me, but I think that, traditionally, there's been a certain quantity of users that synced folders out of the /Android/data or similar locations and/or needed some extra flexibility. When Android 11 arrived, it was difficult to break that workflow for all those users (and I guess there was also some re-architecture needed for the app, but I don't know how much would it be).

I went through the same with Syncthing, and now I install it from out of Google Play, where it doesn't need Google approval to do the All Files Permission API call.

I understand why the API changes and the hardening of the Android system, but it's also true you're locked out from certain folders even when on developer mode and it feels weird.

It's worth noting that SAF does not work with native code.

I wonder if google’s drive app is subject to the same limitations, though.

It is.

Hello there, it seems I was indirectly mentioned..

So let me ask you, how does this:

> Hardening down and making apps only request precisely what they actually need

Relate to Google Play Services? It seems to relate only to third party apps, doesn't it?

> This Nextcloud app seems to be

Right, so you don't know the app. What about getting informed first?

I use Nextcloud to backup files to the cloud. I want it to access my files.

And you can let it if they use Storage Access Framework to ask for that permission without them requiring blanket access to all your private data.

Perhaps you should get informed as well.

In the end this is again app developers refusing to do the work to protect privacy and trying to push through the laziest most privacy voilating solution because it's less work.

> Perhaps you should get informed as well.

What did I say that was wrong? The comment I was answering to - that I assume you read - says: "This Nextcloud app seems to be [...] It isn't a file manager, it isn't a backup utility, it's a cloud provider with local mirroring."

Which is wrong, isn't it?

The person you are replying to has not denied anything you said, nor have they given any indication that they need to get informed. Your comment is wildly misplaced.

Reply on news.ycombinator.com