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.
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.
> 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.
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.
>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.
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.
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.
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.
Regrettably competition law doesn't really work like this: in the US it doesn't kick in until consumer prices are affected, and in the EU it is a combination of consumer prices plus market fairness. Market fairness could be for technical stuff like this but to the best of my knowledge it hasn't done anything so fine grained. The only example that comes to mind is when Microsoft were forced to show alternative browsers in Windows. No idea if they still have to do that or not, but it is a much higher level thing that is much more readily understood.
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.
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.
they have the advantage that they can shape the API to their needs. yes, you can argue that google apps have the same limitations as other apps. but google defines the limitations. just because google doesn't need a feature, it doesn't mean that no one else needs or should have that feature. so google is able to define features that fit their business model, and they prevent anyone else from offering a different feature set. they own the platform and compete in it. that in itself is an advantage. to not have an advantage either google must not compete with apps on the platform and or they should relinquish their ownership of the platform.
Or simply put the implementation behind a permission that they will give to themselves and practically never give to you.
I second the fighting against a copy-paste bot. It took a couple of weeks of multiple daily requests before we got to exchange emails with some sort of human being, which was almost as useless until we gave in and abandoned
From an Pixel 5a perspective. The camera application provided by Google will only open Google's gallery application and will not open the one the end user sets as system default. User must exit the camera application and manually open the gallery application they really want to use.
One of the reasons I am looking forward for a company that provides a quality Linux base phone. That is the only way to get the system configuration and application select the end user really wants. Google and Apple are for profit prison Wardens with their mobile OSes.
PS. Has anyone ever studied the economic, resource, and power waste of system bloat-ware?
I'd be surprised if they have to go through the same review process as everyone else. And even if they do, the reviewers are likely to give them a pass because it's Google.
And unicorns shit rainbows, and we're all going to win the lottery tomorrow.
Nothing google does is in good faith. They're a corporation - a bundle of regulations, laws, rules, and incentives executed on a mixed substrate of human brains and digital computers, beyond the control and sensibilities that govern individual rationality, seeking to maximize profit. If it's not illegal, they'll do it, and if it is illegal, they'll still do it if the penalty is less than the profit.
We have to stop pretending corporations are people. We have to stop pretending like CEOs can affect what these companies do - the only way to restrain them is laws with teeth. If you want CEOs to behave, enforce laws that come with jail time and lost fortunes. Otherwise, this is what we live with.
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
This may be true, may have workarounds, and may be solved on later Android versions, but it also is not why Nextcloud says they are avoiding the framework. And Google Drive provides the same functionality using SAF, so I'm not sure it's a problem for this use case.
Wow the resolution to your link [3] is infuriating:
> We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue (...)
It's all possible excuses all at once: "Thank you for your issue, we are working on it. Also we have no intention to work on it and we are closing it, the problem probably doesn't exist anymore anyways, and if you think it does make sure to open a new issue for us to treat it with the same amount of respect".
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.
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.
Then don't enable it, no need to take away my ability to do so. Granular permissions are good (especially when the app can't reliably know they were refused), providing I have the ultimate control.
> it’s a damned if they do, damned if they don’t scenario for Google.
Did they consider my scenario above - where the app doesn't know it was not granted a permission?
> especially when the app can't reliably know they were refused
That's the problem. Android didn't do this even though it was obviously what is needed. Android apps can easily tell what permissions they have.
I think Google prioritised UX over power and security here. They were presumably scared about people accidentally clicking the "Silently deny" button and then getting confused when the app didn't work. Big missed opportunity.
Google simply needs to add "I'm an adult" functionality to their phones. I know the author of this app and trust them, I know the functionality I want and I accept the risk because I'm a grown adult and can make my own choices.
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.
You need it in the same sense you need to load the system's vulkan driver. System libraries don't have more permissions, but it's going to be extra work to reimplement and your code may break on different versions or devices.
> I was a bit surprised that the official client suddenly disappeared though.
Here is when syncthing dropped the official Android client [0] so you can read through their rationale and the HN response at the time.
I am not an Android developer but I do follow this space; I had the impression at the time that it really was mostly about the dev cycles that would have been required and nobody willing to do the work.
I do wonder why they don't just make the fork an official Syncthing project, it seems like the obvious solution would be to officially bless it. I can only guess the maintainer likes their independence.
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
* 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.
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.
> 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.
"they", in my case it's me. With on my own Nextcloud server, on my own LAN.
It's me that want "access to everything everywhere".
Difficult for me to think that is not about gate keeping from Google.
Users can access almost everything everywhere with file manager apps. On the Play Store, file manager apps are one of the exceptions that are allowed to access all files.
Usually the answer is that it creates more problems for more people than it solves. The work involved to add options to allow full access is substantial and could increase the attack surface.
Features that are expensive but only useful to a small portion of the userbase often don't get prioritized.
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.
Open the Drive app, tap the "New" button, and select "Upload". You get a file picker UI. This UI is provided by the Storage Access Framework that Nextcloud says they cannot use.
In the Play Store, find the Drive app, select "About this app", scroll down to "App permissions", and tap "See more". It does not have the "manage external storage" permission listed, which is the one Nextcloud says they need.
Google is smart enough to not make things that obvious, but let's not get fooled.. the point is that if API changes would negatively impact Google products financially, they'd not go through. But if they impact a competitor, it's not an issue.
Locked down API means Google can innovate (because they can change the API), but you can't.
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
Maybe something else instead. e/os famously leaves the bootloader gaping open after the installation (looks like relocking is only supported on Fairphones), is very late to release anything (their most recent ROM is still based on AOSP 14!), inc.securty updates.
i'd rather have secure, stable and slow. i don't know about locking the bootloader (do you have a reference to that? i'd like to read up on it). but i don't care that their rom is always the most recent one.
what matters is that e/OS is the only rom i am aware of that combines usability with security. graphene OS doesn't count because it is only available on pixel phones and therefore very limited in applicability. others i don't know.
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.
But, I want that. With all the responsibilities that come with that.
Why can't I grant an app that permission? If Google discovers that an app with that permission is abusing what they are doing with that permission, then revoke their developer account! Delete the app from existing phones and inform the users that the developers could not be trusted! App store death penalty!
It's difficult to understand why there is any other reason other than maintaining their privleged position on the device to deny users this ability. Put a persistent notification in the status tray: "These apps have full access:", etc.
At the moment, you can do that, but not with an app hosted on the Play Store. I use a git client to sync my notes between my computers and my phone. But I had to get the app from FDroid, because it required the read all files permission to track changes.
Maybe there's a middle ground between "apps can't do this" and "uploading all your data to the developers without a permissions dialog or a popup"? Could we maybe design a system where this permission requires opt in consent like every other feature on Android? Third party apps access to the feature is the issue here.
The old API works this way. Random games requested the "access all files" permission. This was bad and the rest is history.
The better middle ground is the new (9 years old) SAF API. The SAF API simply presents a directory picker to the user. The user can give the app access to any directories he likes.
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!
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.
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?
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.
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.
> 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.
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
>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.
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.
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.
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.
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.
I don't doubt what you're saying, but whatever the reason, the end result is the same: Google Apps have a "first-party apps privileged access".
If it looked as nefarious as it is on the inside they would have roughly zero employees.
This sounds exactly what anti-trust laws are for.
It does not look like the laws are working!
Enforcement is erratic, fines are small, and the incentives to do things like this are strong.
They have had this problem for five months. How many customers have they lost in this time?
Regrettably competition law doesn't really work like this: in the US it doesn't kick in until consumer prices are affected, and in the EU it is a combination of consumer prices plus market fairness. Market fairness could be for technical stuff like this but to the best of my knowledge it hasn't done anything so fine grained. The only example that comes to mind is when Microsoft were forced to show alternative browsers in Windows. No idea if they still have to do that or not, but it is a much higher level thing that is much more readily understood.
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.
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.
The question to ask is: do Google apps have an advantage here over others?
they have the advantage that they can shape the API to their needs. yes, you can argue that google apps have the same limitations as other apps. but google defines the limitations. just because google doesn't need a feature, it doesn't mean that no one else needs or should have that feature. so google is able to define features that fit their business model, and they prevent anyone else from offering a different feature set. they own the platform and compete in it. that in itself is an advantage. to not have an advantage either google must not compete with apps on the platform and or they should relinquish their ownership of the platform.
Or simply put the implementation behind a permission that they will give to themselves and practically never give to you.
I second the fighting against a copy-paste bot. It took a couple of weeks of multiple daily requests before we got to exchange emails with some sort of human being, which was almost as useless until we gave in and abandoned
I will go with yes for $500.
From an Pixel 5a perspective. The camera application provided by Google will only open Google's gallery application and will not open the one the end user sets as system default. User must exit the camera application and manually open the gallery application they really want to use.
One of the reasons I am looking forward for a company that provides a quality Linux base phone. That is the only way to get the system configuration and application select the end user really wants. Google and Apple are for profit prison Wardens with their mobile OSes.
PS. Has anyone ever studied the economic, resource, and power waste of system bloat-ware?
I'd be surprised if they have to go through the same review process as everyone else. And even if they do, the reviewers are likely to give them a pass because it's Google.
According to the article, and according to many of the comments here, yes they do.
And unicorns shit rainbows, and we're all going to win the lottery tomorrow.
Nothing google does is in good faith. They're a corporation - a bundle of regulations, laws, rules, and incentives executed on a mixed substrate of human brains and digital computers, beyond the control and sensibilities that govern individual rationality, seeking to maximize profit. If it's not illegal, they'll do it, and if it is illegal, they'll still do it if the penalty is less than the profit.
We have to stop pretending corporations are people. We have to stop pretending like CEOs can affect what these companies do - the only way to restrain them is laws with teeth. If you want CEOs to behave, enforce laws that come with jail time and lost fortunes. Otherwise, this is what we live with.
Hmm, AFAIK drive.readonly is a Google Drive thing. TFA is talking about local file access, not Google Drive access.
Hello, it’s the same overall issue just on different platforms.
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
————————
[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
This may be true, may have workarounds, and may be solved on later Android versions, but it also is not why Nextcloud says they are avoiding the framework. And Google Drive provides the same functionality using SAF, so I'm not sure it's a problem for this use case.
Wow the resolution to your link [3] is infuriating:
> We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue (...)
It's all possible excuses all at once: "Thank you for your issue, we are working on it. Also we have no intention to work on it and we are closing it, the problem probably doesn't exist anymore anyways, and if you think it does make sure to open a new issue for us to treat it with the same amount of respect".
> often in horrific ways
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.
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.
> I wouldn’t feel safe enabling it for any app
Then don't enable it, no need to take away my ability to do so. Granular permissions are good (especially when the app can't reliably know they were refused), providing I have the ultimate control.
> it’s a damned if they do, damned if they don’t scenario for Google.
Did they consider my scenario above - where the app doesn't know it was not granted a permission?
> especially when the app can't reliably know they were refused
That's the problem. Android didn't do this even though it was obviously what is needed. Android apps can easily tell what permissions they have.
I think Google prioritised UX over power and security here. They were presumably scared about people accidentally clicking the "Silently deny" button and then getting confused when the app didn't work. Big missed opportunity.
Google simply needs to add "I'm an adult" functionality to their phones. I know the author of this app and trust them, I know the functionality I want and I accept the risk because I'm a grown adult and can make my own choices.
This is also why the official SyncThing Android app stopped being distributed. There is a fork but it's not available on the Play Store.
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.
You can get simple file descriptors for SAF, but you do need to ask for them via Java APIs.
> and you need a Java/Kotlin bridge to convert these to file descriptors.
Do you need it in these languages or could you use anything that can make binder calls?
To my knowledge you cannot access SAF through binder, for sure not officially.
You need it in the same sense you need to load the system's vulkan driver. System libraries don't have more permissions, but it's going to be extra work to reimplement and your code may break on different versions or devices.
The fork is in the play store and works fine for me on Android 15: https://play.google.com/store/apps/details?id=com.github.cat...
I was a bit surprised that the official client suddenly disappeared though.
> I was a bit surprised that the official client suddenly disappeared though.
Here is when syncthing dropped the official Android client [0] so you can read through their rationale and the HN response at the time.
I am not an Android developer but I do follow this space; I had the impression at the time that it really was mostly about the dev cycles that would have been required and nobody willing to do the work.
I do wonder why they don't just make the fork an official Syncthing project, it seems like the obvious solution would be to officially bless it. I can only guess the maintainer likes their independence.
[0] https://news.ycombinator.com/item?id=41895718
Well they also probably don’t want the reputation hit if the fork ends up doing some kind of rug pull.
From a very cursory look it seems like syncthing-fork uses ContentResolver and other stuff from SAF, so it seems they made it work.
The official maintainer of syncthing-fork indeed stopped publishing to Google Play, but it seems some other guy is doing that now for him.
Monopoly behaviour.
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
Honestly it's extremely annoying my device locks me out from my data - that would be third entry to my list:
* 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 :-|
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.
> 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.
Entirely correct, for instance see
https://developer.android.com/training/data-storage/shared/d...
This was discussed yesterday:
https://news.ycombinator.com/item?id=43970959
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.
Which they can do, using SAF, without the "access to everything everywhere" permission that they want.
> permission that they want
"they", in my case it's me. With on my own Nextcloud server, on my own LAN. It's me that want "access to everything everywhere". Difficult for me to think that is not about gate keeping from Google.
Curious also, why can't users have access to everything everywhere for their own files?
Users can access almost everything everywhere with file manager apps. On the Play Store, file manager apps are one of the exceptions that are allowed to access all files.
Usually the answer is that it creates more problems for more people than it solves. The work involved to add options to allow full access is substantial and could increase the attack surface.
Features that are expensive but only useful to a small portion of the userbase often don't get prioritized.
Features that are useful to competitors who would like to provide an alternative to a Google product also don't get prioritised, it seems.
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.
Open the Drive app, tap the "New" button, and select "Upload". You get a file picker UI. This UI is provided by the Storage Access Framework that Nextcloud says they cannot use.
They definitely aren't playing by the same rules. If Google Drive needs an API or permission it gets it no questions asked.
In the Play Store, find the Drive app, select "About this app", scroll down to "App permissions", and tap "See more". It does not have the "manage external storage" permission listed, which is the one Nextcloud says they need.
Google is smart enough to not make things that obvious, but let's not get fooled.. the point is that if API changes would negatively impact Google products financially, they'd not go through. But if they impact a competitor, it's not an issue.
Locked down API means Google can innovate (because they can change the API), but you can't.
I rely on nextcloud AIO and need to sync my files.
Google can prompt the user for permissions; it’s up to the user beyond that.
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
Just use e/os ! ;)
Maybe something else instead. e/os famously leaves the bootloader gaping open after the installation (looks like relocking is only supported on Fairphones), is very late to release anything (their most recent ROM is still based on AOSP 14!), inc.securty updates.
Doesn't sound like a serious project.
what else?
i'd rather have secure, stable and slow. i don't know about locking the bootloader (do you have a reference to that? i'd like to read up on it). but i don't care that their rom is always the most recent one.
what matters is that e/OS is the only rom i am aware of that combines usability with security. graphene OS doesn't count because it is only available on pixel phones and therefore very limited in applicability. others i don't know.
Yeah it's the "less space than a Nomad" people
I know, I used to be one of those
[flagged]
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.
But, I want that. With all the responsibilities that come with that.
Why can't I grant an app that permission? If Google discovers that an app with that permission is abusing what they are doing with that permission, then revoke their developer account! Delete the app from existing phones and inform the users that the developers could not be trusted! App store death penalty!
It's difficult to understand why there is any other reason other than maintaining their privleged position on the device to deny users this ability. Put a persistent notification in the status tray: "These apps have full access:", etc.
At the moment, you can do that, but not with an app hosted on the Play Store. I use a git client to sync my notes between my computers and my phone. But I had to get the app from FDroid, because it required the read all files permission to track changes.
Maybe there's a middle ground between "apps can't do this" and "uploading all your data to the developers without a permissions dialog or a popup"? Could we maybe design a system where this permission requires opt in consent like every other feature on Android? Third party apps access to the feature is the issue here.
The old API works this way. Random games requested the "access all files" permission. This was bad and the rest is history.
The better middle ground is the new (9 years old) SAF API. The SAF API simply presents a directory picker to the user. The user can give the app access to any directories he likes.
Dupe (250 points, 170 comments): https://news.ycombinator.com/item?id=43970959
Arguably the originator's blog post has some individual merit beyond an article from a tech news aggregator.
The merit seems to be repeating the screech cycle from HNers not understanding the context?
There should be a DMCA-like law that would allow to instantly prohibit actions like these until they have been properly scrutinized.
I would like to have both options: Full file access and controlled access. I guess not eveyrone wants nextcloud full file sync.
But yes this is shitty regarding google.
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!
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.
> I guess Google Drive doesnt have these restrictions, does it?
It does
Goddammit Pichai. We had something mediocre, why enshitify it to the oblivion?
[dead]
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?