<span class="gmail_quote"></span>On 6/1/07, <b class="gmail_sendername">Gervase Markham</b> <<a href="mailto:gerv@mozilla.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gerv@mozilla.org</a>> wrote:

<div><span class="q"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Ian Hickson wrote:<br>> Yeah, this is mentioned in the security section:<br>><br>>    <a href="http://www.whatwg.org/specs/web-apps/current-work/#security5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.whatwg.org/specs/web-apps/current-work/#security5

</a><br>><br>> ...along with recommended solutions to mitigate it.<br><br>All of those mitigation measures seem to be non-ideal.</blockquote></span><div><br>I disagree. The third item in the list describes the solution which I had in mind:

<br><br><div style="margin-left: 40px;">"Blocking access to the top-level domain ("<a href="http://www.whatwg.org/specs/web-apps/current-work/#public0" title="public storage area" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

public</a>") storage areas: user agents may

     prevent domains from storing data in and reading data from the top-level

     domain entries in the <code title="dom-globalStorage"><a href="http://www.whatwg.org/specs/web-apps/current-work/#globalstorage" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">globalStorage</a>

</code> object. For example, content at the

     domain <code><a href="http://www.example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.example.com</a></code> would be allowed to access

<code><a href="http://example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">example.com</a></code><code> </code> data but not  <code>com</code> data." </div> That effectively restricts the storage to a single domain and is in line with how cookies work today.

<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Have any browser makers expressed opinions on which of them they are

planning to implement?

</blockquote></span><div><br>That's a good question, but I'm not sure if it's one that the WHATWG can answer? I do know that Firefox 2 already implements the Storage spec. Info on that here:<br><br><a href="http://developer.mozilla.org/en/docs/DOM:Storage" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://developer.mozilla.org/en/docs/DOM:Storage</a><br></div><br>I wasn't able to find any docs that describe the Storage security model used in Gecko, so I ran a few tests. What I found was that any attempt to access globalStorage[''] or globalStorage['com'] from the context of a website resulted in a security error. You can try the test for yourself here:

<br><br><a href="http://java.dnsalias.com/temp/storage.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://java.dnsalias.com/temp/storage.html</a><br><br>After loading the page, open the Javascript Error console. You should see a security exception listed. 

<br>

<br>I presume that the restrictions are relaxed for signed pages as well as those that are run at a higher privilege level. (e.g. XULRunner apps.)<span class="q"><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Is there a document somewhere outlining the actual benefits of this<br>feature, even as potentially restricted?<br></blockquote></span></div><br>The specification has this explanation: <span style="font-style: italic;">"Web

   applications may wish to store megabytes of user data, such as entire

   user-authored documents or a user's mailbox, on the clientside for

performance reasons." And it's not just performance reasons. If I wanted to work on a Google Spreadsheet on a plane, for example, offline caching of the data would allow me to continue my work without an internet connection. Then when I reconnect to the internet and load the document, the client would sync its stored changes with the server.

My understanding is that this is Google's justification for their new "Gears" product. Which is basically the same as the WHATWG Storage + Database specifications, but with auto-sync and an incompatible API.

<br><br>Thanks,<br><span class="sg">Jerason<br>

</span>