- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 17 Mar 2010 11:01:04 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv26983
Modified Files:
Overview.html
Log Message:
changes from Bryan and F2F discussion
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- Overview.html 16 Mar 2010 10:11:50 -0000 1.28
+++ Overview.html 17 Mar 2010 11:01:02 -0000 1.29
@@ -100,6 +100,24 @@
Capability may not directly correspond to enabling or disabling
access to a single Device API interface.</p>
</dd>
+ <dt>Explicit Consent</dt>
+ <dd><p>A user action directly related to a query for the user's consent, for an
+ action to be taken by the application, or for an application lifecycle
+ action. An example of explicit consent for an application action is a
+ positive user response to a query by the web runtime, asking whether an
+ application should be allowed to take a photograph. Examples of explicit
+ consent for an application lifecycle action include a positive user
+ response to a query by:
+ <ul>
+ <li>A positive user response to a query by the web runtime upon
+ application installation, asking whether an explicitly disclosed set of
+ API requests by the application should be allowed.</li>
+ <li>A positive user response to a query by the application
+ storefront upon application selection and download, asking whether an
+ explicitly disclosed set of API requests by the application should be
+ allowed.</li>
+ </ul>
+ </dd>
<dt>Feature</dt>
<dd><p>A Feature is a set of Device APIs that provides access
to specified Device Capabilities. A Feature is the unit of expression of dependencies by Web
@@ -217,7 +235,7 @@
obtaining user consent.</p>
</section> <!-- consent -->
-<section>
+<section id="privacy-minimization">
<h4>Minimization</h4>
<p>To reduce the risks of over-exposing users data, it is helpful to
@@ -272,7 +290,7 @@
untrusted applications</p>
</section> <!-- control -->
-<section>
+<section id="privacy-access">
<h4>Access</h4>
<p><code>UA-Functionality</code>: Whether the UA needs to allow users to view the applications
@@ -282,7 +300,7 @@
users to delete history entries or whole histories</p>
</section> <!-- access -->
-<section>
+<section id="privacy-retention">
<h4>Retention</h4>
<p><code>App-Policy</code>: Whether applications can specify how long they would like to
@@ -296,7 +314,7 @@
applications are bound by some default retention period</p>
</section> <!-- retention -->
-<section>
+<section id="privacy-identifiability">>
<h4>Identifiability</h4>
<p><code>App-Policy</code>: Whether applications can specify that they would like to link
@@ -310,7 +328,7 @@
as it is no longer needed in identifiable form</p>
</section> <!-- identifiability -->
-<section>
+<section id="privacy-secondary-use">
<h4>Secondary Use</h4>
<p> <code>App-Policy</code>: Whether applications can specify secondary purposes for which
@@ -322,7 +340,7 @@
<p> <code>App-Data-Use</code>: Whether applications can use data for secondary purposes</p>
</section> <!-- secondary use -->
-<section>
+<section id="privacy-disclosure">
<h4>Disclosure</h4>
<p>Once the data have been made available to the requester, the
@@ -360,7 +378,7 @@
</div>
</section> <!-- privacy aspects -->
-<section>
+<section id="principles">
<h2>Principles</h2>
<section id="user-control-principle">
<h2>User Control Principle</h2>
@@ -442,10 +460,10 @@
in which a particular distributor (such as a network
operator) certifies an
application as trustworthy, eliminating run-time user
- prompts. This approach
+ prompts in some cases. This approach
avoids the disadvantages of prompts, but at the expense
- of taking legitimate
- control away from the user. Other approaches, such as
+ of taking real-time
+ control away from the user in those cases. Other approaches, such as
BONDI, do not
hard-code this type of trust model, but nonetheless provide for a policy
authority to determine an access control policy, and this policy can require
@@ -473,9 +491,14 @@
DAP should not presuppose that an approach involving blanket permissions
only (e.g. implicit granting of blanket permission by allowing installation to
occur, or an explicit blanket permission given when the application is first
- run) is the right answer. Both approaches have advantages for different use
- cases and we should try to define a system that supports all use cases
+ run) is the right answer. Different permission granularities have
+ advantages for different use
+ cases and we should require a system that supports
+ all use cases
effectively.
+DAP should follow industry practice
+in these cases, and provide permission granularities consistent with
+those widely deployed in the mobile market.
</p>
</li>
</ul>
@@ -483,7 +506,7 @@
</section> <!-- user control -->
</section>
-<section>
+<section id="privacy-use-cases">
<h2>Privacy Use Cases</h2>
<p>
This section outlines privacy use cases.
@@ -883,7 +906,11 @@
<h3>User Control Requirements</h3>
<ul>
<li>The security framework MUST NOT require User Agents to present modal dialogs to prompt users for security
- decisions</li>
+ decisions, while the application is running.
+<ul><li>Note: modal dialogs may be required
+ for security prompts provided during application
+ installation or invocation.</li></ul>
+</li>
<li>The security framework SHOULD allow users to have control over general configuration of security
decisions</li>
<li>The security policy framework SHOULD make it possible to record
@@ -891,6 +918,41 @@
decisions using the policy markup language format.</li>
</ul>
</section> <!-- user control rqmts -->
+ <section id='privacy-rqmts'>
+ <h3>Privacy Requirements</h3>
+<p>Privacy concerns will need to be addressed in different ways,
+ depending on the <a href='#privacy-areas'>privacy area</a>. Approaches include specific requirements
+ on individual APIs, conveying user-expectations with
+ data itself and/or documenting best practices for application
+ and content developers.</p>
+<p> <a href="#privacy-minimization">Minimization</a> is closely related to API methods and what they
+ return, so addressed in specific API definitions. <a href="#privacy-access">Access</a> to
+ the history of which application (web content) obtained specific
+ data may also be defined
+ either for all APIs or individually.</p>
+<p> Requirements involving user expectations on specific data items,
+ such as areas of data
+ retention, secondary use and dislosure may require user parameters
+ to be conveyed
+ with data. (possible DAP v2 item). Finally, items that impact
+ practices by application/content developers are out of the scope of
+ API definition, but may benefit from Best Practice definitions.
+</p>
+<p>The following table summarizes this approach:</p>
+<table border="1" cellspacing="1" cellpadding="1">
+ <tr><th>Address in specific API Definitions</th><th>Address by
+ conveying additional information with Data</th><th>Address by
+ describing Best Practices</th></tr>
+ <tr><td><a href="#privacy-minimization">Minimization</a></td><td></td><td></td></tr>
+ <tr><td><a href="#privacy-access">Access to usage
+ history</a></td><td></td><td><a href="#privacy-access">Access</a></td></tr>
+ <tr><td><a href="#privacy-minimization">Minimization</a></td><td><a href="#privacy-retention">Retention</a></td><td><a href="#privacy-retention">Retention</a></td></tr>
+ <tr><td></td><td><a
+href="#privacy-secondary-use">Secondary Use</a></td><td><a
+href="#privacy-secondary-use">Secondary Use</a></td></tr>
+ <tr><td></td><td><a href="#privacy-disclosure">Disclosure</a></td><td><a href="#privacy-disclosure">Disclosure</a></td></tr>
+</table>
+ </section>
<section>
<h2>Security Framework Requirements</h2>
<ul>
@@ -908,8 +970,8 @@
define a Javascript binding</li>
<li>It MUST be possible to have separate policy decision and
enforcement points</li>
- <li>The DAP security model SHOULD be compatible with the HTML 5
- security model.</li>
+ <li>The DAP security model SHOULD be compatible with the
+ same origin policy.</li>
</ul>
</section> <!-- security framework requirements -->
<section>
Received on Wednesday, 17 March 2010 11:01:07 UTC