ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Jun 12, 2014 at 10:44 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> 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.
>>
>

To give a bit of background here & to motivate the problem:

Whenever a push message arrives on the device, the push notification
daemon has to decide how to handle it, with "handling" roughly
referring to:

* Make sure that the receiver of the notification, i.e., an app, will
be able to consume the message (the app might not be running)
* If appropriate, inform the user that something happened and give a
visual cue corresponding to the incoming message. Here, some
constraints apply:

  * A push message contains an app-specific payload and fields for
identifying the receiver (the application).
  * The type of visual cue depends on user preferences (the so-called
"distraction knob") and the message payload.

Our system offers multiple types of visual cues:

  * Notifications: Distracting to the user and very invasive
  * Messaging menu: Reserved for human to human interaction, non-invasive
  * Icon emblems with counts: Non-invasive

>From the push notification service perspective, the incoming message
is not descriptive enough to automatically map the incoming message to
one of the visual cues. For that to happen, we need assistance from
the app to translate between the message's payload and the declarative
language of the visual cue endpoints. This is where the helper comes
into play. Once the translation has happened (under tight resource
constraints), the push notification service decides where to put the
visual cue according to user preferences.

>From my perspective, we are not violating our lifecycle model here.
First, we do not startup the entire app. Second, we put a hard limit
on the helper execution, both in terms of system resources and in
terms of execution time.

The alternative approach would be to encode all endpoint-specific data
(think: notification title, subtitle, icon, sound, haptic feedback)
into the push messages. While technically doable, we would end up with
quite a bad signal/noise-ratio per message, where signal refers to the
app-specific payload and noise refers to any system-specific field.

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

You should have a meeting invite in your calendar.

Thanks,

  Thomas

> --
> Jamie Strandboge                 http://www.ubuntu.com/
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>