> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.
I don't think Google was ever buy a "I don't want to use file APIs because writing the code would be hard." excuse for a security issue. I don't know what kind of exact "discussions" were possible here for "give me access to all user data, photos and everything because I don't think I want to use SAF APIs". It's like that dude in your company that will have a meltdown in PRs over his better way instead of fixing the comments and having code submitted.
Apple won't let you write into random directories past their APIs either, just because it would be too hard to use ObjC/Swift.
There's going to be loud, destructive friction when a 10-15 year old platform reduces the functionality available to its apps. Security models do need to evolve, but Android was introduced as a platform suitable for deep personal customization with few mandatory boundaries.
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.)
Two examples that recently bothered me:
* I can't grant an application permission to read and store files in existing folders. This means I can't store file transfers through KDE connect in my Downloads or Documents folder.
* I can't access the Android/ folder without a PC at hand. This means I'm unable to mod Android games without my laptop. Not a big deal - but it's still frustrating.
4 years ago, there would have been zero friction for these use cases.
Most changes seem to come down to "the sandbox APIs aren't sufficiently isolated, let's lock down the sandbox further".
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.
Google's app process requires active developers and just makes it plain impossible to make an app and have it work with minimal updates. You're not allowed to "feature complete" an app and just exist. Every few months they threaten me to upgrade this, upgrade that, fill out this form, submit this info and I eventually gave up this year and they've already deleted my developer account and removed the app from search.
I feel like theyr'e doing this just to minimize storage costs or something lol. Android dev sucks for a hobbyist
It sucks for small software entrepreneurs too, as the cost of keeping a trustworthy developer on retainer for that kind of maintenance work can easily eat the modest revenue for a good niche app. And iOS is fundamentally no better.
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.
Yeah, I'm sure it can. The app I was talking about was an app that handled appointments for my mom's business. 80% of her customers used the mobile website but a few liked the app for notifications and just liked apps but I eventually gave up as I'm not a fulltime android dev, just a backend engineer that can hunt and peck my way through an android app. It was fine for many years but the past 2 have been horrible and I eventually told my mom I give up
Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
They did, the upstading app developers like this one just forced people to give them full access to all data in the app (or the app wouldn't run) and ended up not implementing scoped storage - something HNers outright demanded several times and exposed as a good upside of iOS.
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.
It's my phone. It's my data. It's my choice to install the app. It's my choice to grant the permissions to all files. Because guess what, I'm using the app to sync all my files.
I really can't agree with Google in this particular case.
I couldn't agree more. Given how much frigging hoops I had to jump through to get my Obsidian over syncthing setup to sync with my company iPhone - I nearly gave up.
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 gave up. My phone now is just a communication and utility device, and thus I don’t feel the urge to upgrade until it can’t do those tasks. I went back to computers (and Linux) to be able to just use them as a computer.
Same. I wish there were an alternative (a practical pocket computer), but there really isn't. So I too gave up on fighting my phone, and have also completely stopped doing mobile development. I now treat my phone essentially as an untrusted, prepackaged walled garden with limited utility. :-/
How did you get iPhone Syncthing + Obsidian working? I was under the impression that it was basically impossible to share Möbius Sync's directory with Obsidian.
Got it working myself. I set up a share inside of Mobius Sync that reaches into the Obsidian folder. (note the entire thing, just one vault). I think there was a popup saying it was unsupported but I haven't had any problems yet.
The java.io.File API isn't removed from Android, nor inaccessible. You can absolutely still use it. Google Play has chosen to not accept it on their store unless you justify it (to their non working bots). In this case, the dev chooses to just drop the entire app because maintaining it just for Fdroid feels pointless.
There's very few permissions on android that are system/privileged/preinstalled.
That’s still not your product though. You only bought a licence.
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.
Have you considered that it's a plural "you" that you're choosing to pit yourself against, with different people each weighing different complaints?
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.
It's an open-source program, it shouldn't be held to the same standards as a closed-source program that just shuttles all of your data to someone else's computer.
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).
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
In a perfect world, what Syncthing does would be handled at the OS level and all OSes would seamlessly interoperate. In the real world the OS vendors are hostile to interoperability so the only way to get that is with a third-party tool that has OS-level access.
In reality, Syncthing is also pretty good at destroying battery life unless you go above and beyond to configure it in a way that then hampers Syncthing's ability to provide seamless file continuity between devices. I know that there will be disagreement here, but in my own opinion OS vendors are correct in being hostile to these apps under current circumstances. They could provide better ways to have third parties implement it and provide cross platform support for their platform solutions, but I've had Syncthing be the #1 cause of battery life drain on multiple devices and platforms before and it's honestly just not worth fighting with it. To get it under control relegates it to being not much better than rsync.
I think it's important to draw a distinction between OS providers and app store providers here. The fact that they're the same entity in most cases is or should be largely irrelevant.
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.
I want it to be able to browse to another app's private folder to sync the data of that app to my computer. If browsing to there it's not the job of syncthing then I need a file manager with those permissions.
For 3 years now I can't open my Downloads or Pictures folder without root, because their shitty API is unbelievely bad that it would take around 30 minutes to open a folder with that many files.
> Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.
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.
Or maybe this, plus Panic removing GDrive support from Transmit, plus iA dropping Android support from Writer because of it, point to a common perception that Google's API for doing things "the right way" suck to the point of unusability. If iA and Panic and Syncthing -- all who've supported Android for many years -- can't manage to make it work, then I suspect it's broken.
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.
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.
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.
We both know that first bit is a strawman, so we can move past it.
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.
> 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.
That's exactly what OPEN_DOCUMENT_TREE does. The typical workflow involves presenting a directory picker activity to the user and asking them to pick a dir (the app can then retroactively ask the OS to persist these permissions across restarts.)
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.
> . 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.
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.
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.
Apple's position is different, because Apple never let you have this kind of access.
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.
SAF is a slow, buggy mess, and it only works in Java/Kotlin, so it's understandable that they don't want to use it. GrapheneOS manages to allow native access (via Java or machine code) to only specific user-selected directories through its Storage Scopes feature [1]. They basically did SAF but correctly and without the funding of a megacorp.
>They basically did SAF but correctly and without the funding of a megacorp.
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.
You're right, it's far from perfect, but it shows that it's not difficult to restrict native access to specific files/folders using the kernel and not weird Java IPC (which I guess should be obvious anyway). Google could've opted to provide native access to files, in addition to access via SAF, when you select a file via the picker, but they didn't. Graphene did it correctly from the low-level implementation side, not the UX side (but they can't really make the UX easier without breaking compatibility with standard Android apps AFAIK).
I think burn out on free projects is a real thing. Heck I get burn out on old projects and I’m being -paid- to maintain them. Good will and accolades only go so far and passion runs out eventually, especially if you’re only one person and there’s no one there to give you respite for a good recharge and you’re facing a hostile entity like Google.
On that note. what is with this modern trend of trying to pretend the filesystem does not exist.
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.
You're nearly correct, actually. In addition to security, SAF was supposed to provide a consistent interface to access files from various sources, including network sources, not just the local filesystem. Unfortunately the implementation just kind of sucks.
For the overwhelming majority of users, the file system is a confusing implementation detail that often breaks something when they're forced or tricked into directly interacting with it.
it's how the cross platform software works and has always worked. demanding a total rewrite just to publish on a single channel is insane, especially since this used to be the ONLY way to do things.
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.
> Nothing came of the discussions with google. Demands by Google for changes to get the permission granted were vague, which makes it both arduous to figure out how to address them and very unclear if whatever I do will actually lead to success. Then more unrelated work to stay on play came up (dev. verification, target API level), which among other influences finally made me realize I don't have the motivation or time anymore to play this game.