first pass for feedback
authorRobin Berjon <>
Fri, 27 May 2011 12:10:39 +0200
changeset 22 e3e3bf71a7e5
parent 21 fdd8a2141c4c
child 23 e181834c5380
first pass for feedback
--- a/proposals/request-feature/Overview.html	Fri May 27 11:06:40 2011 +0200
+++ b/proposals/request-feature/Overview.html	Fri May 27 12:10:39 2011 +0200
@@ -34,6 +34,7 @@
       <p class='note'>
         This document is currently more of a sketch of a proposal than a properly defined specification.
+        The terminology is loose in parts, and requirements need a fair amount of tightening.
     <section id='sotd'>
@@ -303,14 +304,39 @@
     <section id='modules'>
       <h2>Containing Access</h2>
+        The global scope in each module script is a proxy to the main scope such that the many host-defined
+        properties of <code>window</code> are available. However, script-defined properties are restricted to their
+        respective scopes.
-      <!-- 
-          XXX
-          - mostly reference
-          - can't write to these from the main scope
-          - can always shoot yourself in the foot, but it's harder
-      -->
+      <p>
+        The one addition to the module scope is the <code>exports</code> attribute, which is an empty object
+        which the module can modify in order to make functionality available to requiring scopes. The <code>exports</code>
+        object functions as defined in [[!COMMONJS]].
+      </p>
+      <p>
+        Naturally, a module can still shoot itself in the foot and expose functionality that would open the 
+        privileged features to XSS vulnerabilities, but it is nevertheless much less likely to happen by 
+        mistake. The simplest way of shooting oneself in the foot in a module would be as follows:
+      </p>
+      <pre class='example'>
+        // assuming geolocation privileges have been granted
+        exports.geolocation = navigator.geolocation;
+      </pre>
+      <p>
+        It is, however, difficult to protect against active stupidity — we only endeavour to contain the more
+        passive kind here.
+      </p>
+      <p>
+        A sketchy IDL is provided below. Questions are open as to whether <code>WindowProxy</code> is the
+        proper interface to inherit with, and as to the best way of specifying the access behaviour to the
+        requesting scope <code>window</code>.
+      </p>
+      <dl class='idl' title='[NoInterfaceObject] interface ModuleScope : WindowProxy'>
+        <dt>readonly attribute Object exports</dt>
+        <dd>
+          This empty object can be freely assigned to in order to define the module's interface.
+        </dd>
+      </dl>
     <section class='appendix'>