- From: John Morris <jmorris@cdt.org>
- Date: Wed, 29 Oct 2008 00:02:02 -0400
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: "Ian Hickson" <ian@hixie.ch>, "public-geolocation" <public-geolocation@w3.org>
Martin, thanks, you have correctly clarified my language. Ian, my first and foremost concerns are the browser makers. They obviously are in the best position to ensure that privacy is protected within their eco-systems. But they ALSO have the ability (say, by adopting Geopriv) to force downstream site and app developers to consider and (we hope) protect privacy. It is precisely because many web developers are, as you say, actively hostile to privacy that it is critical to force them to confront and grapple with privacy. The browser makers will of course not be able to force downstream developers to in fact play nice on privacy, but if the user's "expectation of privacy" is made clear to the downstream developer, then the developer's local law may will force them to honor those expectations. If this world were made up only of browser makers who we can trust to play nice, then we might not need Geopriv. But it is not, so to my view something like Geopriv is critical. And equally importantly, if we simply have to trust the API-browser makers to play nice, then we are giving up on any chance that the downstream developers will play nice. This means that as a user of a particular browser, I will hesitate to give permission for my location to be given to anyone, because I have zero assurance that the ultimate recipient of my location info will not abuse it. But instead, if I know that the ultimate recipient will receive my clear privacy rules with my location -- and the local laws require that those rules be followed -- then I would be more willing to let my location be distributed. At the end of the day, I believe that more people will use a browser's location service is they have some reason to hope that their privacy would be honored downstream. To answer a specific question you raised, I am not familiar with the iPhone OS stack, but it if is similar to the spec in this WG, then yes, I certainly think that it is insecure. But the fact that Apple may not be behaving appropriately on privacy is not a reason that everyone else should follow suit. John At 9:17 PM -0500 10/28/08, Thomson, Martin wrote: >Hi Ian, > >I think that you might have misinterpreted John's use of the word >"developer". In the web context, it's so often used to refer to >site developers that you tend to forget that "developer" also >applies to folks like Doug, who build the API in browsers. I'll let >John correct me, but developer in this context refers to both. > >Cheers, >Martin > >> -----Original Message----- >> From: Ian Hickson [mailto:ian@hixie.ch] >> Sent: Wednesday, 29 October 2008 12:08 PM >> To: John Morris >> Cc: Doug Turner; Thomson, Martin; Jon Ferraiolo; Andrei Popescu; >> public-geolocation >> Subject: Re: wording for the privacy section >> >> On Tue, 28 Oct 2008, John Morris wrote: >> > >> > According to the charter, the objective of this WG is "to define a >> > SECURE AND PRIVACY-SENSITIVE INTERFACE for using client-side location >> > information in location-aware Web applications." To simply assert in >> a >> > spec that any implementation MUST take privacy into account while >> being >> > silent on HOW to do so accomplishes nothing, and will do absolutely >> > nothing to change the norm - which is to wholly ignore privacy. >> >> I think what we need is an API that is the JS equivalent of the API in >> the >> iPhone OS stack, which is privacy-sensitive in exactly the same opaque >> way. Do you think that the iPhone implementation is insecure? >> >> >> > [...] the output of [the geopriv] group is a standard that seeks to >> > FORCE developers to deal directly with privacy (or to consciously >> choose >> > to ignore privacy by ignoring an essential element of the IETF >> > standard). >> >> Having the developers have to worry about privacy is a lost cause, >> IMHO, >> especially in the Web space where the developers are actively hostile > > in >> many cases. Much better to put this in the hands of the user, under the >> control of the user agent. The UA is trusted software already, and >> there >> are very few UA implementors relative to the number of site >> implementors, >> so it is far easier to get it right at that level. >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. >> fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ >> ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`- >> .;.' > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2]
Received on Wednesday, 29 October 2008 04:02:48 UTC