[html5] r4119 - [e] (0) Update the WHATWG complete spec to handle the bits where local storage a [...]
whatwg at whatwg.org
whatwg at whatwg.org
Mon Oct 12 18:45:59 PDT 2009
Author: ianh
Date: 2009-10-12 18:45:58 -0700 (Mon, 12 Oct 2009)
New Revision: 4119
Modified:
complete.html
source
Log:
[e] (0) Update the WHATWG complete spec to handle the bits where local storage and database specs had common text.
Modified: complete.html
===================================================================
--- complete.html 2009-10-13 01:37:45 UTC (rev 4118)
+++ complete.html 2009-10-13 01:45:58 UTC (rev 4119)
@@ -57365,12 +57365,9 @@
<h4 id=disk-space><span class=secno>6.12.6 </span>Disk space</h4>
<p>User agents should limit the total amount of space allowed for
+ these storage features.
- storage areas.
-
- databases.
-
</p>
<p>User agents should guard against sites storing data under the
@@ -57408,8 +57405,9 @@
local storage area
+ or its
- client-side database
+ client-side databases
to track a user across multiple sessions, building a profile of the
user's interests to allow for highly targeted advertising. In
@@ -57429,6 +57427,7 @@
the <code title=dom-localStorage><a href=#dom-localstorage>localStorage</a></code> objects
+ and
the database objects
@@ -57459,8 +57458,10 @@
<p>However, this also puts the user's data at risk.</p>
+
<!--v2 consider adding an explicit way for sites to state when
data should expire, as in localStorage.expireData(365); -->
+
</dd>
@@ -57469,16 +57470,11 @@
<p>If users attempt to protect their privacy by clearing cookies
without also clearing data stored in the
-
+ local storage area and relevant databases,
- persistent storage
-
- database
-
-
- feature, sites can defeat those attempts by using the two features
- as redundant backup for each other. User agents should present the
+ 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>
@@ -57489,6 +57485,7 @@
local storage areas
+ and
databases
@@ -57573,12 +57570,9 @@
from that domain. To mitigate this, pages can use SSL. Pages using
SSL can be sure that only pages using SSL that have certificates
identifying them as being from the same domain can access their
+ storage areas and databases.
- storage areas.
-
- databases.
-
</p>
@@ -57586,12 +57580,9 @@
<p>Different authors sharing one host name, for example users
hosting content on <code>geocities.com</code>, all share one
+ common set of storage objects and databases.
- persistent storage object.
-
- set of databases.
-
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
Modified: source
===================================================================
--- source 2009-10-13 01:37:45 UTC (rev 4118)
+++ source 2009-10-13 01:45:58 UTC (rev 4119)
@@ -64854,11 +64854,16 @@
<h4>Disk space</h4>
<p>User agents should limit the total amount of space allowed for
+ <!--END complete-->
<!--END database-->
storage areas.
<!--END storage-->
<!--START database-->
databases.
+ <!--END database-->
+ <!--START complete-->
+ these storage features.
+ <!--START database-->
<!--START storage-->
</p>
@@ -64897,8 +64902,9 @@
<!--END database-->
local storage area
<!--END storage-->
+ or its
<!--START database-->
- client-side database
+ client-side databases
<!--START storage-->
to track a user across multiple sessions, building a profile of the
user's interests to allow for highly targeted advertising. In
@@ -64920,6 +64926,7 @@
<!--END database-->
the <code title="dom-localStorage">localStorage</code> objects
<!--END storage-->
+ and
<!--START database-->
the database objects
<!--START storage-->
@@ -64950,8 +64957,10 @@
<p>However, this also puts the user's data at risk.</p>
+ <!--END database-->
<!--v2 consider adding an explicit way for sites to state when
data should expire, as in localStorage.expireData(365); -->
+ <!--START database-->
</dd>
@@ -64960,16 +64969,19 @@
<p>If users attempt to protect their privacy by clearing cookies
without also clearing data stored in the
-
+ <!--END complete-->
<!--END database-->
- persistent storage
+ local storage area,
<!--END storage-->
<!--START database-->
- database
+ relevant databases,
+ <!--END database-->
+ <!--START complete-->
+ local storage area and relevant databases,
+ <!--START database-->
<!--START storage-->
-
- feature, sites can defeat those attempts by using the two features
- as redundant backup for each other. User agents should present the
+ 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
@@ -64981,6 +64993,7 @@
<!--END database-->
local storage areas
<!--END storage-->
+ and
<!--START database-->
databases
<!--START storage-->
@@ -65067,11 +65080,16 @@
from that domain. To mitigate this, pages can use SSL. Pages using
SSL can be sure that only pages using SSL that have certificates
identifying them as being from the same domain can access their
+ <!--END complete-->
<!--END database-->
storage areas.
<!--END storage-->
<!--START database-->
databases.
+ <!--END database-->
+ <!--START complete-->
+ storage areas and databases.
+ <!--START database-->
<!--START storage-->
</p>
@@ -65080,11 +65098,16 @@
<p>Different authors sharing one host name, for example users
hosting content on <code>geocities.com</code>, all share one
+ <!--END complete-->
<!--END database-->
- persistent storage object.
+ local storage object.
<!--END storage-->
<!--START database-->
set of databases.
+ <!--END database-->
+ <!--START complete-->
+ common set of storage objects and databases.
+ <!--START database-->
<!--START storage-->
There is no feature to restrict the access by pathname. Authors on
shared hosts are therefore recommended to avoid using these
More information about the Commit-Watchers
mailing list