W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

APIs for non-interactive contexts or without explicit user consent

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 02 Dec 2009 17:44:47 +0100
To: public-device-apis <public-device-apis@w3.org>
Message-ID: <1259772287.18585.1527.camel@localhost>
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 16:45:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT