Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
So stick had to come out. The full filesystem access is now reserved for apps that manage full filesystem (e.g. file explorers) and that's it. Scoped storage APIs were introduced in 2013, 11 years ago and Play started enforcing them in 2020, so the experiment with scary warnings was running for 7 years and developers refused to give up on that sweet full private file access.
Granted, SAF is quite a shitty API.
Seems like a perfect fit for SAF.
I really can't agree with Google in this particular case.
I grew up when computers didn't babysit me and tried to act like the good old GDR, knowing every thing better than their citicens.
Nowadays, I feel more and more hindered by computers, not enabled. Computers used to be a production device (I could create things with them).
Phones are not a computer - phones are a just "consume like we want you to" device.
The problem is, I want my phone to be a creation device. A device that allows me to create content, text, to do lists, shopping lists, ideas and store them. And(!) sync them using the tools I decide to use. And not force me to use tools I friggin hate, because they just don't get the job done.
I want to be able to get all data from my phone - regardless of what it is and what app put it there.
If I decide to only sync specific folders. So be it. But I want to be able to sync "/"
The risk here isn't misuse of the data, it's that some exploit is found in the code, and the additional protection of limiting its filesystem access is marginal (but nice to have).
Android/Google Play review keep restricting APIs and replacing them with less capable APIs, or keeping the APIs and reducing functionality.
It works again, but I had a USB endoscope that stopped working because Google pulled APIs and took a while to replace them. I can't use location sharing in my choice of apps anymore because something on my phone blocks either app runtime, app internet access, app location, or gps decoding and I don't use it often enough to be motivated to delve through logcat to figure it out, if they even still let me use logcat?. I'm sure it helps my battery life, but it reduces the functionality of the phone.
This was a competitive distinction against Apple's closed "safety first" platform design in iOS and led to an ecosystem of applications that took advantage of all these extra possibilities. As Google tightens its grip over the platform and pursues more aggressive limitations for security reasons (and whatever other ones), it's inevitable that many publishers and users are going to be deeply frustrated when the features that made their device theirs are no longer available.
(And incidentally, the restrictions on the Apple side have nothing to do with the application development language. I don't know where you would get that idea from or how to even make sense of it. It's just the nature of Apple's original design philosophy for iOS, where apps were deeply isolated and had no more capabilities than were necessary. Largely, Apple has been gradually adding capabilities to heavily-restricted apps over the lifetime of iOS, while Google has been moving in the opposite direction because they each started from opposite ends of the design space.)
Technically, the guy who inherited Syncthing Android maintenance destroyed it because he didn't want to use the file permission APIs.
Which, of course, is a reasonable decision for a maintainer to make when they're working with limited resources. But I have to say in this case I find some of the maintainer's behavior to be a bit surprising for a project as mature as Syncthing.
google could always contribute to the open source app to implement the features they wish to see, but instead of using their billions for good they'd rather use it for evil.
I think you're overlooking the obvious motivation of "maintain a lock on a substantial profit stream".
Almost by definition, the people who argue strongly for free use of their hardware and software are almost never the same people who argue strongly for safety and security restrictions. You seem to be frustrated by a contradiction or inconsistency that doesn't exist.
It's true that Google can't win the hearts of both sides, but they surely know that -- you don't need to get so personally frustrated on their behalf. It's just a company with a product in a market, and the market is never going to be uniform.
Google use to allow just any app to access the whole drive. That's probably too permissive. Now they've obviously swung too far the other direction, where even well intended, experienced devs are unable to work within Google's new constraints.
There's very few permissions on android that are system/privileged/preinstalled.
If they do need access to literally everything on the device, then it seems reasonable that they have to pass some minimum security bar. After all, several of the apps whose data they want access to are used to secure things like private medical records, classified information, etc.
At some point, the encrypted data has to be mounted as plaintext so apps can work with it. It seems reasonable to ask for some kind of permission system so that apps have to declare they need to read these files and so users can make a decision about whether to allow that access. But these developers are refusing to even ask for that permission.
From the description of the people who wrote these apps, there are 2 basic APIs at play:
1. Get access to the entire drive.
2. Ask for permission to individual files.
I would have assumed there was a middle ground like asking for permission to a specific folder's contents, yet those same devs insist that's not the case. iA Writer users want to edit everything inside a folder. Syncthing users want to sync an entire folder. Transmit users want to select upload/download to/from an entire folder. If Google made those APIs available then we wouldn't be having this conversation.
OS vendors shouldn't make it impossible to create apps that have unlimited access to the filesystem or that suck battery in the background. There are reasons users might want to run apps that do either or both - a file indexer, for example. All the OS should do is ask the user if the app has permission to do those things.
An app store provider on the other hand might reasonably have many criteria for inclusion, such as F-Droid only allowing FOSS. This only becomes problematic when the app store in question is effectively a monopoly.
The truth is Syncthing doesn’t have the resources to keep up with Android platform changes and Google’s review process.
why does google(or apple) need "special interfaces" to access the filesystem in a specific way, why don't they just use the existing file api and improve the file access permission system.
I think the unix single tree filesystem was one of their great innovations and see this multi tree api fragmentation bullshit as a sort of backwards regression.
My cynical read is that the filesystem is user freedom, and the walled gardens don't want user freedom.
Privacy and security are literally the reasons for these APIs. I don't see how you could possibly call that a strawman.
> I would have assumed there was a middle ground like asking for permission to a specific folder's contents,
Isn't that what OPEN_DOCUMENT_TREE does? https://developer.android.com/reference/android/content/Inte...
Except SAF is slow as hell, working on multiple files means separate calls for every little thing like file size via java API. Means everything going to be VERY slow and drain battery a lot. I've seen test from 2019 where directory listing operation is 25-50 times slower in SAF
Most file system API changes aren't exactly recent, they're just inconvenient. Most changes were introduced in Android 11, with some going back all the way to Android 4.4. App developers tried to use workarounds, exceptions, and special permissions to work around API restrictions as long as they could and now the holes in the sandbox are finally being closed.
The Syncthing for Android app hasn't had much development in the past few years, so years of minor changes have added up to tech debt that's (too) expensive to fix.
I'm not saying that's a good thing, but it's not exactly a secret when you bought it.
> I guess I'm a bit at a loss about why these app developers feel they need access to things like medical records stored on the work phone of everybody at your doctor's office.
...which isn't a strawman. It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.
As to OPEN_DOCUMENT_TREE, to my naive eyes that's what it looks like to me, too. That said, I'm confident that the devs we've discussed here, particularly the ones who sell the related apps for their livelihood, are clever enough to read the docs and that they've ruled it out for some reason. I certainly don't think the Syncthing team is too incompetent to use a documented method if it magically did the right thing.
iA -- one of the cases you mention -- balked at needing a standardized security assessment to access the full Google Drive.
> In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit.
https://ia.net/topics/our-android-app-is-frozen-in-carbonite
Googe Drive as part of Workspace is HIPAA compliant (https://support.google.com/a/answer/3407054?hl=en), meaning medical offices can and do host medical records on Drive. It's not mentioned in the article why iA needs access to all files on a HIPAA compliant service.
Workspace is also (at least partially) FedRAMP compliant (https://support.google.com/a/answer/13190816?hl=en). So similar questions arise as to whether iA needs to access federal data.
There really is: https://puri.sm/products/librem-5.
And it's my daily driver.
Flash your favorite open firmware, enjoy and let regular users who cannot do that avoid permission extortion. The world has needs and issues, it is not spinning around your skillset.
It's also way more clunky for the user than using the file picker, and has the potential for user confusion because the app is silently denied access so it thinks the file/folder doesn't exist.
I feel like theyr'e doing this just to minimize storage costs or something lol. Android dev sucks for a hobbyist
It's why both App Stores are now dominated by corporatized growth chasers compromising their UX with endless feature treadmills and pushing for subscription IAP to fund it all.
Building a personal/family lifestyle business from the long tail on a few good niche apps, sold at a modest and respectful upfront cost, is pretty much a thing of the past now; and all the software we loved has been delisted or sold to those corporatized growth chasers.
4 years ago, there would have been zero friction for these use cases.
However: - You can't pick the root of a storage volume, only its subdirectories. This is presumably for your own good. - The application is still forced to use the SAF APIs, which are slow (each call requires an IPC) and overcomplicated. For working with multiple files, directory listings, etc, naive use of SAF can be a couple orders of magnitude slower than standard File APIs. This can be sped up, but it's never going to be anywhere close to native speed.
I can understand why the developers can't be bothered with a badly thought out new system.
That's not true at all though, `ACTION_OPEN_DOCUMENT_TREE` gives app permanent access to shared directory using the file chooser dialog. It needs no extra privileges or permissions outside user choice of dir.
Android has been pushing to restrict the usage of such features for a while. It sounds like now they finally pushed hard enough that Syncthing broke.
As a longtime Syncthing user I'm personally fine with this. I think its fair for Google to demand a certain minimum bar of polish for apps on the Play Store. I'll continue to use Syncthing on F-Droid so long as its feature set continues to make it superior to those more polished alternatives. Hopefully the absence of Syncthing on the Play Store will create an opportunity for another file syncing app to fill that void, or incentivize contributors to eventually bring Syncthing up to snuff to get back on the Play Store. (Or possibly, incentivize Google to develop tools to make it easier for low-budget apps like Syncthing to meet their quality standards.)
[1]: https://github.com/syncthing/syncthing-android/issues/1048#i...
At least the parts it can access, anyway: /storage/emulated/0
Try asking an elderly user of an Android phone where the attachments from gmail they have tried to save are stored in.
I think they'd cope a lot better with a standard folder/file hierarchy as opposed to saving into a folder/file hierarchy but never at any point telling the user where in the hierarchy they saved to!
And every app saves to a different location. I've been using computers my entire life and I generally have to resort to a file manager to find what I'm looking for.
As for the mobile platforms I just don't care for it much anymore. I think Jobs was right from the get go with the iPhone: the functionality that was first announced is the most important, every else is just not very necessary. Most apps are a wrapper for a web app for some smart caching anyway. In any case the small screen size and obligatory use of fingers for input make it a slow imprecise tool for any doing stuff and I believe this is why the smartphone is such a content consumption addiction machine, there is just not much else that it does well...