←back to thread

397 points opengears | 7 comments | | HN request time: 0.001s | source | bottom
Show context
jasonjayr ◴[] No.41896030[source]
From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064

> 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.

replies(1): >>41896431 #
izacus ◴[] No.41896431[source]
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.

replies(8): >>41896508 #>>41897183 #>>41897242 #>>41897307 #>>41897422 #>>41898178 #>>41899343 #>>41900928 #
homebrewer ◴[] No.41896508[source]
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.
replies(4): >>41896583 #>>41896829 #>>41897279 #>>41897419 #
ants_everywhere ◴[] No.41897279[source]
> 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.

replies(1): >>41897494 #
kstrauser ◴[] No.41897494{3}[source]
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.

replies(1): >>41897929 #
1. ants_everywhere ◴[] No.41897929{4}[source]
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.

replies(1): >>41897999 #
2. kstrauser ◴[] No.41897999[source]
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.

replies(1): >>41898317 #
3. ants_everywhere ◴[] No.41898317[source]
> We both know that first bit is a strawman, so we can move past it.

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...

replies(1): >>41898876 #
4. kstrauser ◴[] No.41898876{3}[source]
You're right; my bad. What you said was:

> 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.

replies(2): >>41898968 #>>41900058 #
5. ants_everywhere ◴[] No.41898968{4}[source]
> . 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.

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.

6. iptrz6 ◴[] No.41900058{4}[source]
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.

replies(1): >>41900102 #
7. kstrauser ◴[] No.41900102{5}[source]
I can imagine devs throwing a fit about that, then. They’re the ones who’ll get bad reviews even if it’s out of their control.