ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 14-06-25 01:00 PM, Rodney Dawes 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.

So I gather you have the same problem on iOS, as much of the same limitations
exist there?

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

I disagree with that. The Android store contains a massive amount of malware, in
contrast to the Apple store which contains very little. The difference is that
Apple performs manual reviews for apps, apps have very little control on what
they can do in the background, and they are very confined. Android's automated
app approval process that basically allows every app to request any permissions
is the problem.

I believe our solution is better than that. Our app approval process is
automated if you use the default confinement policy groups. If you need
something more, you then need to go through a manual review / partner agreement,
etc. This should allow us to get the benefits of the Android app submission
process, with the security of the Apple store.

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

Sure, but that can't happen once the app is no longer in the foreground. I do
understand that a game can steal your cpu cycles while you're playing, but,
honestly, that isn't much of a threat, IMHO.

As soon as you enable an app to run in the background, that becomes a much more
important threat.

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

I agree...there not much we can do for apps running in the foreground stealing
cpu cycles, but yeah, the review system will possibly take care of it.

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

Yes, that is what our platform will do.

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

This is why we are using trusted helpers, they allow the user to transparently
grant fine-grained permissions with context. When they can't be done
transparently, for example, granting access to your location, they can still be
done when required providing the user with context.

There is no good way of displaying or asking security relevant questions to a
user when an app is in the process of being installed.

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

I'm sorry, but AFAIK, iOS has very limited background service capabilities, and
it seems to be doing just fine. That is the model we should be looking at, not
the Android model.

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

I completely agree. But I'm not willing to have apps running in the background
to do so.

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

How would you write those apps for iOS?

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

The problem is once you allow the torrent app to do that, you then allow every
other app, including the flashlight apps to do it too.

Marc.