Re: Rechartering Device APIs & Policy Working Group

On Fri, Feb 4, 2011 at 5:22 PM,  <Frederick.Hirsch@nokia.com> wrote:

> Paddy
>
> How did you deal with the privacy concerns of such a generic interface?
>

Preventing or minimizing the opportunities for user
profiling/deanonymization must be built in to the returned data (i.e. don't
return anything that is privacy sensitive or too unique to profile).


>
> On Feb 4, 2011, at 10:52 AM, ext Robin Berjon wrote:
>
> > Hi Paddy,
> >
> > On Feb 4, 2011, at 16:16 , Paddy Byers wrote:
> >> In BONDI (1.5, which never really become public) we formulated a generic
> sensor API, which dealt in a generic way with discovering available sensors
> of arbitrary type with sensor-specific description of capabilities, defining
> sensor-specific value types, reading sensor values, watching sensor values
> with a generic way to specify triggers or thresholds, etc. This seemed to be
> the minimum that you would want from a generic API. There was no way in the
> API to "configure" a sensor, but you could get a "parameterised" instance
> (ie specify some parameters when you get the sensor instance) and specify
> thresholds when watching for sensor changes.
> >>
> >> If it is of interest to the group I can dust it off and circulate it.
> >
> > Yes, I wanted to look for it (as well as the DLNA API that was there too)
> but all I can see to find from the BONDI web site are 404 pages these days.
> >
> > I don't know if the Membership will decide to add these to the charter,
> but it's certainly worth having something concrete to look at so that people
> can make their minds up. Comparison with a Web Introducer approach would be
> interesting (for both sensors and DLNA — and for DLNA I think there's also
> an OIPF API that might be worth looking, though to be honest DLNA/UPnP
> scares me, there are hardly any good reasons to use SOAP anywhere, but with
> embedded devices it seems profoundly wrong).
>

We should probably start by using the standard web events model for
well-defined sensors ala the Orientation Events spec:

http://dev.w3.org/geo/api/spec-source-orientation.html

No need to kick off with any more than that initially. Extensibility,
discoverabilty and soapiness ( ..or, in agreement with Robin, lack of it)
could come later. FWIW, extensibility and discoverability could be rolled in
to the events model itself also (e.g. an event to indicate the
connection/disconnection of sensors themselves). Capability could be
identified initially via something such as navigator.sensors =
['temperature', 'orientation'/*, ... */].

We're (Opera) actively developing to the Orientation Events draft. It would
make sense to reuse such a model for other sensors (or a more generic
onsensorstart/onsensorend approach presented in the para above.

- Rich


> >
> > --
> > Robin Berjon - http://berjon.com/
> >
> >
> >
> >
>
>
>