ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 06/12/2014 02:08 PM, Lucio Torre wrote:
> On Thu, Jun 12, 2014 at 3:27 PM, Alejandro J. Cura <alejandro.cura@xxxxxxxxxxxxx
> <mailto:alejandro.cura@xxxxxxxxxxxxx>> wrote:
> 
> 
>     This gives the developer flexibility, yes, but it also sounds like
>     something that could affect negatively impact battery life, so surely
>     I'm missing some part of the bigger picture.
> 
> 
> It is something that could impact battery life, but i dont think we should take
> action to defend ourselves against that scenario.
> 
> 
>     Will every random app installed from the store be able to have such
>     helpers run on new notifications?
> 
> 
> Yes, that is the idea. We no longer consider helpers to be a privileged feature.
>  
> 
>     What would be the security context of the helpers? If they are able to
>     do calculations, I assume it will be the same security context of each
>     app to access their local files.
>     Will the helpers be rate-limited in cpu time or frequency of runs?
> 
> The helper will have a limited time to run and in the same security context of
> the app.
>  
> There will be a rate limit on the server side to how often you get to post
> notifications for apps, and there are many bundling strategies we can implement
> to reduce network usage, wakeups and user interruptions. But i dont think this
> is critical right now.
> 
> We will find apps that send millions of notifications per day just by looking at
> the logs, and if they are malware, we will drop their requests and get in
> contact with the store guys to let them know. 
> 
> The gained flexibility outweighs the risk of abuse, i think.
> 

I'm quite surprised by the phrasing in this response since it sound like a
significant change since we've had a very hard stance against anything that goes
counter to application lifecycle. "We no longer consider helpers to be a
privileged feature" seems to fall in to that category. You also said "It is
something that could impact battery life, but i dont think we should take action
to defend ourselves against that scenario" which, again, is counter to
application lifecycle but also is contradicted later by "The helper will have a
limited time to run".

Are you saying that this is not a wholesale change of attitude on application
lifecycle but instead simply an addendum so that a click app that specifies a
push notification client will not impact battery life because it will only be
allowed to run for a short time and will not affect security because it runs
under the application's confinement?

Is there a specification on this? How are these push clients started and
stopped? Do we expect the push notification client to need to talk to
powerd/have some lifecycle exception? How will security policy be applied? Will
Unity8 just handle all this? How will push clients declare themselves
(presumably a click user hook, but I'm curious about the specifics). We need to
discuss how the security policy is declared as well and adjust the click
reviewers tools for it to ensure there is no abuse.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature