ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

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?
>  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.
Or it could get us to the point where people don't want to use our platform
because its not possible to run background services. We should not put
battery life over everything else, since for some apps its ok if they use
more battery, like a running/hiking tracker.
> It's not about allowing everything, it's about finding innovative solutions to
> enable everything app developers want without compromising on security and privacy.
Agreed
> 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.
Our platform is open and this is totally awesome, however closed
services might not want
to open their protocols to everyone. Since we want to have commercial
success
we have to think about them too.
And we can hardly put a reverse engineered clients into our platform right?

Also waiting for the next platform update, just to get app XY is also
not so nice...


Benjamin
> Marc.
>
>