Re: APIs for non-interactive contexts or without explicit user consent

In the geolocation wg, we discussed this issue.  For example, a voip phone might need to use the geolocation api to disclose location information to emergency services.

We ended up with this text:
http://dev.w3.org/geo/api/spec-source.html#privacy_for_uas

Doug Turner

On Dec 2, 2009, at 8:44 AM, Dominique Hazael-Massieux wrote:

> Hi,
> 
> During the call today, and the in the follow-up discussions that Bryan
> started [1], we touched again on the need for (some of) our APIs to also
> be usable in a context where there is no user to give consent at usage
> time, or where user consent has been granted in out-of-bands ways —
> let’s call this the “installable application” context since browsers
> vendors have made it pretty clear they’re not interested in catering for
> these use cases in the short term (although arguably, permission
> persistence is a type of out-of-band permission grants).
> 
> I think there are several aspects to consider regarding the design of
> APIs for installable applications:
> • first, do we want them? I think we have heard many participants of the
> group want them; the main dissension on that point has been to say that
> designing APIs for the installable application context must not make
> APIs for the browser context less secure
> 
> • secondly, can we address both context within a single API? it seems
> like the jury is still out on that one; it might “just” be that the
> hanging-off point of the APIs is sufficient to deal with one context or
> the other, but this needs to be looked at on an API-per-API basis; I
> think it would certainly be a more satisfying result if we can have a
> single API, but we probably should remain open on that point; a possibly
> important point is that in a context where we don’t need user consent,
> the requirement for an asynchronous API might be going away — there are
> obviously other aspects to that (e.g. length of time needed to get back
> a response).
> 
> • thirdly, do we want them on the same schedule as browsers APIs? I
> don’t think there has been much discussion on that point; the scheduling
> question has really two aspects itself:
>  ‣ whether a single API can fit the two contexts (which essentially
> affects the schedule to Last Call)
>  ‣ whether we can get implementations of the APIs in the two contexts
> in the same schedule (which will affect the Candidate Recommendation
> length)
> 
> I’m send these thoughts in the hope we can avoid re-hashing these
> discussions again and again — feedback and additions to this analysis
> are very welcome.
> 
> Dom
> 
> 1.
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0067.html
> 
> 
>

Received on Wednesday, 2 December 2009 18:02:07 UTC