On the other hand Apple has forced apps to use location data for purposes it should not be used for. Termius, for example, is my favorite iOS SSH app. But according to them, they can’t keep an SSH session running in the background unless they’re constantly tracking your location data. And somehow Apple approved this usage of location data.
I don’t want to give Termius my location. I don’t want them tracking me everywhere I go. But apparently that’s the only way they can keep my SSH session alive when I need to switch to Safari for a few minutes?
Absent memory pressure, apps can stay open for up to 10 minutes in the background.
The correct solution here is for the app to request background processing and to schedule a local notification in 9 minutes saying that the app is about to run out of background time and pause (and then clean up the notification if the user returns to the app before it fires). This means you're not abusing anything, and it lets the user return before the connection is killed in order to keep it alive.
This also means if the user never returns, the app will naturally shut down the connection after 10 minutes instead of keeping it open indefinitely.
Yeah on iOS 13 I get Safari tabs reloading if I toggle between them. Just switching to one tab and back to the other will sometimes completely reload the page.
iPadOS was such a major leap forward for the iPad and there's not many features left I need to use it as a laptop replacement... but the aggressive app and tab killing ruins everything. I've never said this about iOS devices before, but it's time to start putting more RAM in these machines.
Under normal usage, iOS will kill apps a lot earlier than 10 minutes. In the general case it's really not possible to do this, and I would argue that shipping with a flaky feature is probably worse than not shipping with it at all.
I haven't checked in a while but in the past it was fairly reliably 10 minutes.
In any case, there's a property `UIApplication.backgroundTimeRemaining` that tells you how long you have, so you can use that to calculate the appropriate notification time.
I thought it was 3 minutes? Or is it 3 guaranteed, 10 maximum?
And yes, the app in question of course does exactly that notification dance (I've used it since long before it got its current name).
GP is talking about a new feature to keep sessions open in bg for a loong time.
I've disabled it, not for fear of tracking but because it seems like a silly way to forget connections open and drain the battery for no reason.
App has indeed also always supported mosh... me I just attach to tmux.
But I agree with whoever wrote it's better to have such a bg hack feature than not, for those who find it useful.
Or instead of using a hack that intermittently fails, you could use a platform that lets the app function correctly. The app can pester the user about if they want to keep the connection open only if the user specifically wants that.
Termius works perfectly on Android without requesting my location.
Hint: if Apple allowed apps to run indefinitely in the background, it would be less than a month before almost every app "needs to run in the background", for user-unfriendly reasons. And battery life would drop to a couple of hours.
This is why I'm an Apple user. Hate regarding Apple's policies like "use a platform that lets the app function correctly" (ie. drain battery running in background just to do more tracking, or because every developer assumes THEIR app is so special that it must never be unloaded from memory, in order to open instantly when being swapped back to... weeks after user's last interaction). With hilarious frequency, the complaints people have about Apple are precisely the reasons I prefer their products.
> Hint: if Apple allowed apps to run indefinitely in the background, it would be less than a month before almost every app "needs to run in the background", for user-unfriendly reasons. And battery life would drop to a couple of hours.
This doesn't happen on Android. The reason it doesn't is that the app has to display a persistent notification if it wants to run with high priority in the background. This is why I'm an Android user. It lets the user do what they need to do and prevents apps from being abusive.
Every excuse for Apple's platforms failings that I have seen so far has a better solution on Android that the Apple apologist has not heard of.
Main problem facing any app that needs to run in the background is that Apple only allows it for certain use cases - VoIP, audio/airplay, location and BLE being the main ones. That's why since iOS 13 users have been seeing alerts that apps with no reason to need Bluetooth are requesting it.
So I deny most apps use of this, as it's clearly just a ploy to keep their app running when it shouldn't be. Something like the Termius app you cite has a legitimate reason to run in the background though and has to ask for one of those permissions.
It's a weird grey area IMO. I'm sure if you asked the Termius developers they may tell you that they don't even use the location data and that it's just a mechanism to keep the app running. However, the fact that we as users don't know this for sure is a problem that Apple could fix by adding a specific background permission alert.
The problem as I understand it isn’t the ssh connection being dropped but the app being closed and needing to reload. Because iOS devices don’t have enough RAM to keep an app in the background while also running Safari.
the application being closed and needing to reload at some future point effectively drops the connection from the client side
mosh solves this use-case because there is no need for the client to remain connected to persist. It's like a tmux/screen terminal running in detached mode. When the app loads back up, it picks up the mosh session again.
> Mosh maintains the terminal session (not "connection" in the TCP-sense because Mosh uses UDP) even when a user loses their Internet connection or puts their client to "sleep." In comparison, SSH can lose its connection in such cases because TCP times out.[5]
Humorous, but the curse of Android devices is that every single app demands a perpetual background service doing close to nothing. Of course we see the same thing on Windows and macOS where everyone thinks they need their own background daemons for the most absurdly simple task.
Of all the things to be controversial, this has to be the most surprising: Who knew that HN was so much in love with egregious and unnecessary background daemons.
99.9999% of the time the most that is necessary is an occasional scheduled task. No, your picture of cats app doesn't need to run a busy loop pinging a server. Learn how to use the core messaging infrastructure of the platforms you target.
No, Chrome doesn't need to run a perpetual service just to check for updates.
I don’t see why it can’t be requested like any other permission. Otherwise apps just abuse location and audio to make it work anyway. It’s not like apps AREN’T working in the background.
There are extraordinarily few cases where apps on iOS need to run in the background, beyond what can be accomplished via a periodic scheduled task or the system eventing infrastructure. And the notion paraded here that every app is secretly doing it by pretending that it's playing audio is nonsense that has little correlation with reality.
Android very recently -- at API level 26 -- added restrictions on background tasks for that platform (and it's much more involved than if you display a notification or not). Before that every app developer just spun up a background service for everything, and anyone who has done an iota of development on Android devices saw the tragedy of the commons that the platform became. So kudos to Google for cleaning it up a bit. Of course Samsung, Google and others just declare themselves immune from those restrictions and it's just a smaller problem, not a solved problem.
That's indeed how it works on Android. If you want to have a high priority background task that isn't among the first to get killed when another app needs more memory, you have to tell the OS to show a notification that is displayed until the user shuts down the service.
iOS really needs a channel for legitimate, real background apps. A lot of its battery life and security advantages over Android come from the fact that it doesn't allow a wild-west of background processes, but there are certain cases where you really do just need that.
Apple is good at taking use-cases and creating cohesive stories around the right way to serve them; this one has been long-coming.
Agreed. Camera upload to DropBox is one situation I've run into. Currently it seems like it's using some janky set up where each time I change location it triggers an event to look for new photos to upload but this results in Apple notifying me of DropBox looking up my location X amount of times in the last few days.
Yeah, I think I declined that option so instead every time I open the Dropbox app, I get a notification 5 minutes later saying uploads were paused. It's exhausting.
Apple does have a small number of very specific use cases carved out where they allow apps to run in the background, like VOIP apps and audio players. But “I just want to run in the background to do stuff” has never been a legitimate use case in their view.
They could do it the same way they did it with background location (what this whole article is about) - keep pestering the user "this app has used 15% of your battery in the background, disable background processing for it?". Only the most die-hard IRC users will keep allowing it.
Apple's effective policy is that any long-running service should be mediated via a remote server. This affects not just SSH but every other protocol that relies on long-lived TCP connections such as IRC and XMPP. Not only can you no longer maintain the connection - you also need an out-of-band way to provide notifications via APNS. Together these requirements have hugely damaged traditional or federated protocols. Nowadays XMPP has extensions to handle this situation but the damage is done.
Meanwhile Matrix gets by because they have a company with actual money subsidising the client app (Riot) and providing notifications for every user, no matter which homeserver they happen to be using. Without that benevolence provided for iOS, Matrix could well be another non-starter outside FOSS circles.
> Meanwhile Matrix gets by because they have a company with actual money subsidising the client app (Riot) and providing notifications for every user, no matter which homeserver they happen to be using. Without that benevolence provided for iOS, Matrix could well be another non-starter outside FOSS circles.
So, I'm reading this that regardless of using a separate 'homeserver', Matrix receives all traffic/notifications?
In all likelihood, Termius isn’t collecting your location at all and it’s never leaving the app. Test it, but I’d be willing to bet that their servers never see your geolocation.
We also had to do this to get enough background time. I can honestly say we don't track you. customers also get mad when the app intermittent stops doing its job.
I just hope the app review team doesn't throw us out again.
I just don’t understand why Apple doesn’t have a “allow to run in background” permission. Instead developers have to resort to Bluetooth or silent audio or location tracking which further erodes user trust and allows for developers to say “I swear we don’t track you” while actually tracking you.
Termius is lying. They could just as easily played silent audio in the background to keep the app from being suspended. Although in my opinion both practices should cause them to be rejected from the AppStore since they’re clearly misusing the APIs. Must be an oversight from the review team at Apple.
Apple’s reviewers try to distinguish between apps that legitimately need to play audio in the background and apps whose use cases have nothing to do with audio (or location) and are likely using the APIs to work around the rules.
>And somehow Apple approved this usage of location data.
On one hand I agree with you, that's crazy that your SSH program put that limit on there for clearly tracking purposes. But I guess I sort of disagree this is Apple's problem to solve. It's yours.
Apple made the changes to inform and educate you the customer that an app that is abusing your trust.
The solution is not to force Apple to police developers but for you to stop using Terminus. Call it a free market solution if you like.
The difference with real and ideal is that Terminus could absolutely find a "legitimate" use for location and it would scoot right by Apple review anyhow. So let them be upfront they're bad people being bad.
(Before it comes... I KNOW... Apple walled garden and how they do this a lot anyhow! But, as someone who has walled garden issues with Apple, we should encourage information and education over big brother protecting us. It might not be consistent for them, but I think it's the right move here)
The reason I called out Apple is because they normally take a strong stance on misuse of permissions. I’ve had my own apps rejected for the justification “I need location permissions so I know where you are” in a mapping app where the use case is obvious.
If Apple is playing hands on, they deserve just as much blame.
I don't disagree. They need to do have a consistent approach. Selective enforcement is not likely the thing here, it seems like sibling that this just got missed.
So, report to Apple, file a review, stop using it.
If Apple comes to the rescue and characteristically fixes it, great, if they don't - they've already made great steps in allowing you to make informed decisions.
Why stop using the app, let one report it, and not just turn the unwanted feature off?
And I think the app is covered since it's saying "enabling location data means you can plot on a map where you've connected to a host" or something like that in settings - good enough a bs feature for Apple to let it slide, evidently.
That's what I'm taking issue with. I don't like the feature, hence I don't use it. But why default to faulting them for adding a feature that's clearly useful enough for some to justify being hackily implemented?
As someone presumably technically capable wouldn't the first step be ensuring sync is off, routing through a pi or whatever and firing up Wireshark to check whether it's even possible that something malicious is going on? I'm not saying it's not - I have no idea. But I'd certainly have a look before making any claims.
>The solution is not to force Apple to police developers but for you to stop using Terminus.
The actual scalable solution is for Congress or states to pass GDPR-style privacy legislation (or CCPA if your politicians are captured by tech industry interests).
The scalable solution is to stop using Apple products and use platforms that let you do what you want without resorting to silly hacks that might hide actual privacy violations.
I don’t want to give Termius my location. I don’t want them tracking me everywhere I go. But apparently that’s the only way they can keep my SSH session alive when I need to switch to Safari for a few minutes?