- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Wed, 29 Oct 2008 14:56:20 -0700
- To: John Morris <jmorris@cdt.org>
- Cc: Ian Hickson <ian@hixie.ch>, public-geolocation <public-geolocation@w3.org>, public-geolocation-request@w3.org
- Message-ID: <OF96062F71.2B8BA94D-ON882574F1.0076B36E-882574F1.007883C3@us.ibm.com>
I am one of those who thinks that the W3C geolocation spec should leave security and privacy concerns to the user agent. I skimmed through geopriv [1] [2] and I have three reactions: (1) The W3C should steer clear of attempting to define security and privacy policy. Let other parts of the industry figure this out, such as IETF, OMTP or OMA. The W3C should focus exclusively on defining good APIs, which is a hard enough task. However, the W3C geolocation spec should say that user agents must or should include suitable facilities for security and privacy protection, and it makes sense to include an informative reference to geopriv. (2) The OMTP is working on a similar policy definition mechanism, but it is more general in scope in that it addresses all sorts of device APIs (address book, camera, phone dialer, etc). Last I looked, the OMTP was building upon the security architecture found in OASIS's XACML technology. The mobile phone industry needs to embrace one or the other, or maybe something else, but clearly we need unification in terms of how to express security policies. (3) Regarding geopriv, in all honesty, I am scratching my head. I appreciate the effort to protect user policy, but from a practical perspective, who creates the policy documents? The end user? I am hugely skeptical if mobile phone users would create policy documents or run software that would help them create policy documents. Users just want to run applications and occasionally will tolerate and pay attention to any security prompts that might come their way. Often, if you want a security system that will catch on with the industry, it is usually the case that you need extreme simplicity (i.e., less is more). Maybe I am misunderstanding geopriv, but it looks like overkill. Maybe I am scared off by the first example in the spec, which appears to show how you can allow your location to be exposed if you are in either Bavaria, Munich, Perlach or Otto-Hahn-Ring. Jon [1] http://www.ietf.org/html.charters/geopriv-charter.html [2] http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-17.txt John Morris <jmorris@cdt.org> Sent by: To public-geolocatio Ian Hickson <ian@hixie.ch> n-request@w3.org cc public-geolocation <public-geolocation@w3.org> 10/29/2008 02:30 Subject PM RE: wording for the privacy section 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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic20841.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 29 October 2008 21:57:14 UTC