ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

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.

 Let's also not try to
> be nannies to every possible "bad app" situation.

This is exactly what we need to do, else we're going to end up with a store full
of malware. We have the opportunity to do things right at the moment, and we
need to draw some hard lines on what is allowed and what is not.

 Even with confinement,
> and the app lifecycle, there are thousands of malware things I could do
> in my app.

Please be specific, so we can fix these issues right away.

 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.

Sure it will, it will get us to the point of being the platform people want to
use because their phone is fast and has great battery life from not running a
zillion background services.

It's not about allowing everything, it's about finding innovative solutions to
enable everything app developers want without compromising on security and privacy.

Contrary to other platforms, ours is open...anyone can help write the functions
of the core os. If we need an IRC background service, for example, let's allow
developers to contribute to the blessed one that we can ship as part of the OS
instead of simply allowing arbitrary apps to run arbitrary background services.

Do we want torrent applications in the store? Then let's allow people to
contribute a torrent service that we can audit and ship as part of the OS.

Marc.