W3C home > Mailing lists > Public > www-tag@w3.org > January 2010

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

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Tue, 12 Jan 2010 08:30:43 -0500
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <5C6FD350-92E1-47BC-945A-92C862E4F1AC@nokia.com>
To: "ext noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
Noah

Thanks, speaking not as chair, this is along the same lines as what  
I've been thinking.  The difficulty will be in the details.

regards, Frederick

Frederick Hirsch
Nokia



On Jan 11, 2010, at 9:31 PM, ext noah_mendelsohn@us.ibm.com wrote:

> Frederick Hirsch writes:
>
>> No ,from my personal understanding I think we are asking something
>> broader, which is, how to enable privacy in the context of APIs
>> without creating unnecessary complexity or dependencies.
>
> (I'm responding as an individual TAG member -- not speaking for the  
> rest
> of the TAG)
>
> One approach that intrigues me would be to do something along the  
> lines
> of:
>
> * Ensure that the API has some reasonably general extensibility  
> mechanism,
> including the ability for code using the extensions to dynamically
> discover which ones are there, and whether use of any are required  
> (in the
> common case of Javascript APIs, I suspect that most of what you need  
> is
> inherent in the language itself.)  User agents would be expected to
> enforce the use of mechanisms that are marked as required.
>
> * Identify reasonably forseeable use cases involving privacy, and  
> show how
> the extension mechanism could be used to implement >and require the  
> use
> of< the necessary controls where necessary.
>
> * As appropriate, provide mandatory baseline privacy controls if  
> deemed
> necessary for likely early uses of the APIs.  To some extent, the  
> debate
> for a particular API will be "what should be the mandatory baseline
> privacy controls, and should it be possible to replace these as
> requirements change?"
>
> If done right, I think you could create APIs in which both mandatory  
> and
> optional privacy policies could be implemented as "mix-ins", but in  
> which
> it innovation relating to the particular privacy mechanisms could be
> somewhat decoupled from evolution of the specifications for the rest  
> of
> the API.
>
> Some of this is intuition and I understand that details are vague;  I
> don't have an existence proof that this approach is workable, but it  
> seems
> to me that it's an appealing direction to explore.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Frederick Hirsch <frederick.hirsch@nokia.com>
> Sent by: www-tag-request@w3.org
> 01/08/2010 03:13 PM
>
>        To:     "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
>        cc:     "Hirsch Frederick (Nokia-CIC/Boston)"
> <Frederick.Hirsch@nokia.com>, "www-tag@w3.org" <www-tag@w3.org>, W3C
> Device APIs and Policy WG <public-device-apis@w3.org>, (bcc: Noah
> Mendelsohn/Cambridge/IBM)
>        Subject:        Re: W3C TAG position on policy mechanisms for  
> Web
> APIs and Services
>
>
> Hi Ashok
>
> No ,from my personal understanding I think we are asking something
> broader, which is, how to enable privacy in the context of APIs
> without creating unnecessary complexity or dependencies. I think this
> is a more difficult problem since it is harder if we do not assume a
> pervasive privacy infrastructure. Can we privacy-enable APIs without
> assuming a specific infrastructure? Put another way, what are the
> various approaches?
> One might be treating APIs as RESTful APIs [1] another might be to
> require passing of information structures like Geopriv in the API
> calls, to give only two examples. What are the implications of
> various  approaches - does the TAG have comment?
>
> We are also seeking feedback on the Geolocation decision noted in my
> message.
>
> I'd be interested in learning more about what you think the general
> approach might be, and how trusted agents fit into that, but that was
> not the specific question.
>
> Thanks
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html
>
> On Jan 6, 2010, at 1:58 PM, ext ashok malhotra wrote:
>
>> Hi Frederick:
>> I think you are saying that users want a trusted agent to enforce
>> privacy.  Where is that trusted agent?
>> Is this correct?
>> All the best, Ashok
>>
>>
>> Frederick Hirsch wrote:
>>> Dear Noah and TAG members:
>>>
>>> The Device APIs and Policy Working Group understands the importance
>>> of  privacy. The DAP 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 DAP 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 DAP 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
>>>
>>> Note, This should fulfill DAP ACTION-73 (for Tracker's benefit)
>>>
>>> On Dec 4, 2009, at 10:33 AM, ext noah_mendelsohn@us.ibm.com wrote:
>>>
>>>> To: The W3C Device APIs and Policy Working Group
>>>>
>>>> The W3C Policy Languages Interest Group maintains a Wiki [1] which
>>>> contains real world cases where personal information has been
>>>> compromised
>>>> due to inadequate policy or poor/nonexistent enforcement. One of
>>>> these
>>>> cases describes how Virgin Mobile used photos that it found on
>>>> Flickr
>>>> in a
>>>> national advertising program.  The photos appeared on large
>>>> billboards,
>>>> much to the surprise of the owner and the subject.
>>>>
>>>> In the public mind, issues related to the management and
>>>> protection of
>>>> user information in Web Applications, Device access over the Web  
>>>> and
>>>> Services provided over the Web loom large and must be addressed.
>>>> The
>>>> TAG,
>>>> therefore, urges working groups working in these areas to include  
>>>> in
>>>> their
>>>> architectures the ability to communicate policy information so that
>>>> it can
>>>> be used to determine correct access to and retention of user data
>>>> and
>>>> resources. Addressing these concerns should be a requirement,
>>>> although the
>>>> details of how they are addressed may vary by application. For
>>>> example, a
>>>> working group might provide mechanisms for including policy
>>>> information in
>>>> API calls in a flexible manner, perhaps by using some more
>>>> generalized
>>>> extensibility mechanism.
>>>>
>>>> We note that there has been some dialog in this area.  In
>>>> particular,
>>>> the
>>>> IETF GeoPriv Working Group has requested [2] the W3C Geolocation
>>>> Working
>>>> Group to add additional support for user privacy. There is a
>>>> discussion
>>>> thread on this subject on the Geolocation Mailing list [3].
>>>>
>>>> Thank you very much.
>>>>
>>>> Noah Mendelsohn
>>>> For the W3C Technical Architecture Group
>>>>
>>>> [1] http://www.w3.org/Policy/pling/wiki/InterestingCases
>>>> [2]
>>>>
> http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0006.html
>>>> [3]
>>>>
> http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/thread.html#msg98
>
>>>>
>>>>
>>>>
>>>> P.S. Tracker:  this should fulfill TAG ACTION-318
>>>>
>>>> --------------------------------------
>>>> Noah Mendelsohn
>>>> IBM Corporation
>>>> One Rogers Street
>>>> Cambridge, MA 02142
>>>> 1-617-693-4036
>>>> --------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
Received on Tuesday, 12 January 2010 13:31:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:19 GMT