11 ms·

This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start t

This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the services. Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.

raxxorrax 8y ago
I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here. It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.
- tass 8y ago
  What is a trash app by your definition?
- squarefoot 8y ago
  The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is. If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.
  - simonh 8y ago
    Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
    - xfer 8y ago
      > only a closed system with a single gatekeeper that can avoid this problem at scale I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?
      - simonh 8y ago
        You clipped off my answer to that question from your quote. I mean you can disagree, that's fine, in which case just say so.
    - zeveb 8y ago
      > Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. That's the beauty of the GPL: one can't lock down a GPLed distro that way. > In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility. Those who s/freedom/security/g tend to rm -rf / and get neither freedom nor security.
      - squarefoot 8y ago
        "That's the beauty of the GPL: one can't lock down a GPLed distro that way." True, but its strength is also its weakness in this context: anyone can keep the distro open but add some "vital" code that is closed and does what they want without anyone noticing. The GPL doesn't prevent closed code from running on open source machines, it just sets limitations on imposing limitations (which makes it so great IMO), so a module that displays advertising, tracks users or steals personal data can easily be implemented inside a closed app, blob, device driver etc. and unless I missed something the GPL can do nothing if that module was compiled using non GPLed compilers, linked against non GPLed libraries etc. In other words, if I take a non GPLed compiler and a set of non GPLed libraries that set no obligation to open the resulting code if I distribute the output, I can write anything and add it to a Linux distro then distribute them together without any legal obligation to publish the source and reveal the internals of my code. That would be the case for suspicious code inside blobs and drivers. Someone please correct me if I'm wrong. Of course the community can fork in no time, but imagine a very popular piece of hardware which could work only with that closed blob.
- simonh 8y ago
  The point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.
  - raxxorrax 8y ago
    I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much. And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration. "Managed" platforms accelerated this phenomenon in my opinion.
simias 8y ago
Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.
- sudhirj 8y ago
  Should also see if the killer apps are phoning home every time they kill anything, along with info about which app is killed on whose phone at what time. Becuase, you know, analytics.
- sudhirj 8y ago
  And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied. But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.
  - simonh 8y ago
    As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself. Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication. This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way. EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.
nbzklr 8y ago
This isn't about protecting the user from badly written and battery draining apps. Almost all of the mentioned manufacturers ship their devices with a long list of pre-installed and whitelisted services, including Facebook and other spyware. As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even possible).
- scarface74 8y ago
  It’s also not scalable if every app starts running background processes on an operating system without “virtual memory” - yes, I know there is a difference between virtual memory and swapping to the disk.
  - nbzklr 8y ago
    Even stock android does not guarantee that background services can run indefinitely, but Google at least provides clear rules what process may run how long in the background and under which circumstances it is killed. I have no idea why the manufacturers are allowed to blatantly break those rules and still brand their operating system Android.
bad_user 8y ago
>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks" iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does. _Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained. As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail. Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps. _Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc). There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.
- sudhirj 8y ago
  Example 1 has been solved with Background App Refresh a long time ago [1] Example 2 should work fine with the background mode declared [2] Both these APIs are pretty old... is there something I'm missing? [1] https://developer.apple.com/documentation/uikit/core_app/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/updating_your_app_with_background_app_refresh https://developer.apple.com/documentation/uikit/core_app/man... [2] https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background https://developer.apple.com/documentation/foundation/url_loa...
  - bad_user 8y ago
    1. no, does not work — email clients warn users that if the app gets killed then notifications will stop and yes, I tested this quite recently 2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-) Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02.34.png?dl=0 https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02... Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04.32.png?dl=0 https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...
TagAsDelusion 8y ago
pretext
draw_down 8y ago
That's right.
zmmmmm 8y ago
I think that's an over fatalistic interpretation. You're implying that giving more power to users inevitably results in them harming themselves and therefore should not be done, instead the OS vendor should make explicit APIs for everything and only whitelist "allowable" things. My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.

