2009/dap/privacy-reqs Overview.html,1.7,1.8

Update of /sources/public/2009/dap/privacy-reqs
In directory hutz:/tmp/cvs-serv3381

Modified Files:
	Overview.html 
Log Message:
editing pass per ACTION-144: remove conformance requirements, and minor additional edits


Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-reqs/Overview.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- Overview.html	19 Mar 2010 10:27:24 -0000	1.7
+++ Overview.html	24 Mar 2010 13:55:25 -0000	1.8
@@ -24,56 +24,47 @@
   <body>
     <section id='abstract'>
       This document provides definitions, use cases, and  requirements
-      for device APIs. 
+      for making device APIs more privacy-friendly. 
     </section> <!-- abstract -->
 
-    <section id='introduction'>
-      <h2>Introduction</h2>
+    <section id="sotd">
       <p>
         This document is an editors draft and currently does not
         reflect consensus of the WG but rather is a starting point for
         further work. It is based on input documents and list
         discussion.
       </p>
+
+      </section>
+    <section id='introduction'>
+      <h2>Introduction</h2>
       <p>
-        The security framework described in this document is intended
-        to be applicable both to widgets and web applications (web
-        site access to Device APIs).
+        The privacy requirements described in this document are intended
+        to be applicable to device APIs both in the context of widgets and web applications.
       </p>
     </section>  <!-- introduction -->
 
-    <section id='targets'>
-      <h2>Conformance Targets</h2>
-<p>There are two conformance targets referred to in this document:</p>
-<ul>
-<li><p><code>User Agent</code></li>
-<li><p><code>Application/Content</code></li>
-</ul>
-</section>
 <section id="privacy-categorization">
 <h3>Privacy Requirement Categorization</h3>
 <ul>
 <li><p><code>UA-Functionality</code>: Requirements for functionality provided strictly by user
 agents (without relation to any policy information provided by an
-application or a user)</p></li>
-<li><p><code>App-Policy</code>: Requirements for policies to be provided by applications</p></li>
-<li><p><code>User-Policy</code>: Requirements for policies to be provided by users</p></li>
-<li><p><code>App-Data-Use</code>: Requirements for what applications can do with the data
-they receive</p></li>
-</ul>
-
-<p>An example of <code>UA-Functionality</code> would be akin to the Geolocation requirement that
+application or a user); for instance, the Geolocation requirement that
 user agents must obtain express user permission before sending
-location. An example of <code>App-Policy</code> would be a requirement that applications
+location</p></li>
+<li><p><code>App-Policy</code>: Requirements for policies to be provided by applications; for instance, a requirement that applications
 provide information about the purpose, secondary uses, retention time,
 or other policies about the data they are requesting to the UA so that
-they may be accessible to users. An example of <code>User-Policy</code> would be a
+they may be accessible to users</p></li>
+<li><p><code>User-Policy</code>: Requirements for policies to be provided by users; for instance, a
 requirement that UAs provide a way for users to send information about
 their policy preferences -- "don't disclose my data to anyone" or
-"make my data public" for example -- to applications. An example of <code>App-Data-Use</code>
-would be akin to the Geolocation requirement that applications must
+"make my data public" for example -- to applications</p></li>
+<li><p><code>App-Data-Use</code>: Requirements for what applications can do with the data
+they receive; for instance, the Geolocation requirement that applications must
 only use the location information for the task for which it was
-provided to them.</p>
+provided to them</p></li>
+</ul>
 
 <p class="issue">Will the document support all four types of
 requirements, and if not, which subset will it support? If the
@@ -153,7 +144,7 @@
           is an API that produces a message template, but requires the
           user to press &quot;send&quot; to actually send the message.
         </p><p>
-          Such user actions constitute implicit consent, since the user
+          Such user actions constitute <dfn>implicit consent</dfn>, since the user
           has a choice to perform them and doing so implies consent to
           use the associated Device Capabilities. Such implicit consent
           eliminates the need for a security access dialog for that
@@ -246,7 +237,7 @@
 applications are bound by some default retention period</p>
 </section> <!-- retention -->
 
-<section id="privacy-identifiability">>
+<section id="privacy-identifiability">
 <h4>Identifiability</h4>
 
 <p><code>App-Policy</code>: Whether applications can specify that they would like to link

Received on Wednesday, 24 March 2010 13:55:32 UTC