- From: poot <cvsmail@w3.org>
- Date: Tue, 11 Jan 2011 21:44:17 -0500
- To: public-html-diffs@w3.org
webstorage; hixie: Purge references to Web SQL Database. (whatwg r5736)
http://dev.w3.org/cvsweb/html5/webstorage/Overview.html?r1=1.155&r2=1.156&f=h
http://html5.org/tools/web-apps-tracker?from=5735&to=5736
===================================================================
RCS file: /sources/public/html5/webstorage/Overview.html,v
retrieving revision 1.155
retrieving revision 1.156
diff -u -d -r1.155 -r1.156
--- Overview.html 14 Dec 2010 02:07:45 -0000 1.155
+++ Overview.html 1 Jan 2011 06:34:04 -0000 1.156
@@ -229,7 +229,7 @@
<p><a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"></a></p>
<h1>Web Storage</h1>
- <h2 class="no-num no-toc" id="editor-s-draft-14-december-2010">Editor's Draft 14 December 2010</h2>
+ <h2 class="no-num no-toc" id="editor-s-draft-1-january-2011">Editor's Draft 1 January 2011</h2>
<dl><dt>Latest Published Version:</dt>
<dd><a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></dd>
<dt>Latest Editor's Draft:</dt>
@@ -322,7 +322,7 @@
</dl><p>The W3C <a href="http://www.w3.org/2008/webapps/">Web Applications
Working Group</a> is the W3C working group responsible for this
specification's progress along the W3C Recommendation track.
- This specification is the 14 December 2010 Editor's Draft.
+ This specification is the 1 January 2011 Editor's Draft.
</p><!-- required patent boilerplate --><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42538/status" rel="disclosure">public list of
any patent disclosures</a> made in connection with the deliverables
@@ -729,9 +729,7 @@
various properties of that object, cannot change while a script is
executing, other than in a way that is predictable by the script
itself.<h2 id="disk-space"><span class="secno">5 </span>Disk space</h2><p>User agents should limit the total amount of space allowed for
-
- storage areas.
- <p>User agents should guard against sites storing data under the
+ storage areas.<p>User agents should guard against sites storing data under the
origins other affiliated sites, e.g. storing up to the limit in
a1.example.com, a2.example.com, a3.example.com, etc, circumventing
the main example.com storage limit.<p>User agents may prompt the user when quotas are reached, allowing
@@ -745,25 +743,20 @@
welcome and will be used to update this suggestion in the
future.<h2 id="privacy"><span class="secno">6 </span>Privacy</h2><h3 id="user-tracking"><span class="secno">6.1 </span>User tracking</h3><p>A third-party advertiser (or any entity capable of getting
content distributed to multiple sites) could use a unique identifier
- stored in its
-
- local storage area
- to track a user across multiple sessions, building a profile of the
- user's interests to allow for highly targeted advertising. In
- conjunction with a site that is aware of the user's real identity
- (for example an e-commerce site that requires authenticated
- credentials), this could allow oppressive groups to target
- individuals with greater accuracy than in a world with purely
- anonymous Web usage.<p>There are a number of techniques that can be used to mitigate the
+ stored in its local storage area to track a user across multiple
+ sessions, building a profile of the user's interests to allow for
+ highly targeted advertising. In conjunction with a site that is
+ aware of the user's real identity (for example an e-commerce site
+ that requires authenticated credentials), this could allow
+ oppressive groups to target individuals with greater accuracy than
+ in a world with purely anonymous Web usage.<p>There are a number of techniques that can be used to mitigate the
risk of user tracking:<dl><dt>Blocking third-party storage</dt>
<dd>
- <p>User agents may restrict access to
-
- the <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> objects
- to scripts originating at the domain of the top-level document of
- the <span>browsing context</span>, for instance denying access to
- the API for pages from other domains running in
+ <p>User agents may restrict access to the <code title="dom-localStorage"><a href="#dom-localstorage">localStorage</a></code> objects to scripts
+ originating at the domain of the top-level document of the
+ <span>browsing context</span>, for instance denying access to the
+ API for pages from other domains running in
<code>iframe</code>s.</p>
</dd>
@@ -774,12 +767,10 @@
<p>User agents may, if so configured by the user, automatically
delete stored data after a period of time.</p>
-
<p>For example, a user agent could be configured to treat
third-party local storage areas as session-only storage, deleting
the data once the user had closed all the <span title="browsing
context">browsing contexts</span> that could access it.</p>
-
<p>This can restrict the ability of a site to track a user, as the
site would then only be able to track the user across multiple
@@ -791,10 +782,8 @@
risk, if the user does not fully understand the implications of
data expiration.</p>
-
<!--v2 consider adding an explicit way for sites to state when
data should expire, as in localStorage.expireData(365); -->
-
</dd>
@@ -802,24 +791,19 @@
<dd>
<p>If users attempt to protect their privacy by clearing cookies
- without also clearing data stored in the
-
- local storage area,
- sites can defeat those attempts by using the two features as
- redundant backup for each other. User agents should present the
- interfaces for clearing these in a way that helps users to
- understand this possibility and enables them to delete data in all
- persistent storage features simultaneously. <a href="#refsCOOKIES">[COOKIES]</a></p>
+ without also clearing data stored in the local storage area, sites
+ can defeat those attempts by using the two features as redundant
+ backup for each other. User agents should present the interfaces
+ for clearing these in a way that helps users to understand this
+ possibility and enables them to delete data in all persistent
+ storage features simultaneously. <a href="#refsCOOKIES">[COOKIES]</a></p>
</dd>
- <dt>Site-specific white-listing of access to
-
- local storage areas
- </dt>
+ <dt>Site-specific white-listing of access to local storage
+ areas</dt>
<dd>
-
<p>User agents may allow sites to access session storage areas in
an unrestricted manner, but require the user to authorize access
to local storage areas.</p>
@@ -876,16 +860,12 @@
from that domain. To mitigate this, pages can use TLS. Pages using
TLS can be sure that only pages using TLS that have certificates
identifying them as being from the same domain can access their
-
- storage areas.
- <h3 id="cross-directory-attacks"><span class="secno">7.2 </span>Cross-directory attacks</h3><p>Different authors sharing one host name, for example users
- hosting content on <code>geocities.com</code>, all share one
-
- local storage object.
- There is no feature to restrict the access by pathname. Authors on
- shared hosts are therefore recommended to avoid using these
- features, as it would be trivial for other authors to read the data
- and overwrite it.<p class="note">Even if a path-restriction feature was made
+ storage areas.<h3 id="cross-directory-attacks"><span class="secno">7.2 </span>Cross-directory attacks</h3><p>Different authors sharing one host name, for example users
+ hosting content on <code>geocities.com</code>, all share one local
+ storage object. There is no feature to restrict the access by
+ pathname. Authors on shared hosts are therefore recommended to avoid
+ using these features, as it would be trivial for other authors to
+ read the data and overwrite it.<p class="note">Even if a path-restriction feature was made
available, the usual DOM scripting security model would make it
trivial to bypass this protection and access the data from any
path.<h3 id="implementation-risks"><span class="secno">7.3 </span>Implementation risks</h3><p>The two primary risks when implementing these persistent storage
Received on Wednesday, 12 January 2011 02:44:20 UTC