RE: Alarm API Feedback

There certainly is a valid argument for platforms to enforce "sandboxing" of  alarms (i.e. preventing in all cases one application from accessing the alarms defined by another application).  Moreover, I also agree that there is a workaround for the use case I mentioned (if we do in fact define an API that allows one System App to open another).  But I am not sure it makes sense to define the security in the normative text of the API itself.  Wouldn't it be cleaner to define the API, and have the Security Specification specify under what conditions that alarms can be shared?   If the platform can support sharing of alarms between applications or if an application can retrieve all defined alarms based on privileges, then I don't see a reason to prevent it.

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

Based on my reading of the Geolocation API, this has to be done for watchPosition() anyways to ensure uniqueness of the returned value.  Since the SysApps WG charter does not discuss the development of a different geolocation API, there will be a burden on the platform to come up with a safe way to generate unique ID's in order to support geolocation-enabled apps.

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Friday, January 18, 2013 12:38 AM
To: Mandyam, Giridhar
Cc: Dumez, Christophe; public-sysapps@w3.org
Subject: 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 Tuesday, 22 January 2013 20:23:57 UTC