ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

Hey,

On Sun, Jun 22, 2014 at 5:43 PM, Fabio Colella <fcole90@xxxxxxxxx> wrote:
> Currently the app lifecycle may kill an app in any moment if the app is not
> on focus. Most of the apps are designed to be used when focused, but there
> are many other apps that require to work even when not in focus, many
> examples:
>
> Running apps: should count calories and distance even when not focused
> Data Sync (Dropbox, OneDrive, GoogleDrive): should continue the up/download
> and   syncronization when not focused.
> Torrent apps(Transmission)

The download service should be a good starting point here, with
background synchronization being somewhat an exception.

> IRC and messaging platforms not covered by "Online Accounts"

Push notifications FTW, they provide an easy and straightforward way
out of the lifecycle trap.

> Custom Keyboards and Lockscreens (this needs even more work)

>From my perspective, custom keyboards and lockscreens are a different
category. Allowing 3rd party components to replace security sensitive
components requires us to think through all the possible security
implications. Not saying that it is not possible, but it takes time
and attention to detail to get it right in the general case.

> Firewalls, antivirus, antispam (may become useful when the platform becomes
> popular, we should take them in account)

They would fall roughly into the same category as background synchronization.

> Other things to which I'm not currently thinking to but that may be useful
>
>
> The current approach is to use system services to achieve the results: this
> is what happens with music and messaging apps. The problem with this
> approach is that we may end up with the need to create really many services
> and still not cover all the needed requisites. On the other hand we may just
> deny the developers and the users to create and use certain kind of apps.
> The advantages of not allowing background services are mainly longer battery
> life and better overall performances.
>

Sure, and I would like to add security and privacy on top: Any app or
service running in the background can easily spy on the user. The
flashlight-app on Android harvesting a user's location is one of the
prominent examples why this is an actual issue (see [1]). Not having
ordinary app's or their services (intents) running in the background
helps a lot in establishing and maintaining a clean state.

> I think we should find a compromise that allow the user to use apps that
> need background services but also makes him/her free to stop/resume them.
>
> My idea for background services:
>

Do you refer to system- or app-provided background services here?

> should need an Apparmor permission

If we ever allow background services provided by apps, they will be confined.

> should warn the user that the app uses background services

We are about to implement this feature for system services. For app
services, this trust model does not hold as you cannot force an
application author to prompt the user for trust.

> should be killable/pausable by the user and visible in the home scope and or
> in the notification area

Ideally, the user should not need to take care. Please note that I'm
not assuming us, i.e., the subscribers to this mailing list, but
non-tech-savvy users that expect the phone to "just work".

> could be autokilled/paused when battery life is low (this approach is the
> one used by Samsung, Google Drive, Dropbox) but should still allow the user
> to resume the service if he/she needs it even on low battery
> could be paused/resumed according to the number of running apps and services
>

We can certainly come up with a lot of interesting heuristics, infer
information from usage patterns of the phone etc.. However, they are
still heuristics and we would loose a very important property of the
system: Predictable battery life & secure system behavior, no matter
what applications are installed on the phone.

That being said: Instead of loosening the strict lifecycle policy we
should instead focus on expressing our use-cases within the lifecycle
framework:

  (1.) Identify common functionality that should be factored out into
system services.
  (2.) Leverage click hooks for injecting app-specific behavior into
services, under well-defined and strict security confinement and
resource restrictions (5 seconds max., limited amount of main memory,
no GPU access...).

Thanks,

  Thomas

> My consideration is that the user should always end up being able to decide
> what he/she want's to use and when. We put conventions (like stop on low
> battery) over user configuration, but the user should still be free to
> change it.
>

[1] http://www.techrepublic.com/blog/it-security/why-does-an-android-flashlight-app-need-gps-permission/

> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>