ubuntu-phone team mailing list archive

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

On Wed, Jun 25, 2014 at 9:41 AM, Benjamin Zeller
<benjamin.zeller@xxxxxxxxxxxxx> wrote:
> Am 24.06.2014 11:14, schrieb Thomas Voß:
>> On Mon, Jun 23, 2014 at 11:32 AM, Fabio Colella <fcole90@xxxxxxxxx> wrote:
>>> 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.
>> As I pointed out earlier: A strict lifecycle is a somewhat more
>> conservative choice to ensure predictable behavior for the average
>> user. Please also note that the lifecycle policy is meant to be
>> swappable for different usage scenarios, e.g., if the phone is docked
>> or connected to a power supply, we could adjust the policy to be less
>> strict. However, adjusting the policy requires deep thought about the
>> implications.
>>
>>>>
>>>>> 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?
>> Yup.
> Push notifications are great, but how would you implement a app that can
> not communicate over Push? Lets take a simple example, a IRC client,
> we can hardly ask the user to install a own Push "proxy" somewhere just to
> use that client.

Well, that's debatable, specifically for the case of IRC. I would love
to see an IRC app that provides an IRC proxy ootb (ignoring privacy
issues here). In general, I agree with your point though :)

> Also a IRC server will not buffer your communication so you need
> to be able to react on socket events. Running it as a app does not work
> either, because as soon as the app goes into background it will be stopped.
>
> Maybe you even want to get notifications if the app is not open at all.
>
> How about using telepathy backends for things like that?

I think we shouldn't tie to specific implementations here and think in
more general terms that are applicable to all app developers.

> Or alternatively a trusted helper that wakes the app/backend when data is
> available on a socket/filedescriptor?

Dispatching to a service-specific helper type definitely is an option
here, but we should (and will not) wake/start the entire app.
So seems like the general service would be a network/communication-hub
that monitors a socket for readibility & dispatches to app-specific
helpers. I don't think that helpers should be able to write back to
the network, but only be allowed to "translate" to device-local push
notifications. Otherwise, we would sign up for security issues with
helpers sending out information in the background.

One other thing that would have to be considered is the impact of
long-standing network connections (as would potentially be maintained
by the service) on battery life. We did some testing in the past, will
find out the results and share them here. At any rate: I think we
should work hard to stick with a push model as opposed to a pull
model.

Thomas

>>
>>>>
>>>>> 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?
>> Not sure why ADBlock would have to be a service. @data sync and
>> @anti-virus: Both need almost unconfined access to the system, both in
>> terms of access to files and in terms of lifecycle exceptions.
>>
>>>>
>>>>> 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.
>> And Android is the platform famous for inferior battery life ...
>> partly due to arbitrary apps (or their intents) being allowed to
>> execute in the background. The reason is simple: Most users will just
>> reply "yes" to the permission screen, assuming that the system
>> ultimately takes care (which it should). I don't think that we should
>> assume the user to maintain the list of running applications or
>> running background services. Instead, we should aim for doing the
>> right thing, even if the "right thing" for a particular usage scenario
>> (mobile device, not connected to power supply) is more
>> conservative/strict than what a tech-savvy user is used to.
>>
>>>>
>>>>> 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.
>> Please see my comment before. A user shouldn't need to
>> maintain/administrate his/her phone to ensure good performance and
>> battery life.
>>
>>>>
>>>>> 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.
>>
>> The devil is in the detail here: Implementing "require really few
>> resources" is difficult to achieve in the general case.
>>
>>>>
>>>> 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.
>> Looking at other platforms, I wouldn't say that iOS is slow on
>> innovation, despite its lifecycle being strict. Instead of looking at
>> Android as a reference here, we should try to distill common
>> background functionality required by classes of applications and
>> provide services for those.
>>
>> Cheers,
>>
>>   Thomas
>>
>>>>
>>>> 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
>>>>>
>>>
>
>
> --
> 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