ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 14-06-25 02:11 PM, Rodney Dawes wrote:
> 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?

AFAIK, iOS 4 allowed an app that was in the foreground to run in the background
for a few minutes to finish processing. I think it used to be 10 minutes, and
was reduced with iOS 7 to improve battery life.

In this case, isn't the app simply running in the foreground?

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

Hum? That is what trusted helpers do. When an app wants to access the user's
location, there is a prompt which asks for permission. That's what the trusted
prompt session work in Unity 8 is about.

 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.

That is the exact thing we're trying to avoid. Users aren't able to either
understand or make informed decision when they hit confirmation pages,
especially during installation. The Android model is broken, let's not emulate it.

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

Apps can only run in the background for a limited time, and they can use certain
APIs to get woken up regularly, but they can't run in the background save for a
few exceptions. This is why IRC apps on iOS disconnect after a few minutes, or
are designed for jailbroken devices.

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

No, it's not feasible at the moment to write a torrent app for iOS that runs in
the background without jailbreaking it.

Marc.