- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 20 Apr 2010 20:17:23 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-rulesets
In directory hutz:/tmp/cvs-serv7898
Modified Files:
Overview.html
Log Message:
attempt to fix validation error
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-rulesets/Overview.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- Overview.html 20 Apr 2010 15:13:30 -0000 1.2
+++ Overview.html 20 Apr 2010 20:17:20 -0000 1.3
@@ -1,262 +1,256 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-
-
-
-<html lang="en-US">
-<head>
- <title>Privacy Rulesets</title>
- <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
-
-
-
- <!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
- <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
- <script class='remove'>
- var respecConfig = {
- // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "ED",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- //shortName: "",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- // subtitle : "an excellent document",
-
- // if you wish the publication date to be other than today, set this
- //publishDate: "2010-04-14",
-
- // if the specification's copyright date is a range of years, specify
- // the start date here:
- // copyrightStart: "2005"
-
- // if there is a previously published draft, uncomment this and set its YYYY==-MM-DD date
- // and its maturity status
- //previousPublishDate: "2010-04-12",
- //previousMaturity: "ED",
-
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "http://dev.w3.org/2009/dap/privacy-rulesets/",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
-
- // if you want to have extra CSS, append them to this list
- // it is recommended that the respec.css stylesheet be kept
- extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
-
- // editors, add as many as you like
- // only "name" is required
- editors: [
- { name: "Alissa Cooper",
- company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" }, { name: "John Morris",
- company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" }, { name: "Erica Newland",
- company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" },
- ],
-
- //n<!--url: "http://example.org/",-->
-
- // authors, add as many as you like.
- // This is optional, uncomment if you have authors as well as editors.
- // only "name" is required. Same format as editors.
-
- //authors: [
- // { name: "Your Name", url: "http://example.org/",
- // company: "Your Company", companyURL: "http://example.com/" },
- //],
-
- // name of the WG
- wg: "Device APIs and Policy Working Group",
-
- // URI of the public WG page
- wgURI: "http://www.w3.org/2009/dap/",
-
- // name (with the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-device-apis",
- //?????
-
- // URI of the patent status for this WG, for Rec-track documents
- // !!!! IMPORTANT !!!!
- // This is important for Rec-track documents, do not copy a patent URI from a random
- // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
- // Team Contact.
- //wgPatentURI: "",
- };
- </script>
-
- </head>
- <body>
- <section id="sotd">
- <p>This document is merely a W3C-internal document. It has no official standing of any kind and does not represent consensus of the W3C Membership. It is a strawman that has been produced without significant consultation with the wider privacy community for the purpose of starting a discussion about what makes sense in the space of potential possibilities for privacy rulesets.</p>
- </section>
-
-
- <section id='abstract'>
- This document proposes a scheme for defining privacy rulesets: bundles of user privacy preferences that can be conveyed together with user data in the context of a web site or application interaction.
- </section>
-
- <section>
- <h2>Introduction</h2>
- <p>There have been many previous efforts at encapsulating privacy policies in reduced forms [[GEOPRIV-ARCH]][[ID-MGM]][[LIC-PRIV]][[P3P11]][[FIN-PRIV-NOTICE]][[MOZ-ICONS]][[PRIV-ICONS]][[PRIV-ICONSET]][[PRIV-LABEL]]. The lessons learned from all of these support the notion that the DAP WG discussed in Prague that for user-defined expressions of privacy preferences, two constraints are key: they need to be simple, and they need to make sense to both users and developers. The experience of the Creative Commons licenses [[CC-ABOUT]] reinforces this as well -- CC started with four license conditions and six licenses, and it seems that in practice only two of the license conditions tend to vary from license to license [[CC-CHOOSE]].</p>
-
- <p>Using the term "license" to describe user privacy preferences doesn't seem quite right, since "license" implies some rights being transferred between the user and the organization collecting his or her data. Many other terms have been suggested: privacy rulesets, bundles, baskets, preferences, policies, expectations. None of them seems perfect, but this proposal will call them <a title='privacy ruleset'>privacy rulesets</a>. Other key terms are defined in the glossary below.</p>
-
- <p>A scheme is proposed below for defining <a title='privacy ruleset'>privacy rulesets</a> that cover three elements of privacy that seem to matter most to users, are easiest to encapsulate in brief form, and have been addressed by similar previous efforts: sharing, secondary use, and retention of user data. Each element has three possible attributes. When one or more of these attributes are combined, they produce a <a title='privacy ruleset'>privacy ruleset</a>. The scheme assumes that a <a title='privacy ruleset'>ruleset</a> would be somehow conveyed together with user data in the context of an interaction with a web site or application owned by a company or other organization (known as the <a title='data collector'>data collector</a>), such that the <a title='privacy ruleset'>ruleset</a> is meant to convey to the organization what the user's preferences are about the data being conveyed. A given <a title='privacy ruleset'>ruleset</a> is meant to govern only the data that gets conveyed with it.</p>-
-
- </section>
-
- <section>
- <h2>Scope</h2>
- <p>
- For simplicity, the <a title='privacy ruleset'>rulesets</a> only apply to <a title = 'identified data'>identified data</a> -- information that can reasonably be tied to an individual. What <a title='data collector'> data collectors </a> do with other kinds of data that is not linkable to an individual or is held in the aggregate is out of scope. </p>
- </section>
-
- <section>
- <h2>Privacy Elements</h2>
- <p>
- The elements and their attributes are defined below.
- </p>
- <section>
- <h2>Sharing</h2>
- <p><b><code>internal</code></b>: The data can be shared internally within the <a>data collector</a>'s organization and with other organizations that help the <a>data collector</a> provide the service requested in the current interaction.
- <ul>
- <li>Example: A user uses an application that invokes the media capture API to provide a voice search service. The voice capture gets shared only with the organization that provides the app and its partner company that provides the search results, but not with any other company.</li></ul>
-
- <p><code><b>affiliates</b></code>: The data can be shared with other organizations that the <a>data collector</a> controls or is controlled by.</p>
- <ul>
- <li>Example: A user provides a photo captured with the media capture API to Flickr and that photo gets shared with Yahoo (Yahoo owns Flickr).</li></ul>
-
- <p><code><b>unrelated-companies</b></code>: The data can be shared outside of the <a>data collector</a>'s organization with other organizations that it does not control and is not controlled by.</p>
- <ul>
- <li>Example: A user provides contact details obtained through the contacts API to an application provider and that application provider shares them with other unaffiliated companies, like direct marketers or credit reporting agencies.</ul></li>
-
- <p><code><b>public</b></code>: The data can be made public.</p>
- <ul>
- <li>Example: A user uses an application employing the calendar API to post an event on a public web site.</ul></li>
-
- <p>It is important to note that none of the <code>sharing</code> attributes are mutually exclusive -- any of them may be combined to form more permissive grants of sharing abilities than any single one of them on its own.</p>
- </section>
-
- <section>
- <h2>Secondary Use</h2>
-
- <p>It can sometimes be difficult to distinguish between "primary" uses of user data and "secondary" uses. What users believe to be <a title='primary use'>primary uses</a> and what applications providers believe to be <a title='primary use'>primary uses</a> are not always the same, because all of the functionality that contributes to being able to provide a particular application or service is not always evident to users. The attributes below are crafted with the user's conception of <a>secondary use</a> in mind, and therefore attempt to cover all uses of user data that users might want to express a preference about (without making the attributes overly granular).</p>
-
- <p><code><b>contextual</b></code>: The data may only be used for the purpose of completing the current interaction. Contextual uses may include securing, troubleshooting or improving the service being provided or providing advertising in the context of the current interaction.</p>
- <ul
- ><li>Example: A user sets reminders for upcoming events using an application that uses the calendar API. The application uses the events data to deliver the reminders and to serve a contextual ad when the user sets a reminder.</ul></li>
-
- <p><code><b>customization</b></code>: The data may be used to customize, personalize, or otherwise tailor the current interaction for the user.</p>
- <ul>
- <li>Example: A user records songs that he or she hears using an application that employs the media capture API. The application identifies and uses the recorded songs to suggest new music that the user may be interested in.</ul></li>
-
- <p><code><b>marketing-or-profiling</b></code>: The data may be used for marketing and/or profiling purposes. Marketing may occur over time and via any channel (web, email, telemarketing, etc.). Profiling involves the creation of a collection of information about an individual and applies to <a title='profile'>profiles</a> created for any purpose other than customization (e.g., for research, to sell to other organizations, etc.).</p>
- <ul>
- <li>Example: A user sets reminders for upcoming events using an application that uses the calendar API. The application uses the events data to deliver the reminders and to serve ads based on all of the user's reminders.</ul></li>
-
- <p>None of the <code>secondary-use</code> attributes are mutually exclusive.</p>
- </section>
-
- <section>
- <h2>Retention</h2>
-
- <p>The fact that most web servers automatically record logs of user activity -- and that many of these logs are never deleted -- can complicate the task of having applications abide by user-defined retention policies. The retention attributes defined below assume that as a general matter, all <a title='data collector'>data collectors</a> may retain user data for a baseline period of 35 days for the purposes of maintenance, security, and troubleshooting. The attributes express user preferences that apply to retention practices that go beyond this baseline period.</p>
-
- <p><code><b>no</b></code>: The data may only be retained for the baseline period.</p></li>
- <ul>
- <li>Example: A user uses a webcam service that employs the media capture API. The video data is not retained after 35 days.</ul></li>
-
- <p><code><b>short</b></code>: The data may be retained beyond the baseline period, but only for a limited time.</p></li>
- <ul>
- <li>Example: A user uses an application that invokes the media capture API to provide a voice search service. The voice searches are retained for 90 days to optimize search results.</ul></li>
-
- <p><code><b>long</b></code>: The data may be retained beyond the baseline period for an unspecified or indefinite amount of time.</p></li>
- <ul>
- <li>Example: A user drafts SMS messages using an application that invokes the messaging API. Those draft SMS messages are retained indefinitely until the user deletes them.</ul></li>
-
- <p>The <code>retention</code> attributes are mutually exclusive.</p>
- </section>
- </section>
-
- <section>
- <h2>Privacy Rulesets</h2>
-
- <p>The attributes listed above could be combined in many different combinations. Not all of them are possible or sensical (i.e., allowing marketing-or-profiling but not retention), and like Creative Commons licenses, there are likely only a handful that users would want to employ regularly. A list of these potentially common <a title='privacy ruleset'>rulesets</a> is proposed below.</p>
-
- <p>(The formatting of these is arbitrary: they could just as easily be declared as two-letter codes like Creative Commons attributes, or like URI parameters, or in XML, or some other way).</p>
-
- <dl>
- <dt><p><b>Least permissive:
- <br><code>sharing=internal</code>
- <br><code>secondary-use=contextual</code>
- <br><code>retention=no</code>
- </b></dt>
- <dd>The least permissive <a title='privacy ruleset'>ruleset</a> says that the user wants her data shared only internally by the <a>data collector</a> and organizations that help the <a>data collector</a> deliver the service, only used for contextual purposes (which includes contextual advertising), and not retained beyond the baseline period.</p></dd>
- <dt><p><b>Internal customization/personalization:
- <br><code>sharing=internal</code>
- <br><code>secondary-use=customization</code>
- <br><code>retention=short</code>
- </b></dt>
- <dd>Some users may want to permit their data to be used internally by the <a>data collector</a> to do individualized analytics or provide some personalization based on recent activity, but not for marketing purposes. This <a title='privacy ruleset'>ruleset</a>, which allows data to be retained for a limited period and used for customization but not shared, corresponds to that set of preferences.</p></dd>
- <dt><p><b>Profile-based advertising:
- <br><code>sharing=internal</code>
- <br><code>secondary-use=marketing-or-profiling</code>
- <br><code>retention=long</code></b></dt>
- <dd>If users want to allow the <a>data collector</a> to use their data in <a title='profile'>profiles</a> that are later used to target ads back to them, this <a title='privacy ruleset'>ruleset</a> would allow for that, with sharing still limited for internal use but with marketing, profiling, and retention allowed.</p></dd>
- <dt><p><b>Public:
- <br><code>sharing=public</code>
- <br><code>secondary-use=contextual</code>
- <br><code>retention=long</code>
- </b></dt>
- <dd>This <a title='privacy ruleset'>ruleset</a> lets users express their permission to have their data shared publicly, but not used by the <a>data collector</a> for non-contextual purposes.</p></dd>
- <dt><p><b>Most permissive:
- <br><code>sharing=internal</code>
- <br><code>sharing=affiliates</code>
- <br><code>sharing=unrelated-companies</code>
- <br><code>secondary-use=contextual</code>
- <br><code>secondary-use=customization</code>
- <br><code>secondary-use=marketing-or-profiling</code>
- <br><code>retention=long</code>
- <br><code></b></dt>
- <dd>The most permissive <a title='privacy ruleset'>ruleset</a> allows all three kinds of sharing, all three kinds of <a>secondary use</a>, and indefinite retention.</p></dd>
- </dl>
- </section>
-
-
-
-
- <section class='appendix'>
- <h2>Glossary</h2>
- <p>
- <dl>
- <dt><dfn>affiliate</dfn></dt>
- <dd>An organization that controls, is controlled by, or is under common control with another organization. This comports with the [[AD-INDUSTRY]]'s definition of this term.</dd>
- <dt><dfn>data collector</dfn></dt>
- <dd>The organization that owns or otherwise controls the web site or application with which the user interaction occurs. </dd>
- <dt><dfn>identified data</dfn></dt>
- <dd>Information that can reasonably be tied to an individual. See [[P3P11]]'s <a href="http://www.w3.org/TR/P3P11/#def_identity">definition</a> of this term.</dd>
- <dt><dfn>privacy ruleset</dfn></dt>
- <dd>A combination of privacy rules describing the user's preferences about the sharing, secondary use, and retention attributes of his or her data.</dd>
- <dt><dfn>primary use</dfn></dt>
- <dd>A use of data that is directly necessary to complete the user's interaction with the web site or application.</dd>
- <dt><dfn>profile</dfn></dt>
- <dd>A collection of data about an individual.</dd>
- <dt><dfn>secondary use</dfn></dt>
- <dd>Any use of the user's data other than the primary use(s).</dd>
- <dt><dfn>unrelated company</dfn></dt>
- <dd>Any organization that is distinct from the data collector and is not an affiliate of the data collector.</dd>
- </dl>
- </p>
- </section>
-
-
-</section>
-
- </body>
-</html>
+<!DOCTYPE html>
+<html>
+<head>
+ <title>Privacy Rulesets</title>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+ <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ //shortName: "",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ //publishDate: "2010-04-14",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY==-MM-DD date
+ // and its maturity status
+ //previousPublishDate: "2010-04-12",
+ //previousMaturity: "ED",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dev.w3.org/2009/dap/privacy-rulesets/",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Alissa Cooper",
+ company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" }, { name: "John Morris",
+ company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" }, { name: "Erica Newland",
+ company: "Center for Democracy and Technology", companyURL: "http://www.cdt.org/" },
+ ],
+
+ //n<!--url: "http://example.org/",-->
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Device APIs and Policy Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2009/dap/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-device-apis",
+ //?????
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ //wgPatentURI: "",
+ };
+ </script>
+
+ </head>
+ <body>
+ <section id="sotd">
+ <p>This document is merely a W3C-internal document. It has no official standing of any kind and does not represent consensus of the W3C Membership. It is a strawman that has been produced without significant consultation with the wider privacy community for the purpose of starting a discussion about what makes sense in the space of potential possibilities for privacy rulesets.</p>
+ </section>
+
+
+ <section id='abstract'>
+ This document proposes a scheme for defining privacy rulesets: bundles of user privacy preferences that can be conveyed together with user data in the context of a web site or application interaction.
+ </section>
+
+ <section>
+ <h2>Introduction</h2>
+ <p>There have been many previous efforts at encapsulating privacy policies in reduced forms [[GEOPRIV-ARCH]][[ID-MGM]][[LIC-PRIV]][[P3P11]][[FIN-PRIV-NOTICE]][[MOZ-ICONS]][[PRIV-ICONS]][[PRIV-ICONSET]][[PRIV-LABEL]]. The lessons learned from all of these support the notion that the DAP WG discussed in Prague that for user-defined expressions of privacy preferences, two constraints are key: they need to be simple, and they need to make sense to both users and developers. The experience of the Creative Commons licenses [[CC-ABOUT]] reinforces this as well -- CC started with four license conditions and six licenses, and it seems that in practice only two of the license conditions tend to vary from license to license [[CC-CHOOSE]].</p>
+
+ <p>Using the term "license" to describe user privacy preferences doesn't seem quite right, since "license" implies some rights being transferred between the user and the organization collecting his or her data. Many other terms have been suggested: privacy rulesets, bundles, baskets, preferences, policies, expectations. None of them seems perfect, but this proposal will call them <a title='privacy ruleset'>privacy rulesets</a>. Other key terms are defined in the glossary below.</p>
+
+ <p>A scheme is proposed below for defining <a title='privacy ruleset'>privacy rulesets</a> that cover three elements of privacy that seem to matter most to users, are easiest to encapsulate in brief form, and have been addressed by similar previous efforts: sharing, secondary use, and retention of user data. Each element has three possible attributes. When one or more of these attributes are combined, they produce a <a title='privacy ruleset'>privacy ruleset</a>. The scheme assumes that a <a title='privacy ruleset'>ruleset</a> would be somehow conveyed together with user data in the context of an interaction with a web site or application owned by a company or other organization (known as the <a title='data collector'>data collector</a>), such that the <a title='privacy ruleset'>ruleset</a> is meant to convey to the organization what the user's preferences are about the data being conveyed. A given <a title='privacy ruleset'>ruleset</a> is meant to govern only the data that gets conveyed with it.</p>+
+
+ </section>
+
+ <section>
+ <h2>Scope</h2>
+ <p>
+ For simplicity, the <a title='privacy ruleset'>rulesets</a> only apply to <a title = 'identified data'>identified data</a> -- information that can reasonably be tied to an individual. What <a title='data collector'> data collectors </a> do with other kinds of data that is not linkable to an individual or is held in the aggregate is out of scope. </p>
+ </section>
+
+ <section>
+ <h2>Privacy Elements</h2>
+ <p>
+ The elements and their attributes are defined below.
+ </p>
+ <section>
+ <h2>Sharing</h2>
+ <p><b><code>internal</code></b>: The data can be shared internally within the <a>data collector</a>'s organization and with other organizations that help the <a>data collector</a> provide the service requested in the current interaction.
+ <ul>
+ <li>Example: A user uses an application that invokes the media capture API to provide a voice search service. The voice capture gets shared only with the organization that provides the app and its partner company that provides the search results, but not with any other company.</li></ul>
+
+ <p><code><b>affiliates</b></code>: The data can be shared with other organizations that the <a>data collector</a> controls or is controlled by.</p>
+ <ul>
+ <li>Example: A user provides a photo captured with the media capture API to Flickr and that photo gets shared with Yahoo (Yahoo owns Flickr).</li></ul>
+
+ <p><code><b>unrelated-companies</b></code>: The data can be shared outside of the <a>data collector</a>'s organization with other organizations that it does not control and is not controlled by.</p>
+ <ul>
+ <li>Example: A user provides contact details obtained through the contacts API to an application provider and that application provider shares them with other unaffiliated companies, like direct marketers or credit reporting agencies.</ul></li>
+
+ <p><code><b>public</b></code>: The data can be made public.</p>
+ <ul>
+ <li>Example: A user uses an application employing the calendar API to post an event on a public web site.</ul></li>
+
+ <p>It is important to note that none of the <code>sharing</code> attributes are mutually exclusive -- any of them may be combined to form more permissive grants of sharing abilities than any single one of them on its own.</p>
+ </section>
+
+ <section>
+ <h2>Secondary Use</h2>
+
+ <p>It can sometimes be difficult to distinguish between "primary" uses of user data and "secondary" uses. What users believe to be <a title='primary use'>primary uses</a> and what applications providers believe to be <a title='primary use'>primary uses</a> are not always the same, because all of the functionality that contributes to being able to provide a particular application or service is not always evident to users. The attributes below are crafted with the user's conception of <a>secondary use</a> in mind, and therefore attempt to cover all uses of user data that users might want to express a preference about (without making the attributes overly granular).</p>
+
+ <p><code><b>contextual</b></code>: The data may only be used for the purpose of completing the current interaction. Contextual uses may include securing, troubleshooting or improving the service being provided or providing advertising in the context of the current interaction.</p>
+ <ul
+ ><li>Example: A user sets reminders for upcoming events using an application that uses the calendar API. The application uses the events data to deliver the reminders and to serve a contextual ad when the user sets a reminder.</ul></li>
+
+ <p><code><b>customization</b></code>: The data may be used to customize, personalize, or otherwise tailor the current interaction for the user.</p>
+ <ul>
+ <li>Example: A user records songs that he or she hears using an application that employs the media capture API. The application identifies and uses the recorded songs to suggest new music that the user may be interested in.</ul></li>
+
+ <p><code><b>marketing-or-profiling</b></code>: The data may be used for marketing and/or profiling purposes. Marketing may occur over time and via any channel (web, email, telemarketing, etc.). Profiling involves the creation of a collection of information about an individual and applies to <a title='profile'>profiles</a> created for any purpose other than customization (e.g., for research, to sell to other organizations, etc.).</p>
+ <ul>
+ <li>Example: A user sets reminders for upcoming events using an application that uses the calendar API. The application uses the events data to deliver the reminders and to serve ads based on all of the user's reminders.</ul></li>
+
+ <p>None of the <code>secondary-use</code> attributes are mutually exclusive.</p>
+ </section>
+
+ <section>
+ <h2>Retention</h2>
+
+ <p>The fact that most web servers automatically record logs of user activity -- and that many of these logs are never deleted -- can complicate the task of having applications abide by user-defined retention policies. The retention attributes defined below assume that as a general matter, all <a title='data collector'>data collectors</a> may retain user data for a baseline period of 35 days for the purposes of maintenance, security, and troubleshooting. The attributes express user preferences that apply to retention practices that go beyond this baseline period.</p>
+
+ <p><code><b>no</b></code>: The data may only be retained for the baseline period.</p></li>
+ <ul>
+ <li>Example: A user uses a webcam service that employs the media capture API. The video data is not retained after 35 days.</ul></li>
+
+ <p><code><b>short</b></code>: The data may be retained beyond the baseline period, but only for a limited time.</p></li>
+ <ul>
+ <li>Example: A user uses an application that invokes the media capture API to provide a voice search service. The voice searches are retained for 90 days to optimize search results.</ul></li>
+
+ <p><code><b>long</b></code>: The data may be retained beyond the baseline period for an unspecified or indefinite amount of time.</p></li>
+ <ul>
+ <li>Example: A user drafts SMS messages using an application that invokes the messaging API. Those draft SMS messages are retained indefinitely until the user deletes them.</ul></li>
+
+ <p>The <code>retention</code> attributes are mutually exclusive.</p>
+ </section>
+ </section>
+
+ <section>
+ <h2>Privacy Rulesets</h2>
+
+ <p>The attributes listed above could be combined in many different combinations. Not all of them are possible or sensical (i.e., allowing marketing-or-profiling but not retention), and like Creative Commons licenses, there are likely only a handful that users would want to employ regularly. A list of these potentially common <a title='privacy ruleset'>rulesets</a> is proposed below.</p>
+
+ <p>(The formatting of these is arbitrary: they could just as easily be declared as two-letter codes like Creative Commons attributes, or like URI parameters, or in XML, or some other way).</p>
+
+ <dl>
+ <dt><p><b>Least permissive:
+ <br><code>sharing=internal</code>
+ <br><code>secondary-use=contextual</code>
+ <br><code>retention=no</code>
+ </b></dt>
+ <dd>The least permissive <a title='privacy ruleset'>ruleset</a> says that the user wants her data shared only internally by the <a>data collector</a> and organizations that help the <a>data collector</a> deliver the service, only used for contextual purposes (which includes contextual advertising), and not retained beyond the baseline period.</p></dd>
+ <dt><p><b>Internal customization/personalization:
+ <br><code>sharing=internal</code>
+ <br><code>secondary-use=customization</code>
+ <br><code>retention=short</code>
+ </b></dt>
+ <dd>Some users may want to permit their data to be used internally by the <a>data collector</a> to do individualized analytics or provide some personalization based on recent activity, but not for marketing purposes. This <a title='privacy ruleset'>ruleset</a>, which allows data to be retained for a limited period and used for customization but not shared, corresponds to that set of preferences.</p></dd>
+ <dt><p><b>Profile-based advertising:
+ <br><code>sharing=internal</code>
+ <br><code>secondary-use=marketing-or-profiling</code>
+ <br><code>retention=long</code></b></dt>
+ <dd>If users want to allow the <a>data collector</a> to use their data in <a title='profile'>profiles</a> that are later used to target ads back to them, this <a title='privacy ruleset'>ruleset</a> would allow for that, with sharing still limited for internal use but with marketing, profiling, and retention allowed.</p></dd>
+ <dt><p><b>Public:
+ <br><code>sharing=public</code>
+ <br><code>secondary-use=contextual</code>
+ <br><code>retention=long</code>
+ </b></dt>
+ <dd>This <a title='privacy ruleset'>ruleset</a> lets users express their permission to have their data shared publicly, but not used by the <a>data collector</a> for non-contextual purposes.</p></dd>
+ <dt><p><b>Most permissive:
+ <br><code>sharing=internal</code>
+ <br><code>sharing=affiliates</code>
+ <br><code>sharing=unrelated-companies</code>
+ <br><code>secondary-use=contextual</code>
+ <br><code>secondary-use=customization</code>
+ <br><code>secondary-use=marketing-or-profiling</code>
+ <br><code>retention=long</code>
+ <br><code></b></dt>
+ <dd>The most permissive <a title='privacy ruleset'>ruleset</a> allows all three kinds of sharing, all three kinds of <a>secondary use</a>, and indefinite retention.</p></dd>
+ </dl>
+ </section>
+
+
+
+
+ <section class='appendix'>
+ <h2>Glossary</h2>
+ <p>
+ <dl>
+ <dt><dfn>affiliate</dfn></dt>
+ <dd>An organization that controls, is controlled by, or is under common control with another organization. This comports with the [[AD-INDUSTRY]]'s definition of this term.</dd>
+ <dt><dfn>data collector</dfn></dt>
+ <dd>The organization that owns or otherwise controls the web site or application with which the user interaction occurs. </dd>
+ <dt><dfn>identified data</dfn></dt>
+ <dd>Information that can reasonably be tied to an individual. See [[P3P11]]'s <a href="http://www.w3.org/TR/P3P11/#def_identity">definition</a> of this term.</dd>
+ <dt><dfn>privacy ruleset</dfn></dt>
+ <dd>A combination of privacy rules describing the user's preferences about the sharing, secondary use, and retention attributes of his or her data.</dd>
+ <dt><dfn>primary use</dfn></dt>
+ <dd>A use of data that is directly necessary to complete the user's interaction with the web site or application.</dd>
+ <dt><dfn>profile</dfn></dt>
+ <dd>A collection of data about an individual.</dd>
+ <dt><dfn>secondary use</dfn></dt>
+ <dd>Any use of the user's data other than the primary use(s).</dd>
+ <dt><dfn>unrelated company</dfn></dt>
+ <dd>Any organization that is distinct from the data collector and is not an affiliate of the data collector.</dd>
+ </dl>
+ </p>
+ </section>
+
+
+</section>
+
+ </body>
+</html>
Received on Tuesday, 20 April 2010 20:17:25 UTC