ubuntu-phone team mailing list archive

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

On Wed, Jun 25, 2014 at 7:00 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> On Wed, 2014-06-25 at 11:21 -0400, Marc Deslauriers wrote:
>> 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.
>
> I didn't say it didn't matter. But it only matters to a point. There are
> so many things that I want to write apps for on Ubuntu, but the design
> of confinement and lack of background processing, just makes it
> impossible to do. Adding system services for some things isn't going to
> change this situation for me. A large number of the things don't make
> sense as system services.
>
>>  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.
>
> Our store is going to have plenty of malware in it if our platform
> becomes as popular as Android. No matter what we do in terms of
> confinement. The only way to not have any malware at all, is to not have
> any apps.
>
>>  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.
>
> They are not fixable in any way that is meaningful to users. If we were
> to confine apps that use location data such that they can't talk to the
> network, then that immediately prevents anyone from writing any mapping
> applications for example. If I want to write a game that mines for
> bitcoins on your CPU in the background while you're playing the game,
> there's no way for us to confine it. Maybe we implement CPU usage quotas
> so that any one app can't use over N% of the CPU, but it doesn't prevent
> the possibility of doing such an action. Games are a great place to do
> these things in Ubuntu, because they require the user to constantly be
> tapping the screen while playing them; which keeps the screen alive, and
> the process running. Or my game could use your Twitter account from
> online accounts, and start spamming your followers with your current
> score in the game.
>
> Some of these things are just not going to be hard to do if we're going
> to allow any sort of reasonable development of apps on our platform.
> Others we might be able to have clever confinement stories for, to make
> it harder for developers to exploit. But in general, I think we should
> let the ratings and reviews system in the store take care of this. If an
> app does too much and kills batteries fast, users will write bad
> reviews.
>
> What we need is a good permissions handling story that doesn't destroy
> the UX of actually using the platform and any apps on it, so that if say
> a flashlight app is grabbing the location, the user can know about it.
> The story here in Android and iOS is generally bad, because they don't
> provide fine grained control over things, and require apps to request
> all permissions to do some things. If we can provide fine-grained
> control, and require capabilities to be listed in the click manifest for
> the app's package, we can provide an appropriate UX which is not
> overbearing, or horribly incorrect, for the user.
>
>>  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 a platform people won't bother using, because they can't use it for
> the useful things they do, which iOS and Android to allow them to do.
> Just because iOS/Android have app stores that have a hundred thousand or
> more malware apps, doesn't mean the majority of users are using those
> apps daily or that iOS and Android don't have users.
>
>> It's not about allowing everything, it's about finding innovative solutions to
>> enable everything app developers want without compromising on security and privacy.
>
> We don't need to allow everything, but we shouldn't block everything,
> either. I'm all for security and privacy, but not at the expense of
> actually being able to use my phone for all the things I need to do.
>
>> 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.
>
> If I have to work to get a blessed system service for everything I want
> to do in the background for all the apps I want to write, I will never
> write those apps. For many of the apps I wish to develop, a background
> service is the only way for the app to work properly (unless I can
> actively exploit the implementation of pause/resume for apps by ignoring
> SIGSTOP).
>
>> 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.
>
> If some user really wants to waste their battery life and data cap by
> running a torrent app on their phone, I don't see any reason to keep
> them from doing so. I don't think we should provide a blessed service
> for every possible thing that every possible user or developer might
> want to do on their phone. It will always be behind the times, and it
> doesn't solve the problem of getting developers to build apps on the
> phone. It just makes it that much harder to build apps for the platform.
>

Hmmm, I see some problems here: I don't think a user starting a
torrent app on the phone is a strong indication of the user wanting to
waste battery life and his/her cellular data plan. I think the user
can rightly expect the system to transparently take care of scarce
system resources like:

  * power
  * cpu cycles
  * gpu cycles
  * memory

On top, I don't think that each and every single app out there
requires sophisticated background processing to be immediately useful
to the user. The entire conversation in this thread focuses on that
one part of the app lifecycle and we spent quite some time and thought
to present a solution that keeps *most* users and *most* developers
happy. On top, the presented solution of system-provided services is
meant to grow over time based on the feedback we receive from users
and developers, and we can get started adjusting/identifying services
right now.

The other point I want to make: Being strict about the app lifecycle
is surely difficult and takes time and thought. But it allows us to
evolve the platform. Along that lines, just opening up the world to
apps to do whatever they want is not maintainable over time as you
usually cannot take back any sort of functionality that you once
committed to.

Cheers,

  Thomas

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