ubuntu-phone team mailing list archive

[Fabio Colella <fcole90@xxxxxxxxx>]

2014-06-23 9:12 GMT+02:00 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.
>

Yes it is, but the limit is that a developer always needs to wait that the
feature is system implemented before he/she can create an app like that. We
may think this today, maybe tomorrow torrent will be obsolete and new apps
will need to wait until a new service is created to support this.

>
> > IRC and messaging platforms not covered by "Online Accounts"
>
> Push notifications FTW, they provide an easy and straightforward way
> out of the lifecycle trap.
>

Seems this is fully covered. So, if I understood correctly, if I create a
new messaging app I can also use push notifications to make my app listen
while waiting for a new message. Right?

>
> > 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.
>

I agree with you, keyboards in particular have access to lots of sensible
data and should be privacy safe.

>
> > 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.
>

Antispam and firewalls may probably be implemented the way you say because
they're relatively download related. How would something like an Antivirus
be in the same category of data sync? I also think that it would require
whole disk access, or at least the whole user partition. Could a service
like ADBlock be implemented using background download service?

>
> > 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.
>

If we will have a service for GPS in background, like a Runtastic app, this
will be something that could happen even on ubuntu. The only way for me is
to prompt the user to have access to background services.

>
> > 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?
>
Both, one for system ones and one for app-provided ones.

>
> > 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.
>
My idea is that you would need to ask the permission for background
services, like many android apps do to auth google+ connection. It could be
a system prompt: "The app %s is asking access to use background services".
Then if the user presses 'yes' the app will have the apparmor permission
for backgound services, not before.

>
> > 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".
>

Pause and play could have the music icons, so could be easily recognizable
and would be equally easy also to use.

>
> > 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.
>

However we could loose many useful apps, or being able to implement them
only months after an Android one is released.
The predictable battery life would be equal, even background services
should follow the policy of the other services and require really few
resouces.

>
> 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...).
>

I think that you have many good reasons for that but finding every use case
seems to me an utopic task.
(joke: ready for next relase? XD) It would have the side effect of being
slow on innovation.

>
> 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.
> >
>

Thanks,
Fabio

>
> [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
> >
>