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 Friday, 8 January 2010 20:14:24 UTC