7 ms·

From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064 https://github.com/syncthing/syncthing-android/issues/2064 > Not

From the (current) final comment at https://github.com/syncthing/syncthing-android/issues/2064 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.

izacus 2y ago
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.
- homebrewer 2y ago
  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.
  - izacus 2y ago
    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. Granted, SAF is quite a shitty API.
    - monocasa 2y ago
      I mean, syncthing is exactly the kind of app I would expect to have full filesystem access.
      - growse 2y ago
        Why? I want it to have access to the folders I want it to sync, not everything on my device. Seems like a perfect fit for SAF.
        lukeschlather 2y ago
        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.
        izacus 2y ago
        There are Android APIs to let syncthing integrate as cloud provider itself and the author didn't use those either.
        evilduck 2y ago
        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.
        Zak 2y ago
  - deleted 2y ago
    [deleted]
  - ants_everywhere 2y ago
    > 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.
    - kstrauser 2y ago
      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.
      - ants_everywhere 2y ago
        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.
        2y ago
  - mcherm 2y ago
    > for no real reason other than to further tighten control they have of the supposedly "open" platform I think you're overlooking the obvious motivation of "maintain a lock on a substantial profit stream".
    - gruez 2y ago
      You mean google drive subscriptions? Are such revenues even "substantial"? AFAIK google makes the overwhelming majority of its revenue from ads.
- toast0 2y ago
  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.
- swatcoder 2y ago
  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.)
  - fny 2y ago
    Android is fine. There are many, many complaint syncing applications in the wild that use the sanctioned APIs. The truth is Syncthing doesn’t have the resources to keep up with Android platform changes and Google’s review process.
    - CorrectHorseBat 2y ago
      Why is Android moving so fast?
      - growse 2y ago
        SAF was first released as part of Android 4.4, back in 2013.
      - jeroenhd 2y ago
        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.
- beeboobaa3 2y ago
  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.
- EasyMark 2y ago
  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.
- somat 2y ago
  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.
  - david_allison 2y ago
    Cynical take: it puts Google Drive on a level playing-field with local storage (by making the local storage experience awful).
    - NotPractical 2y ago
      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.
      - somat 2y ago
        That sounds right, I would have implemented google drive as a filesystem driver, but I am not google so what do I know.
  - pdonis 2y ago
    > what is with this modern trend of trying to pretend the filesystem does not exist. My cynical read is that the filesystem is user freedom, and the walled gardens don't want user freedom.
  - crooked-v 2y ago
    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.
- NotPractical 2y ago
  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. [1] https://grapheneos.org/features#storage-scopes https://grapheneos.org/features#storage-scopes
  - gruez 2y ago
    >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.
    - NotPractical 2y ago
      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).
- thepra 2y ago
  I would have to disagree, so far the new file API has been the most buggy experience for many apps that have to use files every time that the app is running or is in background, and this is from a user experience perspective alone. I can understand why the developers can't be bothered with a badly thought out new system.

izacus 2y ago

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.

homebrewer 2y ago
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.
- izacus 2y ago
  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. Granted, SAF is quite a shitty API.
  - monocasa 2y ago
    I mean, syncthing is exactly the kind of app I would expect to have full filesystem access.
    - growse 2y ago
      Why? I want it to have access to the folders I want it to sync, not everything on my device. Seems like a perfect fit for SAF.
      - lukeschlather 2y ago
        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.
        izacus 2y ago
        There are Android APIs to let syncthing integrate as cloud provider itself and the author didn't use those either.
        evilduck 2y ago
        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.
        Zak 2y ago
- deleted 2y ago
  [deleted]
- ants_everywhere 2y ago
  > 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.
  - kstrauser 2y ago
    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.
    - ants_everywhere 2y ago
      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.
      - 2y ago
- mcherm 2y ago
  > for no real reason other than to further tighten control they have of the supposedly "open" platform I think you're overlooking the obvious motivation of "maintain a lock on a substantial profit stream".
  - gruez 2y ago
    You mean google drive subscriptions? Are such revenues even "substantial"? AFAIK google makes the overwhelming majority of its revenue from ads.
toast0 2y ago
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.
swatcoder 2y ago
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.)
- fny 2y ago
  Android is fine. There are many, many complaint syncing applications in the wild that use the sanctioned APIs. The truth is Syncthing doesn’t have the resources to keep up with Android platform changes and Google’s review process.
  - CorrectHorseBat 2y ago
    Why is Android moving so fast?
    - growse 2y ago
      SAF was first released as part of Android 4.4, back in 2013.
    - jeroenhd 2y ago
      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.
beeboobaa3 2y ago
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.
EasyMark 2y ago
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.
somat 2y ago
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.
- david_allison 2y ago
  Cynical take: it puts Google Drive on a level playing-field with local storage (by making the local storage experience awful).
  - NotPractical 2y ago
    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.
    - somat 2y ago
      That sounds right, I would have implemented google drive as a filesystem driver, but I am not google so what do I know.
- pdonis 2y ago
  > what is with this modern trend of trying to pretend the filesystem does not exist. My cynical read is that the filesystem is user freedom, and the walled gardens don't want user freedom.
- crooked-v 2y ago
  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.
NotPractical 2y ago
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. [1] https://grapheneos.org/features#storage-scopes https://grapheneos.org/features#storage-scopes
- gruez 2y ago
  >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.
  - NotPractical 2y ago
    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).
thepra 2y ago
I would have to disagree, so far the new file API has been the most buggy experience for many apps that have to use files every time that the app is running or is in background, and this is from a user experience perspective alone. I can understand why the developers can't be bothered with a badly thought out new system.