W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Re: W3C TAG position on policy mechanisms for Web APIs and Services

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 16 Dec 2009 18:25:08 +0100
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-ID: <1260984308.2939.2086.camel@localhost>
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 Wednesday, 16 December 2009 17:25:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT