- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Thu, 31 Dec 2009 12:26:38 -0500
- To: ext Dominique Hazael-Massieux <dom@w3.org>
- Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Thanks Dom. I propose the following revision, with comparison to your proposal following: --- Dear TAG members: The Device APIs and Policy Working Group understands the importance of privacy. The WG would like to ensure that privacy concerns are respected with the additional data that Web developers may obtain using DAP APIs. At the same time we recognize the importance of simplicity, ease of adoption, and the limit of the WG scope to API and policy development (and not the creation of an infrastructure). The WG is only beginning to consider the privacy topic and would appreciate all help it can obtain from anyone that can help us achieve a good practical result in a reasonable time. Our initial starting point will be to examine the decision of the Geolocation Working Group in more detail. This decision was *not* to include privacy rules as part of the API. That decision is documented with the following Geolocation WG resolution: " If the proposal [to include policy rules as part of the API] was adopted, the browsers would end up showing the user an interface that appears to be a user-agent enforced privacy preference panel. However, since the privacy information is provided by the website, there is no way for the user-agent to ensure that the claims made by the website are actually true. This could result in the users being mislead by a user-agent prompt. This would break the separation between the user-agent UI (which users trust) and the site content (which users don't necessarily trust) and would therefore undermine the user's trust in the user-agent, with extremely severe consequences for Web security." http://www.w3.org/2008/geolocation/track/issues/10 While we intend to look at each of the assertions made in that resolution and see if and how they would apply to our own set of APIs, we would very much welcome the TAG’s perspective on that resolution. We would also appreciate TAG input on how the WG can address privacy concerns while limiting the scope to the API and policy aspects of its charter, and not presuming or creating a surrounding infrastructure. Thank you. Regards, On behalf of the DAP WG Frederick Hirsch and Robin Berjon, co-Chairs --- Revision details: > The Device APIs and Policy Working Group is interested in > ensuring that the additional data to which Web developers get > access through the APIs it is developing are made available > while respecting the user’s privacy. The Device APIs and Policy Working Group understands the importance of privacy. The WG would like to ensure that privacy concerns are respected with the additional data that Web developers may obtain using DAP APIs. At the same time we recognize the importance of simplicity, ease of adoption, and the limit of the WG scope to API development (and not the creation of an infrastructure). > > The group has only brushed on that topic so far, and our main > starting point will be to dive deeper into the decision of the > Geolocation Working Group *not* to include privacy rules as > part > of the API. The WG is only beginning to consider the privacy topic and would appreciate all help it can obtain from anyone that can help us achieve a good practical result in a reasonable time. Our initial starting point will be to examine the decision of the Geolocation Working Group in more detail. This decision was *not* to include privacy rules as part of the API. > That decision is documented with the following > resolution: That decision is documented with the following Geolocation WG resolution: > If the proposal [to include policy rules as part of the > API] was adopted, the browsers would end up showing the > user an interface that appears to be a user-agent > enforced privacy preference panel. > However, since the privacy information is provided by > the website, there is no way for the user-agent to > ensure that the claims made by the website are actually > true. > This could result in the users being mislead by a > user-agent prompt. This would break the separation > between the user-agent UI (which users trust) and the > site content (which users don't necessarily trust) and > would therefore undermine the user's trust in the > user-agent, with extremely severe consequences for Web > security. > http://www.w3.org/2008/geolocation/track/issues/10 > (include as written) > While we intend to look at each of the assertions made in that > resolution and see if and how they would apply to our own set > of > APIs, we would very much welcome the TAG’s perspective on that > resolution. (include as written, adding:) We would also appreciate TAG input on how the WG can address privacy concerns while limiting the scope to the API and policy aspects of its charter, and not presuming or creating a surrounding infrastructure. --- regards, Frederick Frederick Hirsch, Nokia Co-Chair, W3C DAP Working Group On Dec 16, 2009, at 12:25 PM, ext Dominique Hazael-Massieux wrote: > Le jeudi 10 décembre 2009 à 16:07 -0500, Frederick Hirsch a écrit : >> Unless I'm mistaken, the Geolocation WG elected not to directly >> address policy in the APIs, different from what is suggested by the >> TAG or IETF Geopriv WG. If I remember, reasons included that it >> would be inappropriate for a browser to present statements that it >> cannot enforce, that web site policies should address the concern and >> that conveying privacy policy information (e.g. intent/restrictions >> for reuse/redistribution etc) add complexity. The counter argument >> is >> that conveying privacy policy intent is important. If there are >> additional arguments, perhaps a short summary would be useful. > > As I quoted during the meeting today, the actual resolution of the > relevant issue in the Geolocation Working Group (annotated in square > brackets by myself for clarification) reads as: > if the proposal [to include policy rules as part of the API] > was > adopted, the browsers would end up showing the user an > interface > that appears to be a user-agent enforced privacy preference > panel. > However, since the privacy information is provided by the > website, there is no way for the user-agent to ensure that the > claims made by the website are actually true. > This could result in the users being mislead by a user-agent > prompt. This would break the separation between the user-agent > UI (which users trust) and the site content (which users don't > necessarily trust) and would therefore undermine the user's > trust in the user-agent, with extremely severe consequences for > Web security. > http://www.w3.org/2008/geolocation/track/issues/10 > > I think it would be useful to get the TAG perspective on that > perspective. To that end, here is a proposed piece of the answer to > the > TAG: > The Device APIs and Policy Working Group is interested in > ensuring that the additional data to which Web developers get > access through the APIs it is developing are made available > while respecting the user’s privacy. > > The group has only brushed on that topic so far, and our main > starting point will be to dive deeper into the decision of the > Geolocation Working Group *not* to include privacy rules as > part > of the API. That decision is documented with the following > resolution: > If the proposal [to include policy rules as part of the > API] was adopted, the browsers would end up showing the > user an interface that appears to be a user-agent > enforced privacy preference panel. > However, since the privacy information is provided by > the website, there is no way for the user-agent to > ensure that the claims made by the website are actually > true. > This could result in the users being mislead by a > user-agent prompt. This would break the separation > between the user-agent UI (which users trust) and the > site content (which users don't necessarily trust) and > would therefore undermine the user's trust in the > user-agent, with extremely severe consequences for Web > security. > http://www.w3.org/2008/geolocation/track/issues/10 > > While we intend to look at each of the assertions made in that > resolution and see if and how they would apply to our own set > of > APIs, we would very much welcome the TAG’s perspective on that > resolution. > > Dom (per ACTION-76) >
Received on Thursday, 31 December 2009 17:27:37 UTC