Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
[e] (0) Split Web Storage into two: Web Storage and Web Database.
git-svn-id: http://svn.whatwg.org/webapps@3418 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
Hixie committed Jul 15, 2009
1 parent 2b53fb2 commit c7c0437
Show file tree
Hide file tree
Showing 2 changed files with 137 additions and 79 deletions.
1 change: 0 additions & 1 deletion index
Expand Up @@ -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>

Expand Down
215 changes: 137 additions & 78 deletions source
Expand Up @@ -59350,12 +59350,7 @@ style/default.css</pre>

<h3>Structured client-side storage</h3> <!--START storage-->

<!--BOILERPLATE middle-w3c-api-intro-->
<!--BOILERPLATE middle-w3c-js-disclaimer-->

<h4 id="storage">Storing name/value pairs</h4>

<h5>Introduction</h5>
<h4>Introduction</h4>

<p><i>This section is non-normative.</i></p>

Expand Down Expand Up @@ -59459,6 +59454,13 @@ style/default.css</pre>
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> {
Expand Down Expand Up @@ -59831,13 +59833,8 @@ style/default.css</pre>
executing, other than in a way that is predictable by the script
itself.</p>




<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>
<!--END storage-->
<!--START database-->

<!-- Feature requests for future versions (v2):
* deleting databases
Expand All @@ -59848,7 +59845,7 @@ style/default.css</pre>
should delete it properly when it is deleted
-->

<h5>Introduction</h5>
<h4>Introduction</h4>

<p><i>This section is non-normative.</i></p>

Expand All @@ -59864,6 +59861,11 @@ have a variable and unknowable number of literals coming:
-->


<!--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
Expand Down Expand Up @@ -60749,17 +60751,23 @@ interface <dfn>SQLTransactionSync</dfn> {

</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
Expand All @@ -60769,9 +60777,11 @@ interface <dfn>SQLTransactionSync</dfn> {
<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
Expand All @@ -60785,8 +60795,14 @@ interface <dfn>SQLTransactionSync</dfn> {

<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
Expand All @@ -60797,28 +60813,37 @@ interface <dfn>SQLTransactionSync</dfn> {
<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
Expand All @@ -60831,35 +60856,55 @@ interface <dfn>SQLTransactionSync</dfn> {
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
Expand All @@ -60868,24 +60913,25 @@ interface <dfn>SQLTransactionSync</dfn> {
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
Expand All @@ -60904,11 +60950,11 @@ interface <dfn>SQLTransactionSync</dfn> {
<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>
Expand All @@ -60920,18 +60966,29 @@ interface <dfn>SQLTransactionSync</dfn> {
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
Expand All @@ -60953,7 +61010,7 @@ interface <dfn>SQLTransactionSync</dfn> {
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
Expand All @@ -60964,6 +61021,8 @@ interface <dfn>SQLTransactionSync</dfn> {
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
Expand All @@ -60986,7 +61045,7 @@ interface <dfn>SQLTransactionSync</dfn> {
and to never construct SQL statements on the fly.</p>


<!--END storage-->
<!--END database-->



Expand Down Expand Up @@ -68374,8 +68433,8 @@ interface <dfn>SharedWorker</dfn> : <span>AbstractWorker</span> {

<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>



Expand Down

0 comments on commit c7c0437

Please sign in to comment.