ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

Am 25.06.2014 11:12, schrieb Thomas Voß:
> 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 :)
There is a thing called tapchat: https://github.com/codebutler/tapchat
which seems to be a IRC bouncer with push capabilities. But you need
your own server to install it somewhere.  There are apps for android
but they are closed, I did not check the licence of the backend but it might
be interesting for us if its open :).
>
>> 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.
Still it would be awesome if a developer could provide his own telepathy
backend ;).
>
>> 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.
I agree with the security issues here, but depending on the protocol
you might need to send "still alive" messages to the server. So at least
there needs to be a way to wake the service somehow.

Also there needs to be a place where the app can pick up data that was
received
when the app was stopped/closed

What we definitely need is a indicator that there is a IRC/whatever service
running in the background. Maybe a services scope?
>
> 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.
I'm using a Jolla phone with a IRC client atm, the impact on my battery
life is not very dramatic but there is definately a difference.

Also isn't Push nothing more than a long running request to the server?
Which makes it a long running network connection as well, its just a more
predictable one.

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