2009/dap/docs/feat-perms feat-perms.html,1.1,1.2

Update of /sources/public/2009/dap/docs/feat-perms
In directory hutz:/tmp/cvs-serv4597

Modified Files:
	feat-perms.html 
Log Message:
Add capability-based security style proposal

Index: feat-perms.html
===================================================================
RCS file: /sources/public/2009/dap/docs/feat-perms/feat-perms.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- feat-perms.html	3 Mar 2011 11:16:47 -0000	1.1
+++ feat-perms.html	22 Mar 2011 11:37:59 -0000	1.2
@@ -38,9 +38,16 @@
 <body>
 <h1>Feature Permissions Playground</h1>
 
+<p>Update <time>2011-03-22</time>: dougt is also pondering how to do
+<a href="http://dougt.org/wordpress/2011/03/device-api-permission-management/">Device API permission management</a>. Added
+a <a href="#capability">Capability-based Security Model inspired proposal</a>. Feel free to join the discussion on
+    <a href="http://lists.w3.org/Archives/Public/public-device-apis/">public-device-apis</a>.</p>
+
 <p>This demo implements the
 <a href="http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html#idl-Permissions">Permissions interface</a>
-with some <a href="#changes">changes</a>. The demo should work with any modern browser. Click <em>Run</em> buttons in <a href="#examples">Examples</a> to experiment. Contacts, Calendar and System Information are used as placeholders only, and may not be applicable for this model.</p>
+with some <a href="#changes">changes</a>. The demo should work with any modern browser. Click <em>Run</em> buttons in
+<a href="#examples">Examples</a> to experiment. Contacts, Calendar and System Information are used as placeholders only,
+and may not be applicable for this model.</p>
 
 <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.</p>
 
@@ -63,28 +70,30 @@
     </div>
     <div class="example">
         <button onclick="evalScript()">Run</button>
-        <textarea id="example_custom">navigator.system.requestPermission(function(response) { log(JSON.stringify(response)); });</textarea>
+        <textarea id="example_custom">navigator.system.requestPermission(function(response) { log(response['system'].permission_level); });</textarea>
     </div>
 </div>
 
 <h2 id="changes">Changes to Feature Permissions Interface</h2>
 
-<p>navigator.foobar implements Permissions (instead of navigator implements Permissions), where foobar is {notifications|sensor|you-name-it|...}:</p>
+<h3>Option A: Each Device API implements Permissions (this demo)</h3>
+
+<p>E.g. <code>FoobarSensor implements Permissions</code>, where FoobarSensor is any applicable Device API:</p>
 <pre>
 interface FoobarSensor : Permissions {
 // ...
 }
 </pre>
 
-<p>Each interface that implements Permissions has a unique <code>feature</code> id:</p>
+<p>Each interface that implements Permissions has a unique <code>feature</code> id.</p>
 <pre>
 console.log(navigator.foobar.feature); // returns "foobar"
 </pre>
 
-<p><code>requestPermission()</code> can drop <code>feature</code> argument.
-If <code>requestPermission()</code> is invoked with undefined arguments the user
-interaction (such as displaying an infobar) is deferred until <code>requestPermission()</code>
-is invoked with a non-null callback:</p>
+<p><code>requestPermission()</code> can drop its first <code>feature</code> argument.
+If <code>requestPermission()</code> is invoked with undefined arguments the user interaction
+(such as displaying an infobar) is deferred until <code>requestPermission()</code> is invoked
+with a non-null callback (similar to the proxy design pattern):</p>
 <pre>
 navigator.foobar.requestPermission(); // returns nothing
 </pre>
@@ -99,23 +108,52 @@
 navigator.baz.requestPermission(function(response) { console.log(response); });
 </pre>
 
-<p>The callback <code>response</code> returned is an array of objects consisting of <code>feature</code>
-identifier and feature's <code>permission_level</code>. System default permission levels are used, 
-if user does not explicitly set the permission permission level. For example, if the user allows access to <code>foobar</code> but 
-leaves the <code>baz</code> permission level to default the following <code>response</code> is returned:</p>
+<p>The callback <code>response</code> returned is an object. The property names of the <code>response</code>
+object map to <code>feature</code> identifiers, the property values to feature's properties such as <code>permission_level</code>.
+System default permission levels are used, if the user does not explicitly set the permission permission level.
+For example, if the user allows access to <code>foobar</code> feature but leaves the <code>baz</code> feature
+permission level to default the following <code>response</code> is returned:</p>
 <pre>
-[
-  {feature: "foobar", permission_level: 2}, // USER_ALLOWED
-  {feature: "baz", permission_level: -1}    // DEFAULT_DENIED
-]
+{
+  'foobar': {'permission_level': 2}, // USER_ALLOWED
+  'baz': {'permission_level': -1}    // DEFAULT_DENIED
+}
 </pre>
 
 <p>If <code>feature</code> parameter passed to <code>permissionLevel(feature)</code> getter is undefined (i.e. not defined),
 the permission level of the interface that implements <code>Permissions</code> is returned:</p>
 <pre>
 navigator.foobar.permissionLevel(); // returns foobar's permission_level, e.g. 2 for USER_ALLOWED
-</pre
->
+</pre>
+
+<h3 id="capability">Option B: Capability-based Security-ish Way</h3>
+    
+<p>The API objects are exposed only if the user has given permission. The objects are passed by reference to the success callback:</p>
+<pre>
+function success(response) {
+    // case 1: the API is exposed only if the user has given permission
+    if (response.foobar !== 'undefined') {
+        response.foobar.doSomething(); // do something with the API
+    }
+
+    // case 2: the entry point is known e.g. navigator.baz, an equality comparison works
+    if (navigator.baz === response.baz) {
+        response.baz.doSomethingElse();
+    }
+}
+
+function error(response) {
+    // example response:
+    // {
+    //    'foobar': {'permission_level': -2}, // USER_DENIED
+    //    'baz': {'permission_level': -1}    // DEFAULT_DENIED
+    // }
+    console.log(response.foobar.permission_level); // logs '-2'
+}
+
+// the feature factory
+navigator.requestPermission(['foobar', 'baz'], success, error);
+    </pre>
 
 <h2>Misc Notes</h2>
 <ul>
@@ -134,9 +172,10 @@
 <h2>Misc UI Ideas</h2>
 <ul>
     <li>Drag and drop features/feature icons from the infobar/other chrome UI element to the web content/sink element.</li>
-    <li>Feature icons could display information about the action (such as contacts, e.g. their names, to be shared with the web page) while hovered/activated/dragged.</li>
+    <li>Feature icons could display information about the action (such as contacts, e.g. their names, to be shared with the
+        web page) while hovered/activated/dragged.</li>
     <li>Infobar could also have two sinks for allowed and denied features, features could be drag and dropped from one to another.</li>
 </ul>
-<div id="footer">by Anssi Kostiainen</div>
+<div id="footer">by <a href="http://twitter.com/anssik">Anssi Kostiainen</a></div>
 </body>
 </html>
\ No newline at end of file

Received on Tuesday, 22 March 2011 11:38:03 UTC