2009/dap/policy-reqs Overview.html,1.20,1.21

Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv24844

Modified Files:
	Overview.html 
Log Message:
more validation fixes

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- Overview.html	10 Mar 2010 17:00:29 -0000	1.20
+++ Overview.html	10 Mar 2010 17:18:31 -0000	1.21
@@ -326,18 +326,23 @@
       <p>
         <ul>
           <li>
-            A reliably identified website can access geolocation coordinates if the
+            A reliably identified website can access geolocation
+            coordinates if the 
             user confirms it’s OK.
           </li><li>
-            Any website in a subdomain of <code>mynetwork.example.com</code> can read phone status
+            Any website in a subdomain
+            of <code>mynetwork.example.com</code> can read phone
+            status 
             properties.
           </li><li>
-            Reliably identified websites can send and receive SMS except to premium
+            Reliably identified websites can send and receive SMS
+            except to premium 
             rate numbers.
           </li><li>
             <code>evil.example.com</code> cannot access any device APIs.
           </li><li>
-            The <code>weather.example.com</code> <var>foo</var> widget can access geolocation coordinates but
+            The <code>weather.example.com</code> <var>foo</var> widget
+            can access geolocation coordinates but 
             only if it’s embedded on the <var>foo</var> home page.
           </li>
         </ul>
@@ -498,21 +503,25 @@
 
         <ul>
           <li>      <p class='issue'>User authorization vs other policy authority</p>
-            <p>
             <p class='issue'>
               Support for trust models other than user security decisions needed?
             </p>
-
-            This issue is who makes security decisions; in particular whether the user
-            is the sole authority for decisions (whether by configuration of settings,
-            or responses to prompts, or both) or there is another authority that
-            determines the rights given to an application.
-            </p><p>
-              Many existing ecosystems for mobile applications are based on a trust model
-              in which a particular distributor (such as a network operator) certifies an
-              application as trustworthy, eliminating run-time user prompts. This approach
-              avoids the disadvantages of prompts, but at the expense of taking legitimate
-              control away from the user. Other approaches, such as BONDI, do not
+<p>
+  This issue is who makes security decisions; in particular whether the user
+  is the sole authority for decisions (whether by configuration of settings,
+  or responses to prompts, or both) or there is another authority that
+  determines the rights given to an application.
+  </p><p>
+              Many existing ecosystems for mobile applications are
+              based on a trust model 
+              in which a particular distributor (such as a network
+              operator) certifies an 
+              application as trustworthy, eliminating run-time user
+              prompts. This approach 
+              avoids the disadvantages of prompts, but at the expense
+              of taking legitimate 
+              control away from the user. 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
               that certain decisions are made without reference to the user.

Received on Wednesday, 10 March 2010 17:18:35 UTC