[html5] r3418 - [e] (0) Split Web Storage into two: Web Storage and Web Database.
whatwg at whatwg.org
whatwg at whatwg.org
Wed Jul 15 03:53:37 PDT 2009
Author: ianh
Date: 2009-07-15 03:53:36 -0700 (Wed, 15 Jul 2009)
New Revision: 3418
Modified:
index
source
Log:
[e] (0) Split Web Storage into two: Web Storage and Web Database.
Modified: index
===================================================================
--- index 2009-07-15 09:05:54 UTC (rev 3417)
+++ index 2009-07-15 10:53:36 UTC (rev 3418)
@@ -133,7 +133,6 @@
<p>This specification is intended to replace (be the new version of)
what was previously the HTML4, XHTML 1.x, and DOM2 HTML
specifications.</p>
-<!--START html5-->
<h3 class="no-num no-toc" id=stability-0>Stability</h3>
Modified: source
===================================================================
--- source 2009-07-15 09:05:54 UTC (rev 3417)
+++ source 2009-07-15 10:53:36 UTC (rev 3418)
@@ -59350,13 +59350,8 @@
<h3>Structured client-side storage</h3> <!--START storage-->
- <!--BOILERPLATE middle-w3c-api-intro-->
- <!--BOILERPLATE middle-w3c-js-disclaimer-->
+ <h4>Introduction</h4>
- <h4 id="storage">Storing name/value pairs</h4>
-
- <h5>Introduction</h5>
-
<p><i>This section is non-normative.</i></p>
<p>This specification introduces two related mechanisms, similar to
@@ -59459,6 +59454,13 @@
convert it to a string.</p>
+
+ <!--BOILERPLATE middle-w3c-api-intro-->
+ <!--BOILERPLATE middle-w3c-js-disclaimer-->
+
+
+ <h4 id="storage">The API</h4>
+
<h5>The <code>Storage</code> interface</h5>
<pre class="idl">interface <dfn>Storage</dfn> {
@@ -59831,14 +59833,9 @@
executing, other than in a way that is predictable by the script
itself.</p>
+ <!--END storage-->
+ <!--START database-->
-
-
- <h4 id="sql"><!--XXX Database storage-->Structured storage</h4>
-
- <p class="XXX">The working group is currently debating whether SQL
- is the right abstraction for this API.</p>
-
<!-- Feature requests for future versions (v2):
* deleting databases
* determining how much storage room is left
@@ -59848,7 +59845,7 @@
should delete it properly when it is deleted
-->
- <h5>Introduction</h5>
+ <h4>Introduction</h4>
<p><i>This section is non-normative.</i></p>
@@ -59864,6 +59861,11 @@
-->
+ <!--BOILERPLATE middle-w3c-api-intro-->
+ <!--BOILERPLATE middle-w3c-js-disclaimer-->
+
+ <h4 id="sql">The API</h4>
+
<h5>Databases</h5>
<p>Each <i>origin</i> has an associated set of databases. Each
@@ -60749,17 +60751,23 @@
</table>
+ <!--START storage-->
-
<h4>Disk space</h4>
<p>User agents should limit the total amount of space allowed for
- storage areas and databases.</p>
+ <!--END database-->
+ storage areas.
+ <!--END storage-->
+ <!--START database-->
+ databases.
+ <!--START storage-->
+ </p>
- <p>User agents should guard against sites storing data in the
- storage areas or databases of 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>
+ <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>
<p>User agents may prompt the user when quotas are reached, allowing
the user to grant a site more space. This enables sites to store
@@ -60769,9 +60777,11 @@
<p>User agents should allow users to see how much space each domain
is using.</p>
+ <!--END database-->
<!--<p>If the storage area space limit is reached during a <code
title="dom-Storage-setItem">setItem()</code> call, the method will
raise an exception.</p>-->
+ <!--START database-->
<p>A mostly arbitrary limit of five megabytes per
<span>origin</span> is recommended. Implementation feedback is
@@ -60785,8 +60795,14 @@
<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 or in its client-side database to
- track a user across multiple sessions, building a profile of the
+ stored in its
+ <!--END database-->
+ local storage area
+ <!--END storage-->
+ <!--START database-->
+ client-side database
+ <!--START storage-->
+ 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
@@ -60797,28 +60813,37 @@
<p>There are a number of techniques that can be used to mitigate the
risk of user tracking:</p>
- <ul>
+ <dl>
- <li>
+ <dt>Blocking third-party storage</dt>
+ <dd>
- <p>Blocking third-party storage: user agents may restrict access
- to the <code title="dom-localStorage">localStorage</code> and
- database 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>
+ <p>User agents may restrict access to
+ <!--END database-->
+ the <code title="dom-localStorage">localStorage</code> objects
+ <!--END storage-->
+ <!--START database-->
+ the database objects
+ <!--START storage-->
+ 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>
- </li>
+ </dd>
- <li>
+ <dt>Expiring stored data</dt>
+ <dd>
- <p>Expiring stored data: user agents may automatically delete
- stored data after a period of time.</p>
+ <p>User agents may automatically delete stored data after a period
+ of time.</p>
+ <!--END database-->
<p>For example, a user agent could treat third-party local
storage areas as session-only storage, deleting the data once the
user had closed all the <span>browsing contexts</span> that could
access it.</p>
+ <!--START database-->
<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
@@ -60831,35 +60856,55 @@
data should expire? as in
localStorage.expireData(365); ? -->
- </li>
+ </dd>
- <li>
+ <dt>Treating persistent storage as cookies</dt>
+ <dd>
- <p>Treating persistent storage as cookies: user agents should
- present the persistent storage and database features to the user
- in a way that does not distinguish them from HTTP session
- cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
+ <p>User agents should present the
+ <!--END database-->
+ persistent storage feature
+ <!--END storage-->
+ <!--START database-->
+ database feature
+ <!--START storage-->
+ to the user in a way that does not distinguish them from HTTP
+ session cookies. <a href="#refsRFC2109">[RFC2109]</a> <a
href="#refsRFC2965">[RFC2965]</a></p>
- <p>This might encourage users to view persistent storage with
- healthy suspicion.</p>
+ <p>This might encourage users to view such storage with healthy
+ suspicion.</p>
- </li>
+ </dd>
- <li>
+ <dt>Site-specific white-listing of access to
+ <!--END database-->
+ local storage areas
+ <!--END storage-->
+ <!--START database-->
+ databases
+ <!--START storage-->
+ </dt>
+ <dd>
- <p>Site-specific white-listing of access to local storage areas
- and databases: 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 and databases.</p>
+ <!--END database-->
+ <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>
+ <!--END storage-->
+ <!--START database-->
+ <p>User agents may require the user to authorize access to
+ databases before a site can use the feature.</p>
+ <!--START storage-->
- </li>
+ </dd>
- <li>
+ <dt>Origin-tracking of stored data</dt>
+ <dd>
- <p><span>Origin</span>-tracking of persistent storage data: user
- agents may record the origins of sites that contained content from
- third-party origins that caused data to be stored.</p>
+ <p>User agents may record the <span title="origin">origins</span>
+ of sites that contained content from third-party origins that
+ caused data to be stored.</p>
<p>If this information is then used to present the view of data
currently in persistent storage, it would allow the user to make
@@ -60868,24 +60913,25 @@
this domain from ever storing data again"), the user can restrict
the use of persistent storage to sites that he trusts.</p>
- </li>
+ </dd>
- <li>
+ <dt>Shared blacklists</dt>
+ <dd>
- <p>Shared blacklists: user agents may allow users to share their
- persistent storage domain blacklists.</p>
+ <p>User agents may allow users to share their persistent storage
+ domain blacklists.</p>
<p>This would allow communities to act together to protect their
privacy.</p>
- </li>
+ </dd>
- </ul>
+ </dl>
- <p>While these suggestions prevent trivial use of these APIs for
- user tracking, they do not block it altogether. Within a single
- domain, a site can continue to track the user during a session, and
- can then pass all this information to the third party along with any
+ <p>While these suggestions prevent trivial use of this API for user
+ tracking, they do not block it altogether. Within a single domain, a
+ site can continue to track the user during a session, and can then
+ pass all this information to the third party along with any
identifying information (names, credit card numbers, addresses)
obtained by the site. If a third party cooperates with multiple
sites to obtain such information, a profile can still be
@@ -60904,11 +60950,11 @@
<h5>Cookie resurrection</h5>
<p>If the user interface for persistent storage presents data in the
- persistent storage features separately from data in HTTP session
- cookies, then users are likely to delete data in one and not the
- other. This would allow sites to use the two features as redundant
- backup for each other, defeating a user's attempts to protect his
- privacy.</p>
+ persistent storage features described in this specification
+ separately from data in HTTP session cookies, then users are likely
+ to delete data in one and not the other. This would allow sites to
+ use the two features as redundant backup for each other, defeating a
+ user's attempts to protect his privacy.</p>
<h4>Security</h4>
@@ -60920,18 +60966,29 @@
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
- local storage areas and databases.</p>
+ <!--END database-->
+ storage areas.
+ <!--END storage-->
+ <!--START database-->
+ databases.
+ <!--START storage-->
+ </p>
<h5>Cross-directory attacks</h5>
<p>Different authors sharing one host name, for example users
hosting content on <code>geocities.com</code>, all share one
- persistent storage object and one set of databases. There is no
- feature to restrict the access by pathname. Authors on shared hosts
- are therefore recommended to avoid using the persistent storage
- features, as it would be trivial for other authors to read from and
- write to the same storage area or database.</p>
+ <!--END database-->
+ persistent storage object.
+ <!--END storage-->
+ <!--START database-->
+ set of databases.
+ <!--START storage-->
+ 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>
<p class="note">Even if a path-restriction feature was made
available, the usual DOM scripting security model would make it
@@ -60953,7 +61010,7 @@
work-in-progress confidential documents stored by a word-processing
site could be examined by the site of a competing company.</p>
- <p>Letting third-party sites write data to the storage areas of
+ <p>Letting third-party sites write data to the persistent storage of
other domains can result in <em>information spoofing</em>, which is
equally dangerous. For example, a hostile site could add items to a
user's wishlist; or a hostile site could set a user's session
@@ -60964,6 +61021,8 @@
in this specification is important for user security.</p>
+ <!--END storage-->
+
<h5>SQL and user agents</h5>
<p>User agent implementors are strongly encouraged to audit all
@@ -60986,7 +61045,7 @@
and to never construct SQL statements on the fly.</p>
- <!--END storage-->
+ <!--END database-->
@@ -68374,8 +68433,8 @@
<p>The <code title="dom-opendatabase">openDatabase()</code> and
<code title="dom-opendatabase-sync">openDatabaseSync()</code>
- methods are defined in the Web Storage specification. <a
- href="#refsWEBSTORAGE">[WEBSTORAGE]</a></p>
+ methods are defined in the Web Database specification. <a
+ href="#refsWEBDATABASE">[WEBDATABASE]</a></p>
More information about the Commit-Watchers
mailing list