ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 06/25/2014 11:47 AM, Marc Deslauriers wrote:
> On 14-06-25 12:21 PM, Benjamin Zeller wrote:
>> Am 25.06.2014 17:21, schrieb Marc Deslauriers:
>>> On 14-06-25 11:02 AM, Rodney Dawes wrote:
>>>> 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?
>>> It most certainly matters. The amount of applications in the Android store that
>>> were created _specifically_ to generate revenue from user tracking is
>>> staggering. Having the flashlight app only be able to do it when it is in the
>>> foreground removes the incentive to have this sort of malware in the first place.
>> Can't we have confined services? When we have a apparmor profile for the
>> service
>> it can not go wild and just do what it wants right?
> 
> It can go wild and do whatever it wants inside of that confinement. For example,
> a background service of any app that has "networking" (which means most of them)
> can track your location while you move about based on what network you are
> currently using, etc.
> 

At this point I'd like to mention for those that are not aware that our trust
model is different than other platforms[1]: "Importantly, permission to access
sensitive data by AppStore apps is typically granted or denied at the time of
access (caching the result for later use as appropriate), so users have a
context for the access being requested. This provides better usability and less
confusion overall."

location-service is one such sensitive API so regardless of whether or not a
malicious flashlight app runs a background service or not, when the app accesses
the location-service for the first time, the user will know about it and be
asked if it is ok (this answer will be cached for next time and is revokable).
If we ever allowed background services, we would want to figure out how to do
the same sorts of things for them (perhaps making it clear that it is a
background service that is performing the access).

That said, once the user grants the access, the app can do whatever it wants
with the data it receives. A popular app might be used frequently enough to
effectively track the user's movements without needing the background service's
constant polling (eg, imagine a social networking app that is used all the time:
today, the user is at home, next at the coffee shop, next at the airport, next
in another city, next traveling in a taxi, next at the hotel, next at a
restaurant, etc). Security policy and application lifecycle can't effectively
address this alone (after all, the user said it was 'ok'), which is why we put
the responsibility on the user to make the trust decision to trust the app or
not with contextual prompting. We also have ratings/reviews and App Store
policies for removing malicious apps and developers as they are reported.

Granted, it is *much* more clear to the user that the app is running and
potentially doing things when in use than when not and I think this is a
meaningful benefit of our application lifecycle policy, but as demonstrated it
doesn't necessarily help with the security/privacy of the device (I admit this
is perhaps splitting hairs on terminology).

I like (and agree with) Marc's comment about using the principle of least
astonishment though, and the lack of background services helps us achieve that.

[1]http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature