←back to thread

Syncthing Android App Discontinued

(forum.syncthing.net)
396 points opengears | 3 comments | 20 Oct 24 14:51 UTC | HN request time: 0.922s | source
Show context
scottbez1 ◴[20 Oct 24 21:30 UTC] No.41898633[source]▶
I used to develop Android professionally (at Dropbox in the 2010s, so I have some familiarity with older Android filesystem APIs) and made a very conscious decision to switch to devx and backend work and get out of Android (as did most of my former Android colleagues). The unending hoops you had to jump through and API changes to keep your app working were too much of a pain.

As a fun anecdote, in 2014 when the "secure" Storage Access Framework was new, I found a trivial directory traversal vuln that allowed writing to any app's private directory by just passing a "../../" file name to the system [0, 1]. It was so trivial I noticed it while just browsing AOSP source to understand SAF better...

Android also used to grant world execute bits to app folders for the longest time, allowing malicious apps to create hard links to other apps' files by name, which could then be handed back to that app for a confused-deputy attack to gain access to the file contents.

All that to say - I'm glad Android has been working on security, but it was built upon such a loose foundation that tons of apps used and abused that it's going to drive developers out of the ecosystem as they have to keep adapting to a continuous stream of major breaking changes as things are locked down.

[0] Bug 18512473 fixed in https://android.googlesource.com/platform/frameworks/base/+/...

[1] Proof of concept video: https://www.dropbox.com/s/8dpd8visrttqbfo/poc.mp4?dl=0

replies(1): >>41899051 #
psanford ◴[20 Oct 24 22:33 UTC] No.41899051[source]▶
It sucks that the ongoing maintenance cost for the native mobile platforms is so high. Who wants to develop on top of a platform that is constantly changing out from under you?

It really makes me nostalgic for the vision of webOS (although not the implementation of webOS from 14 years ago).

replies(1): >>41899322 #
1. awill ◴[20 Oct 24 23:20 UTC] No.41899322[source]▶
But that's Scott's point. If the OS devs had thought through this from the beginning, app devs wouldn't have to keep dealing with breakage. iOS devs have other issues, but not these.

Apple and Google approached the mobile OS from opposite sides. Apple locked everything down and has gradually been adding access/features. Google left the barn door open, and is now trying to shut it. I know which OS/API I'd rather program against.

replies(2): >>41899402 #>>41902701 #
2. scottbez1 ◴[20 Oct 24 23:31 UTC] No.41899402[source]▶
Heh, I never worked on iOS but based on what I heard from our iOS team at the time, I don't think iOS was any better. Though a lot of the frustrations back then were largely app review issues rather than API stability, like trying to push out a big feature release or bug fix and getting rejected because the reviewer found a new way to follow 20 links to get from the help center website to a page allowing you to sign up for a subscription outside the app store...

Web might be a better counter example - it started super locked down, but has slowly gained useful functionality like notifications, USB, serial, GPU, etc within the sandbox model. It just encourages more investment over time as new functionality is added, rather than annoying devs as useful functionality (documented or undocumented) is taken away.

3. Daedren ◴[21 Oct 24 10:40 UTC] No.41902701[source]▶
iOS doesn't regularly break these mainstay APIs.. but when they do break APIs, they never backport them, unlike Google.

One example of an API where we lost power in exchange for security was UIWebView -> WKWebView.

It can end up being far more annoying than usual, even for smaller APIs, because you must maintain both versions of APIs until you get the green light to raise the minimum permitted iOS version.