ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Wed, 2014-06-25 at 13:23 -0400, Marc Deslauriers wrote:
> So I gather you have the same problem on iOS, as much of the same limitations
> exist there?

I don't now, nor have I ever, owned any iOS devices. Nor have I
developed any apps for them. I do know that the types of apps I want to
write, do exist on iOS though, so clearly there must be some way to run
background services on iOS, even if it simply means that an app with
full UI is running in the background.

For example: http://www.innovatemotorsports.com/products/ot2.php

This app supports logging and performance metrics. Surely they don't
expect the user to tap the screen every 5 seconds to keep it alive,
while also trying to drive a car at its peak performance on a race
track.

So how is iOS enabling apps with requirements for background processing
like this?


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

Apple also only support a very limited set of hardware, and have a high
rejection rate, even for legitimate apps. They have a stricter set of
rules about how an app is submitted to the store, and not simply a
stricter set of rules for how the app is run on the device. The
combination of the two certainly leads to less malware, and I'm not
proposing that we simply throw confinement out the window. But we need a
reasonable balance, which doesn't require developers to deal with
partner agreements and building a system service that ends up in the
images.

Like the balance we're trying to achieve with submission approvals, I
think we need an appropriate balance for background services.

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

I don't think it's more important. I think they are equally important.
And I think the user should be allowed to make a decision on how
important they think it is. The main issue should be how we expose that
decision to the user.

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

There is no designed way of displaying that information to the user
currently. It however, is totally possible for any information about
those permissions in the click package, to be indexed by the store, and
it would be possible for the click scope to show that information, in
the app details, and in a confirmation page when the user clicks
Install.

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

> How would you write those apps for iOS?

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20

Apps can have long-running background tasks for certain things, on iOS.
I suppose their manual validation of submissions to the store checks
against their list of allowed things for this case. I'm not sure how we
could automate such checks though, but it could be possible for us to
run an app inside a confined sandbox with some virtual bluetooth things
exposed to the sandbox, to see what the app is doing, and flag for
manual review if it tries to do something outside that scope. Or we
could just flag for manual review any app which provides a background
service.

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

Well a torrent app falls under the supported case of long-running
background tasks on iOS, so it's certainly feasible and acceptable to
write a torrent app on iOS.