W3C home > Mailing lists > Public > public-geolocation@w3.org > October 2008

RE: wording for the privacy section

From: John Morris <jmorris@cdt.org>
Date: Wed, 29 Oct 2008 17:30:37 -0400
Message-Id: <a06240822c52e801b8ddb@[10.0.1.31]>
To: Ian Hickson <ian@hixie.ch>
Cc: public-geolocation <public-geolocation@w3.org>

Ian, see comment below,

At 5:28 AM +0000 10/29/08, Ian Hickson wrote:
>Any scheme based on the idea that anything we can do can force Web authors
>to consider anything at all is doomed to fail. Web authors care about what
>they want to care about. There's nothing we can do about that.

Any approach that starts with the premise that "there is nothing we 
can do about that" is guaranteed to wholly fail to promote privacy 
protection by web authors.  In contrast, any approach that squarely 
confronts web developers with clear privacy expectations will lead 
some to focus on privacy, even if -- as you correctly note -- some 
will not.  Moreover, if the W3C says to web developers, "you must 
appropriately handle privacy rules in order to claim compliance with 
our standard," then I guarantee that at least some developers will 
address privacy when they otherwise would not have done so.

So, doing nothing in this regard ensures that privacy will not be 
considered.  Doing something, in contrast, will increase the 
protection of privacy.  Will the "something" provide perfect 
protection -- of course not.  But it will improve a generally bad 
situation.

>Expecting the law to uphold technical specifications is IMHO highly
>inappropriate. Using technical specifications to uphold morals is equally
>inappropriate. (P3P was an example of attempting both of those, as far as
>I can tell. I think we should learn from those mistakes.)

I am not expecting the law to enforce any technical specification, or 
any moral.  Instead, I am expecting the law to enforce an 
"expectation of privacy," which is something that the law does all 
the time.  By urging the adoption of Geopriv, I am simply saying that 
the W3C standard should require that the "expectation of privacy" be 
conveyed along with the location info.

>Just out of interest, could you show what you think the API should look
>like to handle Geopriv, along with all on-the-wire examples? (Please be
>thorough, i.e. don't say "and then you send a geopriv XML packet" or
>whatever, please actually show the entirety of all data that is to be sent
>in all directions so that we can have a full view of what it is you are
>proposing.) It may be that our disagreement is just based on my ignorance
>of what you are actually considering.

I do not claim to be an expert in how best to implement Geopriv (I 
spend far more of my time personally working on policy issues rather 
than engineering issues).  That is EXACTLY why I am urging this group 
as a very early task to seek direct input from the designers of 
Geopriv.

But I take your request as asking more for a proof of concept.  So I 
have asked my colleague Alissa to spend an hour putting together a 
mock up of how a simple (and privacy protecting) implentation of 
Geopriv could be implemented within the W3C work you are doing.  To 
be clear, although an engineer, Alissa first looked at the Geopriv 
just a couple of weeks ago, and so she also does not claim to be well 
positioned to design the "best" implementation of Geopriv.  But what 
she will circulate on the list shortly will, I think, indicate that 
this WG could fairly easily implement Geopriv.  I am sure that all of 
the folks in this WG, working with the experts in Geopriv, will be 
able to come up with a better and more robust Geopriv implementation.

All of which leads me to the question back to you -- and to the other 
list members who chimed in that the WG should deem privacy out of 
scope:  Why are you so unwilling to explore the possibility of using 
Geopriv, and why are you so unwilling to try to improve the state of 
privacy -- especially when the charter of this group mandates a 
"privacy sensitive" output.

I suspect that the answer to my question is that
Received on Wednesday, 29 October 2008 21:31:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:52 UTC