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.
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.
It's likely a lot less about giving Google's first-party apps privileged access than it is a super low priority for the team to allocate engineering effort to.
I was a PM in Google Workspace for several years. It's a lot less nefarious than it probably seems. Decisions are optimized for revenue and other features (especially for enterprise customers) are going to be much higher priority.
Companies choosing to focus on enterprise revenue (which is basically all of them since like 2012) do so at the cost of end-user satisfaction.
Sounds like it's time for an(other) antitrust lawsuit. At least Nextcloud is based in Europe, which has recently shown an appetite to stand up to tech giants on some things.
Perhaps feature-gate the things that are broken for Google builds, so you can have the functionality available in other channels? Personally, I prioritize installing apps from F-Droid over PlayStore.
AOSP platform dev here. (Filesystem) Opinions my own, I don't speak for Google.
Disclaimer: I don't use nextcloud, and have not looked at their app specifically, this is just a surface level observation from my relatively informed perspective.
My take: SAF would work for this use case, as others have already mentioned.
Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to, and is delivered via the Play store in the same way nextcloud's app is.
As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
SAF is not an option because it is HORRIBLY slow[1][2][3][4][5], which makes it an absolute no-go for any decent cloud synchronization app.
Excerpt from [1]:
> SAF is slow. Every SAF file IO operation takes like 20-30ms because it uses an IPC call. And sometimes you may want to check whether a lot of files exist on the disk and if they do not then create them (or something similar that requires a lot of file operations). It's so slow that even in google example they use hacks to make it faster.
Excerpt from [3]:
> Just to add a new sample for the performance of SAF vs standard File operations:
> […]
> 15 seconds with SAF, 6 milliseconds with native ls ! And there's only 128 files LOL
> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
The lack of consideration for this point in this thread scares me. The amount of data that can be taken from a device through a permission like this is likely huge and it’s not just about “protecting users from themselves”. I wouldn’t feel safe enabling it for any app, and while syncing all data on the device sounds very useful, it’s a damned if they do, damned if they don’t scenario for Google.
Let me guess, loan shark apps, or is there something even worse that I wasn't aware of?
(Essentially ransomware that people "voluntarily" install in order to get a predatory loan, often without knowing how it actually operates. If they fail to pay, not only is their phone locked, but the data from it is used to threaten/extort them, from threatening to send their nudes to their contacts to death threats to relatives identified from the data - https://www.welivesecurity.com/en/eset-research/beware-preda...)
> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
I understand that great care should be taken when this permission is granted to new apps, but NextCloud is well known and on top of that it is a file management app. If anything, apps like that should have this permission.
If you plan to phase it out completely, then the alternatives have to be good enough, which judging from some of the child comments, they are not. I have never developed for Android (and likely never will, because of stuff like this), so I cannot judge properly.
It's also my understanding that the Google Drive App is just some UI over cloud storage. All the interesting bits like Backup are not handled through it and Google Drive gets preferential treatment for this. Additional permissions are required to emulate such functionality.
SAF is a terrible solution for anyone trying to make a cross-platform app (and if you're not then why are you targeting Android as your one platform?), because it doesn't work with native code.
Totally unrelated question but since we're talking filesystems on Android here, I have been incredibly annoyed that AOSP devs disabled "special" characters ":<>?|* in file names in Android 11[0], probably to achieve compatibility with NTFS/FAT. Unfortunately, not only does this make some (especially older) applications accidentally crash when I want to use, say, a question mark in a file name, I can also no longer sync all my files from my Linux machine to my phone.
Now, there is probably little chance for this to get rolled back entirely. But maybe one could make it an option in the developer settings to allow ext4 filenames like before? Do you see any chance your team could be convinced of such a move? And where would be the appropriate place for me to raise this issue and/or contribute a patch?
The problem with the SyncThing Android app is that it's just a wrapper around SyncThing, which is a Go library, but SAF does not give you simple file descriptors you can use in native code. Instead, you get "content://" URLs, and you need a Java/Kotlin bridge to convert these to file descriptors. That would need to be done in SyncThing itself (EDIT: or some other trickery, because it seems like syncthing-fork made it work somehow).
However, AFAIK, this problem would not apply to the NextCloud app.
> SAF cannot be used, as it is for sharing/exposing our files to other apps
SAF can be used. There are reasons why this wouldn't be a good fit for NextCloud (you can't share your entire internal storage, your download folder, or the root of an SD card, for instance), but I don't think NextCloud's statement makes sense.
The point of their app is to backup an entire folder. Sharing from one app to Nextcloud doesn't provide ongoing access to backup later versions of the file.
Just to make sure: Google software has the same exact permission structure across the board? e.g. No Google product uses the same permissions NextCloud is seeking, and instead, they are using SAF? Especially for things that do what NextCloud is doing here.
I just want to be sure that Google is playing by the same rules they they put out for NextCloud and other app developers.
If they refuse to invest in the burden of due diligence required to allow others to operate exactly as they do, then they don't deserve to be managing the field.
It's costly to supervise? Ok, then charge companies a token fee if it's a burden to monitor. Locking other players out is not the appropriate response
Google has reached out to Nextcloud and offered to restore the permission. Wonder if the decision was motivated by the technical arguments or if the antitrust trial and various mentions in the press were a persuading factor.
This is exactly why the EU's Digital Markets Act exists. And why it needs teeth. Google disabling Nextcloud's all-files access on Android, while quietly letting its own apps and big corporate players keep it, isn't about "security". It's about control. Nextcloud is a European, privacy-first alternative built on open standards and that can be fully aligned with GDPR requirements. Blocking its core functionality while favouring your own services is a textbook abuse of platform power. Android was supposed to be open, but moves like this show it (at least the Play Services verison) is just another walled garden. If the EU is serious about digital sovereignty and fair competition, this is the kind of behaviour that must be stopped. Otherwise, no European tech, no matter how compliant, open, or user-friendly, stands a chance.
What apps in Google's ecosystem have the "all files" permission? Google Drive certainly doesn't. The "upload" button on GDrive prompts you to select a file just like NextCloud does.
The "sync just one folder" functionality exists in SAF without any high-risk permissions. Migration of existing profiles may be a pain (as the user would need to grant permission on the folder when switching to the new API).
Synchronisation of the entire virtual storage, the download folder, or any extra folders vendors like Samsung might've added to the blacklist, isn't possible with the new API, but it's also not possible with Google's own services. The DMA only requires Google not to be put in a special position; as long as they don't offer such a feature, they don't need to offer it to NextCloud.
Waiting for the nitpicker crowd "you can install AOSP and/or sideload APKs easily, so there is no incumbent abuse here!", just like we had them for IE (you can install another browser) and iPhone (you can buy another brand).
Edit: oh we already have them in the other submission
Mobile is a second class operating system platform. A browser or OS you use on a desktop can easily be configured to block/filter things. Mobile users are exposed to popups/malware/DNS hijacking daily. If they didn't, mobile would not be the gravy train of clicks for advertisers.
Punishing Google for preventing apps from reading all your private data at a whim is quite a take to involve EU for.
Without this enforcement, malware games and apps like Facebook were just uploading your photos and scanning their EXIF locations under the guise of "needing all access".
And as we found out in existing topic, the better privacy preserving APIs exist, Nextcloud just doesn't want to use them.
Google has a history of creating first-party-only APIs to give their own Android apps an edge.
In 2014 Google split their drive app into multiple separate Android apps for docs, sheets, etc. Obviously getting users to install and migrate to new apps would be a burden, so they designed a 1-click install modal that Drive could use instead of the typical redirect-to-Play-Store flow. Neat!
Around that time the company I worked for (large competitor of Drive) was about to split out some core functionality into a standalone app and wanted to use a similar flow for similar reasons - Nope! Google locked that API behind an app signature verification (not even a permission) so only Google signed apps could use it. No possibility to request the permission or appeal - just a hard-coded monopoly.
There ARE legitimate reasons that things like this can be risky and abuse needs to be mitigated, but there's a line that Google regularly crosses between abuse mitigation and anti-competitive behavior.
None of Google apps use the permission Nexcloud wants. The only exception is the preloaded "Files" file explorer app which doesn't integrate with clouds.
Google's former motto, "Don't be evil," was a key part of their corporate code of conduct, emphasizing ethical and transparent business practices. In 2015 the motto was removed, since then we are in their clutches. Now they are like Microsoft, that's the reason Nextcloud was created!
From my reading, the new API seems like a move in the right direction. But either way, Google is asking Nextcloud to silently break backup/sync-ing until users grant permission, and my guess is that many users won't notice until they discover data loss - the damage to trust and brand would be substantial. And I don't think it is fair for Google to demand in this case when the consequences are almost entirely felt by the users.
* App is allowed to decide if I can (manually) take screenshot/ocr the screen - usually it's banking app, that wants me to remember some long number - then I write it on closest piece of paper - awesome security. No workaround as far as I know.
> App is allowed to decide if I can (manually) take screenshot/ocr the screen - usually it's banking app, that wants me to remember some long number - then I write it on closest piece of paper - awesome security. No workaround as far as I know.
The workflow that I've seen was someone I've known for under a month asking me to photograph her screen and send the photograph over Telegram. Surely that is more secure than letting her just screenshot her own device.
damn this hits hard, i always feel locked out when stuff gets taken away like that - you ever wonder if tech shifts like this actually give us more control or just pull it away?
Google abusing their power, as usual. I guess Google Drive doesnt have these restrictions, does it?
It's time the Europeans move together against these blatant antitrust violations.
[+] [-] AmazingTurtle|9 months ago|reply
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.
[+] [-] stavros|9 months ago|reply
[+] [-] jmathai|9 months ago|reply
I was a PM in Google Workspace for several years. It's a lot less nefarious than it probably seems. Decisions are optimized for revenue and other features (especially for enterprise customers) are going to be much higher priority.
Companies choosing to focus on enterprise revenue (which is basically all of them since like 2012) do so at the cost of end-user satisfaction.
[+] [-] throw7|9 months ago|reply
[+] [-] theodric|9 months ago|reply
[+] [-] mindslight|9 months ago|reply
[+] [-] nolist_policy|9 months ago|reply
[+] [-] moonshot5|9 months ago|reply
Disclaimer: I don't use nextcloud, and have not looked at their app specifically, this is just a surface level observation from my relatively informed perspective.
My take: SAF would work for this use case, as others have already mentioned.
Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to, and is delivered via the Play store in the same way nextcloud's app is.
As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.
[+] [-] noname120|9 months ago|reply
Excerpt from [1]:
> SAF is slow. Every SAF file IO operation takes like 20-30ms because it uses an IPC call. And sometimes you may want to check whether a lot of files exist on the disk and if they do not then create them (or something similar that requires a lot of file operations). It's so slow that even in google example they use hacks to make it faster.
Excerpt from [3]:
> Just to add a new sample for the performance of SAF vs standard File operations:
> […]
> 15 seconds with SAF, 6 milliseconds with native ls ! And there's only 128 files LOL
————————
[1] https://github.com/K1rakishou/Fuck-Storage-Access-Framework#...
[2] https://www.reddit.com/r/androiddev/comments/ga5u72/saf_is_s...
[3] https://issuetracker.google.com/issues/73044953#comment5
[4] https://magicbox.imejl.sk/forums/topic/storage-access-framew...
[5] https://issuetracker.google.com/issues/130261278#comment52
[+] [-] coded_monkey|9 months ago|reply
The lack of consideration for this point in this thread scares me. The amount of data that can be taken from a device through a permission like this is likely huge and it’s not just about “protecting users from themselves”. I wouldn’t feel safe enabling it for any app, and while syncing all data on the device sounds very useful, it’s a damned if they do, damned if they don’t scenario for Google.
[+] [-] tgsovlerkhgsel|9 months ago|reply
Let me guess, loan shark apps, or is there something even worse that I wasn't aware of?
(Essentially ransomware that people "voluntarily" install in order to get a predatory loan, often without knowing how it actually operates. If they fail to pay, not only is their phone locked, but the data from it is used to threaten/extort them, from threatening to send their nudes to their contacts to death threats to relatives identified from the data - https://www.welivesecurity.com/en/eset-research/beware-preda...)
[+] [-] dxuh|9 months ago|reply
I understand that great care should be taken when this permission is granted to new apps, but NextCloud is well known and on top of that it is a file management app. If anything, apps like that should have this permission.
If you plan to phase it out completely, then the alternatives have to be good enough, which judging from some of the child comments, they are not. I have never developed for Android (and likely never will, because of stuff like this), so I cannot judge properly.
It's also my understanding that the Google Drive App is just some UI over cloud storage. All the interesting bits like Backup are not handled through it and Google Drive gets preferential treatment for this. Additional permissions are required to emulate such functionality.
[+] [-] apitman|9 months ago|reply
Drive specifically may not, but the system as a whole, which is controlled by Google, certainly does[0].
[0]: https://support.google.com/googleone/answer/9149304?hl=en&co...
[+] [-] apitman|9 months ago|reply
[+] [-] codethief|9 months ago|reply
Now, there is probably little chance for this to get rolled back entirely. But maybe one could make it an option in the developer settings to allow ext4 filenames like before? Do you see any chance your team could be convinced of such a move? And where would be the appropriate place for me to raise this issue and/or contribute a patch?
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
[+] [-] thombles|9 months ago|reply
[+] [-] deng|9 months ago|reply
However, AFAIK, this problem would not apply to the NextCloud app.
[+] [-] fsh|9 months ago|reply
I was a bit surprised that the official client suddenly disappeared though.
[+] [-] jeroenhd|9 months ago|reply
SAF can be used. There are reasons why this wouldn't be a good fit for NextCloud (you can't share your entire internal storage, your download folder, or the root of an SD card, for instance), but I don't think NextCloud's statement makes sense.
[+] [-] deng|9 months ago|reply
https://developer.android.com/training/data-storage/shared/d...
This was discussed yesterday:
https://news.ycombinator.com/item?id=43970959
[+] [-] lozenge|9 months ago|reply
[+] [-] jasonlotito|9 months ago|reply
I just want to be sure that Google is playing by the same rules they they put out for NextCloud and other app developers.
[+] [-] patcon|9 months ago|reply
If they refuse to invest in the burden of due diligence required to allow others to operate exactly as they do, then they don't deserve to be managing the field.
It's costly to supervise? Ok, then charge companies a token fee if it's a burden to monitor. Locking other players out is not the appropriate response
[+] [-] squeedles|9 months ago|reply
[+] [-] inigoalonso|9 months ago|reply
[+] [-] jeroenhd|9 months ago|reply
The "sync just one folder" functionality exists in SAF without any high-risk permissions. Migration of existing profiles may be a pain (as the user would need to grant permission on the folder when switching to the new API).
Synchronisation of the entire virtual storage, the download folder, or any extra folders vendors like Samsung might've added to the blacklist, isn't possible with the new API, but it's also not possible with Google's own services. The DMA only requires Google not to be put in a special position; as long as they don't offer such a feature, they don't need to offer it to NextCloud.
[+] [-] darkwater|9 months ago|reply
Edit: oh we already have them in the other submission
[+] [-] throw347897823|9 months ago|reply
[deleted]
[+] [-] Hilift|9 months ago|reply
[+] [-] izacus|9 months ago|reply
Without this enforcement, malware games and apps like Facebook were just uploading your photos and scanning their EXIF locations under the guise of "needing all access".
And as we found out in existing topic, the better privacy preserving APIs exist, Nextcloud just doesn't want to use them.
[+] [-] scottbez1|9 months ago|reply
In 2014 Google split their drive app into multiple separate Android apps for docs, sheets, etc. Obviously getting users to install and migrate to new apps would be a burden, so they designed a 1-click install modal that Drive could use instead of the typical redirect-to-Play-Store flow. Neat!
Around that time the company I worked for (large competitor of Drive) was about to split out some core functionality into a standalone app and wanted to use a similar flow for similar reasons - Nope! Google locked that API behind an app signature verification (not even a permission) so only Google signed apps could use it. No possibility to request the permission or appeal - just a hard-coded monopoly.
There ARE legitimate reasons that things like this can be risky and abuse needs to be mitigated, but there's a line that Google regularly crosses between abuse mitigation and anti-competitive behavior.
[+] [-] izacus|9 months ago|reply
[+] [-] igtztorrero|9 months ago|reply
[+] [-] leetnewb|9 months ago|reply
[+] [-] unknown|9 months ago|reply
[deleted]
[+] [-] jsnell|9 months ago|reply
[+] [-] sierra1011|9 months ago|reply
[+] [-] aborsy|9 months ago|reply
Google can prompt the user for permissions; it’s up to the user beyond that.
[+] [-] dzikimarian|9 months ago|reply
* Nextcloud cannot access all files, despite many other file managers can - at least Fdroid version works.
* File manager cannot access /sdcard/android/data - inconvenient workaround via adb
* App is allowed to decide if I can (manually) take screenshot/ocr the screen - usually it's banking app, that wants me to remember some long number - then I write it on closest piece of paper - awesome security. No workaround as far as I know.
If I wanted such treatment I would buy ios :-|
[+] [-] dotancohen|9 months ago|reply
[+] [-] tuga2099|9 months ago|reply
[+] [-] BLenkomo|9 months ago|reply
But yes this is shitty regarding google.
[+] [-] yard2010|9 months ago|reply
[+] [-] throwaway984393|9 months ago|reply
[deleted]
[+] [-] gitroom|9 months ago|reply
[+] [-] tacker2000|9 months ago|reply
[+] [-] happyopossum|9 months ago|reply
It does