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.
stavros · 2h ago
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.
TheNewsIsHere · 2h ago
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.
nolist_policy · 2h ago
> 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.
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?
hkt · 1h ago
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.
jmathai · 1h ago
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.
cess11 · 12m ago
If it looked as nefarious as it is on the inside they would have roughly zero employees.
theodric · 5h ago
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.
HPsquared · 4h ago
The question to ask is: do Google apps have an advantage here over others?
yndoendo · 32m ago
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?
em-bee · 4h ago
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.
monegator · 2h ago
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
donatzsky · 3h ago
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.
brigandish · 4h ago
According to the article, and according to many of the comments here, yes they do.
observationist · 3h ago
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.
nolist_policy · 3h ago
Hmm, AFAIK drive.readonly is a Google Drive thing. TFA is talking about local file access, not Google Drive access.
mbrumlow · 3h ago
Hello, it’s the same overall issue just on different platforms.
thombles · 6h ago
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.
I was a bit surprised that the official client suddenly disappeared though.
JeremyNT · 2h ago
> 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.
deng · 5h ago
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.
deng · 6h ago
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.
izacus · 4h ago
You can get simple file descriptors for SAF, but you do need to ask for them via Java APIs.
treyd · 5h ago
> 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?
deng · 5h ago
To my knowledge you cannot access SAF through binder, for sure not officially.
charcircuit · 48m ago
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.
moonshot5 · 1h ago
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.
coded_monkey · 1h ago
> 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.
zb3 · 54m ago
> 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?
patcon · 2h ago
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
jeroenhd · 7h ago
> 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.
jeroenhd · 7h ago
Which they can do, using SAF, without the "access to everything everywhere" permission that they want.
sirdvd · 5h ago
> 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.
jasonlotito · 3h ago
Curious also, why can't users have access to everything everywhere for their own files?
nolist_policy · 1h ago
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.
criddell · 1h ago
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.
hkt · 1h ago
Features that are useful to competitors who would like to provide an alternative to a Google product also don't get prioritised, it seems.
jasonlotito · 3h ago
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.
zb3 · 49m ago
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.
scottbez1 · 1h ago
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.
inigoalonso · 9h ago
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.
jeroenhd · 6h ago
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.
darkwater · 8h ago
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
geff82 · 7h ago
Just use e/os ! ;)
subscribed · 6h ago
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.
em-bee · 5h ago
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.
raverbashing · 8h ago
Yeah it's the "less space than a Nomad" people
I know, I used to be one of those
Hilift · 7h ago
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.
izacus · 3h ago
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.
jasonjayr · 3h ago
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.
freshchilled · 2h ago
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.
DrillShopper · 3h ago
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.
nolist_policy · 3h ago
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.
jeppester · 2h ago
There should be a DMCA-like law that would allow to instantly prohibit actions like these until they have been properly scrutinized.
Arguably the originator's blog post has some individual merit beyond an article from a tech news aggregator.
izacus · 3h ago
The merit seems to be repeating the screech cycle from HNers not understanding the context?
No comments yet
BLenkomo · 7h ago
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.
igtztorrero · 5h ago
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!
yard2010 · 8h ago
Goddammit Pichai. We had something mediocre, why enshitify it to the oblivion?
tacker2000 · 5h ago
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.
happyopossum · 3h ago
> I guess Google Drive doesnt have these restrictions, does it?
It does
gitroom · 5h ago
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?
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.
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.
> 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.
SyncThing ran into similar problems recently: https://news.ycombinator.com/item?id=41895718
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?
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.
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 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
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.
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
The official maintainer of syncthing-fork indeed stopped publishing to Google Play, but it seems some other guy is doing that now for him.
However, AFAIK, this problem would not apply to the NextCloud app.
Do you need it in these languages or could you use anything that can make binder calls?
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.
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?
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
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.
https://developer.android.com/training/data-storage/shared/d...
This was discussed yesterday:
https://news.ycombinator.com/item?id=43970959
"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.
Features that are expensive but only useful to a small portion of the userbase often don't get prioritized.
I just want to be sure that Google is playing by the same rules they they put out for NextCloud and other app developers.
Locked down API means Google can innovate (because they can change the API), but you can't.
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.
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.
Edit: oh we already have them in the other submission
Doesn't sound like a serious project.
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.
I know, I used to be one of those
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.
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.
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.
No comments yet
But yes this is shitty regarding google.
It does