ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 06/12/2014 03:44 PM, Jamie Strandboge wrote:
> 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?
> 
Ted responded in irc and the answer to this is essentially "yes".

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

Ted responded in irc and mentioned the spec is temporarily in:
https://docs.google.com/a/canonical.com/document/d/1Suig1eQ4Ldpup7ssabyZ3lEjTACMlCv90iHyDwr26Hs/edit

Apparently a proper discussion was planned for very soon and I'm told it will
only be in this google doc for long enough to get it in shape to add to the wiki.

Thanks Ted for answering my questions and clarifying things for me-- there are
still some open questions but everything seems quite reasonable. Let me/the
security team know when you are ready to move forward on the security and click
manifest bits.

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

Attachment: signature.asc
Description: OpenPGP digital signature