Re: Additional security and privacy considerations?

Dear Doug, 

I'm very sorry if my message could feel condescending. It was not 
intended to sound that way. I stand fully behind Thomas' aim to 
require user consent before sending location information and also to 
have some indication that the location API is active and sending 
information to third parties. 

In a car you also have a dashboard where important things are shown 
(e.g. oil pressure). As I said: location information is _very_ 
sensitive data. It therefore merits a place on the dashboard. And this 
assertion is not general at all IMHO. 

Concerning what I mean with hooks: As far as I understand (I'm not an 
engineer or developer), an API provides an interface for applications 
on the one side and the location data services on the other side. But 
this means that only a subset of the possible functionality of the 
location backend used is exposed to the application and vice-versa.

What I want (and what has to be confirmed with Thomas) is, that the 
API contains the necessary functionality to switch location services 
off and also to allow an application a query whether the location 
services are really off. It should provide a certain signal (yes 
that's a very generic wording) that the application can recognize that 
the location services are active and on. The presence of this signal 
would make it easy for applications to show whether location 
information is disclosed (dashboard). It should also provide an easy 
call to the API to switch the location service off.

From a programmer's perspective this may sound like a layman's 
opinion, but it contains the major requirements from a privacy 
perspective. Data protection is there to empower the user to determine 
himself which personal data he wants to disclose. If it is not easy to 
switch the location service off or if there is no awareness of it 
being on, this means a plain collision with the goals of modern 
privacy protection. As we are confronted with a _very_ sensitive area 
of data processing, the risk for disaster is also _very_ high. 

E.g. there are already requirements in Directive 2002/58EC [1] (see  
e.g. whereas 24, wheres 32&35 calls for fully informing the user) 
especially in Article 9 of the Directive. I don't mean here to require 
all what is written in the Directive. I just hint to the background 
and that we have to deal with privacy. It is better we do that here 
than leave it to possibly fragmenting regulations from all kinds of 
places.

I hope this is less condescending and general. Again sorry.

1.http://tinyurl.com/2gvjus

Best, 

Rigo


On Wednesday 13 May 2009, Doug Turner wrote:
> Rigo,
>
> Thanks for your comments and historical background.  I think your
> points are general and probably could be applied to just about
> every bit of technology we build.  We do not want to build
> technology that makes anyone feel stupid.  Although your remarks
> can feel
> condescending, as you point out, I take them with good spirit - I
> think everyone here is trying their best to create a safe secure
> way to enable geolocation on the web.
>
> I did have one question which seems you pointed out as the flaw in
> the draft.  You said that the w3c must "provide the necessary hooks
> in the API to enable such a UI".  Can you point out specifically
> where there isn't a hook in the API to do just this?  It seems to
> me that it is pretty obvious where a UA could hook into provide
> such a UI that TLR has designed.  Maybe that isn't as clear to
> someone farther away from the spec and/or browser implementations?
>
> Thanks again Rigo for your input,
>
> Doug Turner
>
> On May 13, 2009, at 2:36 AM, Rigo Wenning wrote:
> > Hi all,
> >
> > On Tuesday 12 May 2009, Thomas Roessler wrote:
> >>> Again all of this, i believe is out of scope.
> >>
> >> Nothing you said there implies that the requirements I was
> >> proposing   are unimplementable, so let's try to get back to the
> >> part that's in scope.  These  requirements are:
> >>
> >> 1. Have an signal of sorts when location information is passed
> >> to a Web application.
> >>
> >> 2. Use that indicator as a hook for some UI that enables
> >> revocation of   authorization.
> >>
> >> Again, I don't know what that indicator ought to look or sound
> >> or feel   like, and I'm not suggesting to describe the details
> >> of that kind of UI in the spec.
> >
> > Just to confirm and reinforce: Thomas and I are not saying that a
> > certain UI must be shown (the EU Commission & Parliament will
> > care to enforce it on those they can reach), but W3C under
> > scrutiny must provide the necessary hooks in the API to enable
> > such a UI. Whether Mozilla or others then chose not to make a UI
> > for it is a different discussion.
> >
> > Location is extremely sensitive data (think of crime,
> > embarrassment etc). Imagine for a second your preferred VIP being
> > caught with a partner other than the spouse thanks to this
> > location information. Imagine, this happens because the device
> > was tracking location invisibly. I would not want to get that
> > heat from that story.
> >
> > From the location of the directors of Union Bank of Switzerland
> > and the Swiss Bank Corporation and existing rumors it became
> > clear that both were accomplishing a merger to build UBS, one of
> > the world's biggest banks. Predicting such event because of
> > location information would have been worth a lot of money. They
> > were tracked in 1998 by their cellphones, but the information did
> > not leak.
> >
> > If location tracking would have been shown, people would rather
> > blame a stupid VIP than a stupid technology. We believe in
> > creativity of engineers and UI designers. They will need a hook
> > where to connect to. At least we have to provide that hook and
> > perhaps include some more insight from our discussion for
> > guidance. Paternalism is surely not the intend here, but it is
> > clear that you have to look beyond just your immediate technical
> > issues and evaluate the consequences of the technology step
> > you're about to create.
> >
> > Best,
> > Rigo Wenning
> > W3C Legal counsel & Privacy Activity Lead