raxxorrax 8y ago

I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here. It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.

tass 8y ago
What is a trash app by your definition?
squarefoot 8y ago
The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is. If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.
- simonh 8y ago
  Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
  - xfer 8y ago
    > only a closed system with a single gatekeeper that can avoid this problem at scale I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?
    - simonh 8y ago
      You clipped off my answer to that question from your quote. I mean you can disagree, that's fine, in which case just say so.
  - zeveb 8y ago
    > Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. That's the beauty of the GPL: one can't lock down a GPLed distro that way. > In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility. Those who s/freedom/security/g tend to rm -rf / and get neither freedom nor security.
    - squarefoot 8y ago
      "That's the beauty of the GPL: one can't lock down a GPLed distro that way." True, but its strength is also its weakness in this context: anyone can keep the distro open but add some "vital" code that is closed and does what they want without anyone noticing. The GPL doesn't prevent closed code from running on open source machines, it just sets limitations on imposing limitations (which makes it so great IMO), so a module that displays advertising, tracks users or steals personal data can easily be implemented inside a closed app, blob, device driver etc. and unless I missed something the GPL can do nothing if that module was compiled using non GPLed compilers, linked against non GPLed libraries etc. In other words, if I take a non GPLed compiler and a set of non GPLed libraries that set no obligation to open the resulting code if I distribute the output, I can write anything and add it to a Linux distro then distribute them together without any legal obligation to publish the source and reveal the internals of my code. That would be the case for suspicious code inside blobs and drivers. Someone please correct me if I'm wrong. Of course the community can fork in no time, but imagine a very popular piece of hardware which could work only with that closed blob.
simonh 8y ago
The point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.
- raxxorrax 8y ago
  I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much. And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration. "Managed" platforms accelerated this phenomenon in my opinion.

simias 8y ago

Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually? By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.

sudhirj 8y ago
Should also see if the killer apps are phoning home every time they kill anything, along with info about which app is killed on whose phone at what time. Becuase, you know, analytics.
sudhirj 8y ago
And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied. But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.
- simonh 8y ago
  As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself. Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication. This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way. EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.

nbzklr 8y ago

This isn't about protecting the user from badly written and battery draining apps. Almost all of the mentioned manufacturers ship their devices with a long list of pre-installed and whitelisted services, including Facebook and other spyware. As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even possible).

scarface74 8y ago
It’s also not scalable if every app starts running background processes on an operating system without “virtual memory” - yes, I know there is a difference between virtual memory and swapping to the disk.
- nbzklr 8y ago
  Even stock android does not guarantee that background services can run indefinitely, but Google at least provides clear rules what process may run how long in the background and under which circumstances it is killed. I have no idea why the manufacturers are allowed to blatantly break those rules and still brand their operating system Android.

bad_user 8y ago

>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks" iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does. _Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained. As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail. Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps. _Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc). There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.

sudhirj 8y ago
Example 1 has been solved with Background App Refresh a long time ago [1] Example 2 should work fine with the background mode declared [2] Both these APIs are pretty old... is there something I'm missing? [1] https://developer.apple.com/documentation/uikit/core_app/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/updating_your_app_with_background_app_refresh https://developer.apple.com/documentation/uikit/core_app/man... [2] https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background https://developer.apple.com/documentation/foundation/url_loa...
- bad_user 8y ago
  1. no, does not work — email clients warn users that if the app gets killed then notifications will stop and yes, I tested this quite recently 2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-) Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02.34.png?dl=0 https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02... Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04.32.png?dl=0 https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...

TagAsDelusion 8y ago

pretext

draw_down 8y ago

That's right.

zmmmmm 8y ago

I think that's an over fatalistic interpretation. You're implying that giving more power to users inevitably results in them harming themselves and therefore should not be done, instead the OS vendor should make explicit APIs for everything and only whitelist "allowable" things. My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.