- From: Alissa Cooper <acooper@cdt.org>
- Date: Wed, 7 Apr 2010 09:30:47 -0400
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Hi Frederick, A few responses inline... On Apr 7, 2010, at 8:37 AM, Frederick Hirsch wrote: > Alissa > > Thanks for this revision, to summarize to see if I understand: > > 1. Removed categorization of requirements since you suggest this > document should be focused on what impacts API directly, as opposed > to the content of policy itself or user defined policy. Thus this is > now roughly limited to UA-Functionality. This gives the document and > work more focus, which I think is good. > Right. As noted in the last issue in section 1, I do think that we need a high-level discussion *somewhere* about how all the various privacy pieces fit together. This doc may be the place, or it may be elsewhere. > 2. removed use cases due to the change in focus. However, I wonder > if this is always appropriate, since for example the minimization > use case demonstrates a case where the API should be able to return > minimal data, etc. > Agreed. I don't think it will be hard to put the appropriate use cases back in once the requirements are a little more settled. I was just worried about confusing things by leaving in use cases that were focused on user/app policies. > 3. Changed the table from "information with data" to "user > expectations", which does not imply a solution, appropriate to > requirements. > Changed "sharing" to "disclosure" (same intent?) I forgot to mention the "sharing" vs. "disclosure" change in my email. The intent is the same, I just think sharing is a little less confusing (I think "disclosure" can sound legalistic and has a different meaning when it's used as a noun versus when it's used as a verb). > What next steps are needed for APIs for notice, consent, control and > access? Will notice be handled by the commons privacy license idea? Perhaps we can discuss this on the call today. If we take the Contacts API as an example, in section 3.1 it currently has normative requirements on UAs regarding notice ("must acquire permission through a user interface"), consent ("must not create, retrieve, update or delete contact information to Web sites without the express permission of the user"), and control ("permissions that are acquired through the user interface . . . must be revocable and a user agent must respect revoked permissions"). One question is whether we want to require all of the APIs to do those sorts of things. > > Maybe we should capture what is removed in a new User Policy > Preferences document now, so it isn't forgotten? Good idea. > > I updated the editors draft with this revision, see http://dev.w3.org/2009/dap/privacy-reqs/ > Thanks. Alissa > Previous versions are visible in the CS history > > http://dev.w3.org/cvsweb/2009/dap/privacy-reqs/Overview.html > > (previous version at http://dev.w3.org/cvsweb/~checkout~/2009/dap/ > privacy-reqs/Overview.html?rev=1.8&content-type=text/html; > %20charset=iso-8859-1 ) > > > Frederick Hirsch > Nokia > > > > On Apr 6, 2010, at 5:43 PM, ext Alissa Cooper wrote: > >> I've tried to streamline the privacy requirements document per >> ACTION-153 (I think this also closes out ACTION-112 that I took at >> the >> F2F). The text attached below reflects a number of changes: >> >> -- I removed the use cases, since they were about user and >> application policies, not about API requirements. I think we will >> be able to use >> them later when we get to defining how the user expectations/ >> preferences/policies will work. I also removed the discussions under >> the individual privacy elements that were about policies rather than >> API requirements. >> >> -- I re-ordered the remainder of the text so that it's more clear >> which pieces of the privacy work are going where. >> >> -- I changed the table that shows the breakdown of how we're >> dealing with the various elements of privacy, and I added in the >> ones that >> were missing from the table. >> >> I tried not to alter much of the text otherwise. John and I >> definitely >> have some more substantive issues with some of the language in this >> doc, but for the purposes of streamlining I mostly left the text as >> it >> was. He and I will send comments to the list about our outstanding >> issues (before or after FPWD, as appropriate). >> >> I know this is a little late for the Wednesday call, but if it's >> possible for one of the editors to post the text below, it will be a >> lot easier to read (I don't have editorial access). >> >> Cheers >> Alissa >> >> >> <privacy-reqs-01.html><ATT00001..txt> > > >
Received on Wednesday, 7 April 2010 13:31:25 UTC