W3C home > Mailing lists > Public > public-html-commits@w3.org > January 2011

html5/webstorage Overview.html,1.155,1.156

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Sat, 01 Jan 2011 06:34:06 +0000
To: public-html-commits@w3.org
Message-Id: <E1PYv2U-0003o8-Dt@lionel-hutz.w3.org>
Update of /sources/public/html5/webstorage
In directory hutz:/tmp/cvs-serv14622

Modified Files:
	Overview.html 
Log Message:
Purge references to Web SQL Database. (whatwg r5736)

Index: Overview.html
===================================================================
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 Saturday, 1 January 2011 06:34:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 1 January 2011 06:37:44 GMT