ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

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.