W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

Re: ACTION 105: Privacy Rulesets

From: Alissa Cooper <acooper@cdt.org>
Date: Thu, 15 Apr 2010 17:31:06 -0400
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-Id: <C9EE125A-F149-4984-B404-06DCA5F43031@cdt.org>
To: Frederick Hirsch <frederick.hirsch@nokia.com>

Some answers inline...

On Apr 14, 2010, at 9:44 AM, Frederick Hirsch wrote:

> Alissa
> Thanks for putting this together. I have a few initial questions and  
> comments:
> 1.  Is the problem with naming because this cannot be legally  
> binding, so license is an inappropriate term? Aren't these really  
> "conditions of use"?

That is part of the issue. "License" works for Creative Commons  
because they have the actual legal licenses to back up the icons that  
everyone is familiar with. The other issue with "license" is that it  
hints towards the concept of data ownership, which most folks in  
privacy circles dislike or, at the very least, prefer to avoid. Many  
privacy advocates would take the stance that if anyone owns your data,  
it's you, no matter who you give it to, and moreover that that concept  
of "owning" data is not very useful. I wouldn't want anyone to assume  
that the existence of privacy "licenses" means that users are  
transferring ownership of their data.

> 2. For secondary use, 3.2, I do not understand why delivering ads is  
> considered contextual or desired by the user.  If I want a reminder  
> of an event, ads are not part an inherent part of that interaction  
> (or is the suggestion that they are in order to pay for it?) Isn't  
> this the marketing-or-profiling category?

We discussed this a bit on the call (http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/att-0049/minutes-2010-04-14.html#item04 
), but just to extend John's point a bit further -- there are zillions  
of potential uses. P3P had 12 (http://www.w3.org/TR/P3P11/#PURPOSE).  
More recent work by some of the folks who worked on P3P has tried to  
group these together into a smaller number of categories (http://cups.cs.cmu.edu/soups/2009/proceedings/a4-kelley.pdf 
). Given that for our purposes simplicity is of utmost importance, we  
thought it made sense to try to group these down even further into the  
categories that are the most likely to actually be selected by users  
and implementable by implementors.

We also thought the distinction between contextual marketing, which  
happens right during each individual interaction with the site/app,  
and later marketing is important. To just have a stand-alone marketing  
attribute or to lump contextual marketing in with marketing-or- 
profiling would mean that users would have to give the ok to all  
marketing, or to none. We were looking for a middle ground.

> 3. Retention - is the baseline of 35 days an industry best practice,  
> a regulation or law, or an arbitrary time for this document?  
> Likewise for 90 days for short.

The 35 days is mostly arbitrary. John will follow up with an  
explanation of that one.

The short attribute isn't meant to be constrained to 90 days -- 90  
days was just what I picked to illustrate the example. So no=35 days,  
short=longer than 35 but limited somehow, and long=unlimited. The  
short time frame could be anything, as long as the time frame exists.

Retention policies vary significantly across industries/applications,  
where they exist at all. For example, the major search engines retain  
individualized search logs for periods ranging from 3 months to 18  
months. Some ad networks delete data after 18 months and some retain  
it forever. Some ISPs retain usage logs for a year or two years. There  
is ongoing legal wrangling around all of these time limits.

> 4. Rulesets - the text for the various attributes suggests that they  
> can be arbitrarily combined (e.g. for the sharing element), yet the  
> section on rulesets suggests there will be a smaller set of pre- 
> defined combinations. What is the intent here?

This is a decision we will have to make as a group. Because this was a  
first cut, we went for keeping it open-ended and providing lots of  
detail in section 3. But if the group thinks it would be better to  
skip defining the attributes and just define a small set of rulesets  
that represent the most likely ones to be used, we can certainly do  
that (and it would be more along the lines of what I think Richard was  
suggesting when we were talking about privacy "profiles" on the call).  
This would probably end up being a less extensible approach (because  
it would be less clear what it takes to define a new profile), but  
that might be a worthwhile trade-off.

> 5. Glossary - is there an existing glossary we should reference?

We will take a look at P3P and others that might be useful.

> 6. References - will these need to be made complete references as we  
> do in the other documents, title, date, author, uri etc

This will get fixed shortly.

> I think the document should be stored in DAP CVS under a new  
> directory, policy-rulesets.


Received on Thursday, 15 April 2010 21:31:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:19 UTC