2009/dap/privacy-rulesets Overview.html,1.5,1.6

Update of /sources/public/2009/dap/privacy-rulesets
In directory hutz:/tmp/cvs-serv8297

Modified Files:
	Overview.html 
Log Message:
Added list of issues with rulesets

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-rulesets/Overview.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- Overview.html	20 Apr 2010 20:29:11 -0000	1.5
+++ Overview.html	6 Oct 2010 04:38:42 -0000	1.6
@@ -373,7 +373,21 @@
             ruleset'>ruleset</a> allows all three kinds of sharing,
             all three kinds of <a>secondary use</a>, and indefinite
             retention.</p></dd> 
-    </dl>    
+    </dl>  
+
+	<div class="issue">
+		<p>There are a number of open implementability questions about the rulesets. As discussed at the London F2F, these include:
+		<ul>
+			<li><b>Granularity of permissions:</b> At the F2F, a simplified and less granular <a href="http://lists.w3.org/Archives/Public/www-archive/2010Jul/att-0121/w3c-simple-privacy-policies.pdf">selection of rulesets</a> was discussed that would provide only three ruleset choices: one-time, profile, and personalization. Whether the granularity should be at this lower level or somewhere in between the three simplified rulesets and the rulesets as described in this document is an open question.</li>
+			<li><b>Variability of user policies:</b> Because there are multiple rulesets, sites could receive different rulesets from different users. Responding to this variability in back-end implementations may be challenging depending on the site functionality and the range of policies that might be received.</li>
+			<li><b>UI complexity:</b>The rulesets proposal envisions that users would have to select the appropriate ruleset for an interaction through the browser UI. With multiple possible rulesets, this may translate into a more complicated UI than browsers currently offer for other user preferences.</li>
+			<li><b>UI promising too much:</b> Because browsers would be displaying the ruleset choices in the UI but they are not in a position to enforce the rulesets, there is concerns that users may lose trust in the browser when their ruleset directives are not followed, even though that would be the fault of the web site that received the rulesets and not the browser.</li>
+			<li><b>User decision complexity:</b> The results of choosing a particular ruleset may not be evident to users, creating a complex decision that users are not prepared to make. For example, if a particular ruleset choice results in a web application not working properly, it is not clear how to explain to users the causality between the ruleset choice and the application failure.</li>
+			<li><b>Composability of rulesets:</b> When multiple pieces of data are combined in a single service, or when multiple rulesets are chosen for a single piece of data, rulesets may have to be composed. The current proposal does not address composability.</li>
+			<li><b>Jurisdiction-based configurations:</b> There may be legal and other jurisdiction-based constraints that require web applications to perform certain operations on user data. With a small static set of rulesets, the result of these constraints may be that certain applications are unable to comply with particular rulesets.</li>
+			</ul>
+	</p>
+  </div>
     </section>
     <section class='appendix'>
       <h2>Glossary</h2>

Received on Wednesday, 6 October 2010 04:38:46 UTC