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.
SAF doesn't work with native code, which really sucks if you're trying to make a cross-platform app.
Cloud applications can do nil, because the api for the background transfers is only working for iCloud, Nextcloud and other apps in the background get a couple of kb/s effectively pushing you to pay apple. Great Dark pattern from Apple that has been going on for years.
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
As a user, you're to be no longer trusted with such a thing as full and unconditional access to the device you bought. Browsers are headed the same way. And a large crowd here on HN is okay with this, because "security."
This has been true for a while, but the OP isn't even about full and unconditional access (like root access, which is all but impossible for normal use), it's literally just "sync my files".
Yeah, exactly, it's a really worrying trend and one that I really don't want to see continue.
I was under the impression browsers have been implementing more hardware access, not less, if slowly. What are you referring to?
Manifest V3? No ad blockers in Chrome?
I'm embarrassed I didn't immediately think of that, thanks.
>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.
This is not about tinkering. My phone is a toolbox, the apps are the tools and Google keeps breaking them in order to make their tools seem better. I need to get real work done using my phone and being able to sync files with a server is a critical part of that. I can't use Google Drive instead for many reasons, but that's besides the point, because this is illegal anticompetitive behaviour.
As far as I know, Apple also doesn't let you sync folders like this, so that's not a solution. And regardless, Apple cripples many other tools that I rely on.
I strongly disagree. The difference is "I control my phone vs. my phone is controlled by the vendor".
Or "My phone is a computing device vs. my phone is vendor-specified use-case tool".
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.
Perhaps the ecosystem has changed now, but when I made the switch in 2017, having an Android phone felt like a hobby project. I was regularly dealing with flagship phones stuttering and lagging, apps crashing, media formats not displaying properly, etc.
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.
Why isn't it? I think Android is doing a good enough job doing both, and Apple could have simply allowed unlocking the bootloader. Nothing else would need to change.
Isn't the process of vetting a developer a subset of the process for finding a good app for doing a certain task?
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.
Isn't the submission about this being a monopolized market, because options are being removed (NextCloud - a popular option).
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".
I believe it. Most people would be better served paying a local company $20/mo to offer the equivalent of google services using open protocols. Unfortunately such a marketplace doesn't exist, but I believe it will eventually.
They removed the permission for nextcloud, that seems they actually spend resources on removing the permissions. The minimal "spend no resources" approach would have left nextcloud with 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.
The post is alluding to the fact that nextcloud is already doing this (the point to advanced users can install from f-droid)
We need something like F-droid but with proprietary apps to get popular.
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?
> One of the reasons I am looking forward for a company that provides a quality Linux base phone.
What exactly is that going to change with respect to the camera app? I'm as annoyed by Google Camera's behavior as you are but already today we can download FOSS camera apps for Android that will open the gallery app of our choice just fine. It's just that those apps are not quite as good as Google's app. Exchanging the underlying Android layer for regular Linux is not going to change anything about that.
Man, Linux phones are a mess, you do well to wait. I'm eyeing Sailfish but even then I'm hesitant, anything else is a big no no (from experience).
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
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".
Yeah google issues are great.
Reminds me of some bug reports I was looking at for Chromium regarding SVG rendering the other day.
Some of them are almost a decade old and require constant bumps to keep them alive, or filling new issues. Somehow their bot system considers anything more than a year old "probably patched". Their messages read much the same way as that.
Good catch - that’s horrendous and feels like absolute fobbing off with “type a bunch of cliches”
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.
There are no good workarounds unfortunately and it's definitely not solved on later Android versions. I agree though that the reason that Nextcloud gives is factually incorrect (they say that SAF is for providing files rather than accessing them, which is plain wrong).
From what I understand, you can resolve most issues by making ContentResolver queries yourself once you have URI permissions for a folder, including data like filename, mime type and file size in the query projection. This reduces an NxM number of queries to N, where N is the number of nested directories in the tree and M is the number of files in the directory.
Obviously this should be solved with a better API at the SAF layer.
You're linking articles that are 3-6 years old and the performance has significantly improved since then.
Not true. I had first-hand experience a few months ago and the performance is still abysmal.
> 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...)
Pretty much every game and every social media app asked for full storage access under the guise of "downloading game files" or "allowing our photo picker to work".
Then they got free access to all your photos and their location data and all your documents and downloads. Yes, including those banking statements downloaded as PDFs. Forever. In background. Whenever.
That's the access Nextcloud demands instead of using the API where YOU choose what it can read.
Hell, you don't need to go that far.
Some apps suspiciously send data they have no business in about your phone, like Outlook. It's crazy.
Wow, that sounds dystopic as hell...
> 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.
So scary that I don't know how billions of people in the world manage to have the right to use whatever software they want to access "all" the files in the file system of their computers (PC/mac) and that the civilisations have still not yet collapsed...
Then give me a big fat warning then let me choose.
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 next API Nextcloud is asked to use it literally that - it asks you, as the user, what files you want Nextcloud to read.
But why? Just for the odd app that can't be bothered to use the new API?
Even if you trust the app, if there is a vulnerability in there, the Android sandbox provides an additional line of defense. Most apps don't have defenses of their own, the only apps that self-sandbox are web browsers.
> 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.
But the new API allows exactly this, the user can just give the app an empty directory. And Google even pushes apps to use it.
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.
> 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.
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?
[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952
> Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to
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...
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 it's only one file at a time, right? ie you can't give your native code access to a directory.
> 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.
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.
The play store version isn't updated anymore. You should switch to F-Droid.
> 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:
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.
That's just the Drive app. The system overall certainly has more capabilities than are made available to developers[0].
[0]: https://support.google.com/googleone/answer/9149304?hl=en&co...
Yes, but Nextcloud is adamant that they need MANAGE_EXTERNAL_STORAGE permission, not access to the device backup system API.
This is not the same functionality that Nextcloud provides though. This is one time upload of manually selected files, not ongoing passive sync of an entire directory tree.
Ongoing sync is still possible through ACTION_OPEN_DOCUMENT_TREE [0], and using ContentResolver.takePersistableUriPermission [1] to maintain long-lived access to that directory. Enumerating files is slow but that is not a major concern when the use-case is a background sync, and you can drop down to ContentResolver APIs to reduce the number of IPC calls when enumerating.
[0]: https://developer.android.com/training/data-storage/shared/d...
[1]: https://developer.android.com/reference/android/content/Cont...
> Enumerating files is slow but that is not a major concern when the use-case is a background sync
Slow means it's probably burning a lot of CPU, and that is a problem for background tasks, especially on mobile.
No, the call is going through ContentProvider, which happens over Binder IPC, which entails context switching and other I/O overhead. Compared to local file operations (java.io and friends) this is massive; compared to anything else your device does, it's not a big deal at all, and it's not CPU-bound.
The same picker has the functionality of allowing access to a full directory.
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.
It's a lie in plain sight, because for most Google apps, including this one, a lot of background processing is not done by the app itself but by the Google play services app that is all powerful.
Right but it doesn't do the same thing Nextcloud does. If it did do you think Google would say to the drive team "sorry you can't do that"? Of course not. They'd invent a new permission or just whitelist Google apps (they've done it before).
No, they would just use the SAF API.
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.
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.
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
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.
You're attacking a strawman; anti-competitive behavior doesn't require that you do exactly the thing you prohibit others from doing. It can be anti-competitive to use your market control to restrict competition in ways that break competitors product but do not impact your own product.
In any case, you've also ignored most of my comment which WAS an example of Google going that extra step of directly blocking APIs that they leverage themselves.
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.
> What apps in Google's ecosystem have the "all files" permission?
The system itself[0] has capabililities that aren't provided to app developers. iOS is similar. Contrast this with Windows and GNU/Linux where AFAIK you can do pretty much everything the OS can given the proper permissions. Not sure about macOS.
[0]: https://support.google.com/googleone/answer/9149304?hl=en&co...
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
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.
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.
SAF doesn't work with native code
Native code talk to Android APIs as well.
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.
Because you'd scream your head off like other HNers when a news article "100 million users private photos uploaded to Facebook and Genshin Impact!!!!" appears and would demand Google policing.
You can keep all your functionality, Nextcloud just needs to migrate to an API that gives YOU AS A USER control over what it can read instead of demanding blanket permission for everything.
I promise you I would not. I do not want my technology baby-sat by a third party, I want my technology to do exactly what I want.
I also promise I wouldn't run a game or anything that demanded full access to everything that made no sense to have that permission, because what the heck? Outlook wanted "Device administrator" permission on my personal phone when I wanted to connect my office email to it. I politely declined, and stopped using it. (I mean, I understand WHY Outlook needs that, for secure wipe of data, but that's a pretty wide permission for that one reason)
I cringe as I watch one of my kids authorize elevated permissions when they launch Genshin. (For the anti-cheat) And I promise them I will never run it on my machines :-/
But rather than get lost in the details, what I REALLY want, is a piece of software that will backup and restore the entire contents of the phone to a server of my choice, preferably self-hosted. Right now, this "full system access" option gets the job done, but it's a thermonuclear footgun for the unsuspecting.
How could we convince google to create a new a "Full backup of the device" permission? Because then Google could simply deny the permission labeled "full backup" to the latest hot new gacha game, while allowing legit backup apps the power they need?
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.
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 :-|
> 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.
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.
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?
Can Google drive app for any android upload all file types?
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!
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.
Goddammit Pichai. We had something mediocre, why enshitify it to the oblivion?
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.
> I guess Google Drive doesnt have these restrictions, does it?
It does
well, then i stand corrected.
then why should nextcloud have this permission if even google drive doesn't have it?
Because the Android system, which is controlled by Google, does have these permissions[0]. Google is able to offer automatic backup functionality that Nextcloud can't compete with.
[0]: https://support.google.com/googleone/answer/9149304?hl=en&co...
There should be a DMCA-like law that would allow to instantly prohibit actions like these until they have been properly scrutinized.