Re: Alarm API Feedback

On Thu, Jan 17, 2013 at 5:57 PM, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
>>> c) Section 4: "The returned ID is unique (within the application origin)
>>> and can be used to specify and remove the added alarm."  The term
>>> 'application origin' does not clarify whether the ID is unique for each
>>> instance of the application, or it is unique with respect to all instances
>>> of an application that are open at any given instant in time on the same
>>> device.
>
>> Several instances of the same application would be within the same
>> security origin. Therefore, the ID would be unique with respect to all
>> instances of an application.
>
> In practice, the idea is that all instances of the same application share
> the same alarms. Therefore, I do not think there is a need to distinguish
> between different instances of the same application. Is there?
>
>
>
> I think my original phrasing of the question was too narrow – I was
> interested in general in the uniqueness of Alarm ID’s regardless of security
> origin.   I think there are dependencies on how applications on the target
> platform exchange data.  If the Alarm ID’s are unique only with respect to
> the same security origin, then what occurs if Alarm ID’s are exchanged
> between two applications of different security origins?
>
>
>
> It is conceivable that Alarms defined in one security origin should not be
> accessible in other security origins to get around this problem (as is
> stated in the text currently “Alarms are application specific, so there is
> no way to see the alarms scheduled by other applications nor to modify
> them”), but this may prevent target use cases.  As an example, think of one
> application being a downloadable calendar app, and another application being
> a turn-by-turn nav app.  It could be that the nav app moves into the
> foreground upon a alarm event defined by the calendar app and provides a
> route to a destination specified in Alarm.data defined by the calendar app.

Supporting that feature set requires much larger changes to the API
than anything that IDs can provide.

It would require that the nav app can hand some sort of "start URL" to
the calendar app. And then add some argument to alarm.add so that the
calendar app can describe that the alarm should fire to the nav app
rather than the calendar app.

A simpler solution would be to decouple the starting of the nav app
from the alarm. So we would have one API for triggering an alarm and
another API for opening an app.

Defining that the ids from the alarms have to be globally unique is a
non-trivial burden on the API implementation since it means that you
have to take care to not leak information about the set of generated
IDs for one app affects the set of IDs generated for another app. So
you couldn't for example use a simple global counter as ID generator.
Or a pseudo-random-number generator like the one backing Math.random()
in Javascript.

Likely the safest implementation would be to have a cryptographically
strong random number generator, which doesn't seem like a burden we
should put upon implementations unless we have strong use cases.

/ Jonas

Received on Friday, 18 January 2013 08:38:44 UTC