[HN Gopher] The recently lost file upload feature in the Nextclo...
___________________________________________________________________
The recently lost file upload feature in the Nextcloud app for
Android
Author : morsch
Score : 355 points
Date : 2025-05-14 05:38 UTC (17 hours ago)
(HTM) web link (nextcloud.com)
(TXT) w3m dump (nextcloud.com)
| jsnell wrote:
| Dupe (250 points, 170 comments):
| https://news.ycombinator.com/item?id=43970959
| sierra1011 wrote:
| Arguably the originator's blog post has some individual merit
| beyond an article from a tech news aggregator.
| izacus wrote:
| The merit seems to be repeating the screech cycle from HNers
| not understanding the context?
| inigoalonso wrote:
| 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.
| darkwater wrote:
| 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
| raverbashing wrote:
| Yeah it's the "less space than a Nomad" people
|
| I know, I used to be one of those
| geff82 wrote:
| Just use e/os ! ;)
| subscribed wrote:
| 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 wrote:
| 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.
| Hilift wrote:
| 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.
| jeroenhd wrote:
| 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.
| izacus wrote:
| 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.
| DrillShopper wrote:
| 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 wrote:
| 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.
| apitman wrote:
| SAF doesn't work with native code
| jasonjayr wrote:
| 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 wrote:
| 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.
| izacus wrote:
| 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.
| yard2010 wrote:
| Goddammit Pichai. We had something mediocre, why enshitify it to
| the oblivion?
| BLenkomo wrote:
| 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.
| jeroenhd wrote:
| > 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.
| lozenge wrote:
| 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 wrote:
| Which they can do, using SAF, without the "access to
| everything everywhere" permission that they want.
| sirdvd wrote:
| > 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 wrote:
| Curious also, why can't users have access to everything
| everywhere for their own files?
| nolist_policy wrote:
| 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 wrote:
| 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 wrote:
| Features that are useful to competitors who would like to
| provide an alternative to a Google product also don't get
| prioritised, it seems.
| deng wrote:
| 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
| jasonlotito wrote:
| 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 wrote:
| 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.
| IshKebab wrote:
| They definitely aren't playing by the same rules. If Google
| Drive needs an API or permission it gets it no questions
| asked.
| tadfisher wrote:
| 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.
| IshKebab wrote:
| 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).
| nolist_policy wrote:
| No, they would just use the SAF API.
| tadfisher wrote:
| 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.
| Macha wrote:
| 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.
| tadfisher wrote:
| 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/cont
| ent/Cont...
| apitman wrote:
| > 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.
| izacus wrote:
| The same picker has the functionality of allowing access
| to a full directory.
| AmazingTurtle wrote:
| 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.
| theodric wrote:
| 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 wrote:
| The question to ask is: do Google apps have an advantage here
| over others?
| em-bee wrote:
| 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 wrote:
| 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
| brigandish wrote:
| According to the article, and according to many of the
| comments here, yes they do.
| observationist wrote:
| 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.
| donatzsky wrote:
| 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.
| yndoendo wrote:
| 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?
| spookie wrote:
| 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).
| throw7 wrote:
| This sounds exactly what anti-trust laws are for.
| graemep wrote:
| 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?
| hkt wrote:
| 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.
| nolist_policy wrote:
| Hmm, AFAIK drive.readonly is a Google Drive thing. TFA is
| talking about local file access, not Google Drive access.
| mbrumlow wrote:
| Hello, it's the same overall issue just on different
| platforms.
| stavros wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| apitman wrote:
| SAF doesn't work with native code, which really sucks if
| you're trying to make a cross-platform app.
| johnmaguire wrote:
| 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
| antman wrote:
| 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.
| devmor wrote:
| >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.
| stavros wrote:
| 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.
| foobiekr wrote:
| 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.
| stavros wrote:
| 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.
| SahAssar wrote:
| 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".
| apitman wrote:
| Isn't the process of vetting a developer a subset of the
| process for finding a good app for doing a certain task?
| immibis wrote:
| 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.
| pmdr wrote:
| 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."
| stavros wrote:
| Yeah, exactly, it's a really worrying trend and one that I
| really don't want to see continue.
| apitman wrote:
| I was under the impression browsers have been implementing
| more hardware access, not less, if slowly. What are you
| referring to?
| DecentShoes wrote:
| Manifest V3? No ad blockers in Chrome?
| apitman wrote:
| I'm embarrassed I didn't immediately think of that,
| thanks.
| jmathai wrote:
| 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 wrote:
| If it looked as nefarious as it is on the inside they would
| have roughly zero employees.
| arp242 wrote:
| 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".
| cycomanic wrote:
| 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.
| apitman wrote:
| 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.
| mindslight wrote:
| 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.
| cycomanic wrote:
| The post is alluding to the fact that nextcloud is already
| doing this (the point to advanced users can install from
| f-droid)
| apitman wrote:
| We need something like F-droid but with proprietary apps to
| get popular.
| thombles wrote:
| 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.
| deng wrote:
| 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.
| treyd wrote:
| > 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 wrote:
| To my knowledge you cannot access SAF through binder, for
| sure not officially.
| charcircuit wrote:
| 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.
| izacus wrote:
| You can get simple file descriptors for SAF, but you do need
| to ask for them via Java APIs.
| apitman wrote:
| And it's only one file at a time, right? ie you can't give
| your native code access to a directory.
| fsh wrote:
| 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.
| deng wrote:
| 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.
| JeremyNT wrote:
| > 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
| kortilla wrote:
| Well they also probably don't want the reputation hit if
| the fork ends up doing some kind of rug pull.
| gitroom wrote:
| 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?
| igtztorrero wrote:
| 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!
| tacker2000 wrote:
| 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 wrote:
| > I guess Google Drive doesnt have these restrictions, does it?
|
| It does
| tacker2000 wrote:
| well, then i stand corrected.
|
| then why should nextcloud have this permission if even google
| drive doesn't have it?
| patcon wrote:
| 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
| jeppester wrote:
| There should be a DMCA-like law that would allow to instantly
| prohibit actions like these until they have been properly
| scrutinized.
| moonshot5 wrote:
| 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 wrote:
| > 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 wrote:
| > 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?
| IshKebab wrote:
| > 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.
| nolist_policy wrote:
| 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.
| mvdtnz wrote:
| 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.
| nolist_policy wrote:
| 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.
| izacus wrote:
| The next API Nextcloud is asked to use it literally that -
| it asks you, as the user, what files you want Nextcloud to
| read.
| apitman wrote:
| Then give me a big fat warning then let me choose.
| tgsovlerkhgsel wrote:
| > 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...)
| robotnikman wrote:
| Wow, that sounds dystopic as hell...
| spookie wrote:
| 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.
| izacus wrote:
| 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.
| noname120 wrote:
| 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
| tadfisher wrote:
| 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.
| noname120 wrote:
| 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).
| probably_wrong wrote:
| 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".
| urbandw311er wrote:
| Good catch - that's horrendous and feels like absolute
| fobbing off with "type a bunch of cliches"
| spookie wrote:
| 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.
| izacus wrote:
| You're linking articles that are 3-6 years old and the
| performance has significantly improved since then.
| noname120 wrote:
| Not true. I had first-hand experience a few months ago and
| the performance is still abysmal.
| apitman wrote:
| 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.
| scottbez1 wrote:
| 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.
| izacus wrote:
| 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.
| aborsy wrote:
| 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.
| dzikimarian wrote:
| 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 :-|
| tuga2099 wrote:
| Can Google drive app for any android upload all file types?
___________________________________________________________________
(page generated 2025-05-14 23:01 UTC)