ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Mon, 2014-06-23 at 09:12 +0200, Thomas Voß wrote:
> > IRC and messaging platforms not covered by "Online Accounts"
> 
> Push notifications FTW, they provide an easy and straightforward way
> out of the lifecycle trap.

Push notifications are totally the wrong solution for IRC/IM services.
At that point, you've relegated the benefit of using IRC/IM to building
a complex system to essentially do SMS. As far as users are concerned,
it would be far less hassle for them to just send an SMS.

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

Let's not conflate the lack of confinement on Android, with background
services being able to do things. Even without background services,
there is absolutely nothing preventing me from writing a flashlight app
on Ubuntu, which sends your location to some server when it runs. It
might not do it persistently, but does it matter? Let's also not try to
be nannies to every possible "bad app" situation. Even with confinement,
and the app lifecycle, there are thousands of malware things I could do
in my app. If we limit things too much, developers won't want to build
apps on our platform, simply because they can't do what they need to do,
and users won't want to use our platform, simply because they can't do
what they need to do. Security and privacy are important, but removing
the user's freedom and free will in pursuit of them, will get us
nowhere.

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

For a background service to work, the confinement implementation could
require appropriate entries in the click package manifest, and the
information could be presented at install time, or when the app is first
run, by the system, and not by the app or service itself.

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

There is no such thing as predictable battery life. Arbitrary external
factors even play with battery life. There is absolutely no way you can
reliably predict battery life in the real world. The best we can do is
replicate testing conditions of say the Nexus 4, and hope to achieve
similar or better battery life in those same conditions, when running
Ubuntu instead of Android; or on a phone of similar battery capacity
with similar hardware, that is shipped with Ubuntu from the factory.