98
[NoInterfaceObject]
interface WindowSessionStorage {
readonly attribute Storage
sessionStorage
;
};
Window
implements WindowSessionStorage
;
ThesessionStorageattribute represents the set of storage areas specific to the currenttop-level browsing contextp749
.
Eachtop-level browsing contextp749
has a unique set of session storage areas, one for eachoriginp767
.
User agents should not expire data from a browsing context's session storage areas, but may do so when the user requests that such data be
deleted, or when the UA detects that it has limited storage space, or for security reasons. User agents should always avoid deleting data while a
script that could access that data is running. When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user)
the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever
be subsequently retrieved.
When a newDocumentp103
is created in abrowsing contextp748
which has atop-level browsing contextp749
, the user agent must check to see if that
top-level browsing contextp749
has a session storage area for that document'soriginp767
. If it does, then that is theDocumentp103
's assigned session
storage area. If it does not, a new storage area for that document'soriginp767
must be created, and thenthatis theDocumentp103
's assigned
session storage area. ADocumentp103
's assigned storage area does not change during the lifetime of aDocumentp103
.
ThesessionStoragep946
attribute must return aStoragep945
object associated with theDocumentp103
's assigned session storage area, if any,
or null if there isn't one. EachDocumentp103
object must have a separate object for itsWindowp758
'ssessionStoragep946
attribute.
When a newtop-level browsing contextp749
is created by cloning an existingbrowsing contextp748
, the new browsing context must start with the
same session storage areas as the original, but the two sets must from that point on be considered separate, not affecting each other in any way.
When a newtop-level browsing contextp749
is created by ascriptp827
in an existingbrowsing contextp748
, or by the user following a link in an existing
browsing context, or in some other way related to a specificDocumentp103
, and the creation is nota new start for session storage, then the session
storage area of theoriginp767
of thatDocumentp103
must be copied into the new browsing context when it is created. From that point on, however,
the two session storage areas must be considered separate, not affecting each other in any way.
When thesetItem()p945
,removeItem()p945
, andclear()p945
methods are called on aStoragep945
objectxthat is associated with a session
storage area, if the methods did not throw an exception or "do nothing" as defined above, then for everyDocumentp103
object whoseWindowp758
object'ssessionStoragep946
attribute'sStoragep945
object is associated with the same storage area, other thanx,send a storage
notificationp947
.
[NoInterfaceObject]
interface WindowLocalStorage {
readonly attribute Storage
localStorage
;
};
Window
implements WindowLocalStorage
;
ThelocalStorageobject provides aStoragep945
object for anoriginp767
.
User agents must have a set of local storage areas, one for eachoriginp767
.
User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should
always avoid deleting data while a script that could access that data is running.
The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support
resuming sessions after a restart.
Note
In the case of aniframep308
being moved to anotherDocumentp103
, the nested browsing context is destroyed and a new one created.
Note
IDL
IDL
11.2.2 ThesessionStoragep946
attribute
11.2.3 ThelocalStoragep946
attribute
p30
946
116
When thelocalStoragep946
attribute is accessed, the user agent must run the following steps, which are known as theStorageobject
initialisation steps:
1. The user agent may throw a"SecurityError"
DOMException
and abort these steps instead of returning aStoragep945
object if the
request violates a policy decisions (e.g. if the user agent is configured to not allow the page to persist data).
2. If theDocumentp103
'soriginp767
is anopaque originp767
, then throw a"SecurityError"
DOMException
and abort these steps.
3. Check to see if the user agent has allocated a local storage area for theoriginp767
of theDocumentp103
of theWindowp758
object on
which the attribute was accessed. If it has not, create a new storage area for thatoriginp767
.
4. Return theStoragep945
object associated with that origin's local storage area. EachDocumentp103
object must have a separate object
for itsWindowp758
'slocalStoragep946
attribute.
When thesetItem()p945
,removeItem()p945
, andclear()p945
methods are called on aStoragep945
objectxthat is associated with a local
storage area, if the methods did not throw an exception or "do nothing" as defined above, then for everyDocumentp103
object whoseWindowp758
object'slocalStoragep946
attribute'sStoragep945
object is associated with the same storage area, other thanx,send a storage notificationp947
.
Thestoragep1155
event is fired on aDocumentp103
'sWindowp758
object when a storage area changes, as described in the previous two sections
(for session storagep946
,for local storagep947
).
When a user agent is tosend a storage notificationfor aDocumentp103
, the user agent mustqueue a taskp843
tofirep44
atrustedp44
event with the
namestoragep945
, which does not bubble and is not cancelable, and which uses theStorageEventp947
interface, at theDocumentp103
object's
Windowp758
object.
Thetask sourcep843
for these tasks is theDOM manipulation task sourcep846
.
If the event is being fired due to an invocation of thesetItem()p945
orremoveItem()p945
methods, the event must have itskeyp948
attribute
initialised to the name of the key in question, itsoldValuep948
attribute initialised to the old value of the key in question, or null if the key is newly
added, and itsnewValuep948
attribute initialised to the new value of the key in question, or null if the key was removed.
Otherwise, if the event is being fired due to an invocation of theclear()p945
method, the event must have itskeyp948
,oldValuep948
, and
newValuep948
attributes initialised to null.
In addition, the event must have itsurlp948
attribute initialised to theURL
of the document whoseStoragep945
object was affected; and its
storageAreap948
attribute initialised to theStoragep945
object from theWindowp758
object of the targetDocumentp103
that represents the same
kind ofStoragep945
area as was affected (i.e. session or local).
11.2.4.1 TheStorageEventp947
interface
[Constructor(DOMString type, optional l StorageEventInit
eventInitDict)]
interface StorageEvent : : Event
{
readonly attribute DOMString? key
;
readonly attribute DOMString? oldValue
;
readonly attribute DOMString? newValue
;
readonly attribute USVString url
;
ThelocalStoragep946
attribute provides access to shared state. This specification does not define the interaction with
other browsing contexts in a multiprocess user agent, and authors are encouraged to assume that there is no locking
mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the
new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same
time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
⚠Warning!
Such aDocumentp103
object is not necessarilyfully activep749
, but events fired on such objects are ignored by theevent loopp842
until the
Documentp103
becomesfully activep749
again.
Note
IDL
11.2.4 Thestoragep1155
event
947
49
readonly attribute Storage
? storageArea
;
};
dictionary StorageEventInit : : EventInit
{
DOMString? key = null;
DOMString? oldValue = null;
DOMString? newValue = null;
USVString url = "";
Storage
? storageArea = null;
};
Thekeyattribute must return the value it was initialised to. It represents the key being changed.
TheoldValueattribute must return the value it was initialised to. It represents the old value of the key being changed.
ThenewValueattribute must return the value it was initialised to. It represents the new value of the key being changed.
Theurlattribute must return the value it was initialised to. It represents theURL
of the document whose key changed.
ThestorageAreaattribute must return the value it was initialised to. It represents theStoragep945
object that was affected.
11.3 Disk space
User agents should limit the total amount of space allowed for storage areas, because hostile authors could otherwise use this feature to exhaust
the user's available disk space.
User agents should guard against sites storing data under their origin's 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.
User agents may prompt the user when quotas are reached, allowing the user to grant a site more space. This enables sites to store many user-
created documents on the user's computer, for instance.
User agents should allow users to see how much space each domain is using.
A mostly arbitrary limit of five megabytes peroriginp767
is suggested. Implementation feedback is welcome and will be used to update this
suggestion in the future.
For predictability, quotas should be based on the uncompressed size of data stored.
11.4 Privacy
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.
There are a number of techniques that can be used to mitigate the risk of user tracking:
Blocking third-party storage
User agents may restrict access to thelocalStoragep946
objects to scripts originating at the domain of theactive documentp748
of thetop-
level browsing contextp749
, for instance denying access to the API for pages from other domains running iniframep308
s.
Expiring stored data
User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time.
11.4.1 User tracking
948
41
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 thebrowsing contextsp748
that could access it.
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 sessions when they
authenticate with the site itself (e.g. by making a purchase or logging in to a service).
However, this also reduces the usefulness of the API as a long-term storage mechanism. It can also put the user's data at risk, if the user
does not fully understand the implications of data expiration.
Treating persistent storage as cookies
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.
[COOKIES]p1158
Site-specific safelisting of access to local storage areas
User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorise access to local
storage areas.
Origin-tracking of stored data
User agents may record theoriginsp767
of sites that contained content from third-party origins that caused data to be stored.
If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions
about which parts of the persistent storage to prune. Combined with a blocklist ("delete this data and prevent this domain from ever storing
data again"), the user can restrict the use of persistent storage to sites that they trust.
Shared blocklists
User agents may allow users to share their persistent storage domain blocklists.
This would allow communities to act together to protect their privacy.
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 created.
However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session
identifiers in URLs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This
information can then be shared with other sites, using visitors' IP addresses and other user-specific data (e.g. user-agent headers and configuration
settings) to combine separate sessions into coherent user profiles.
User agents should treat persistently stored data as potentially sensitive; it's quite possible for e-mails, calendar appointments, health records, or
other confidential documents to be stored in this mechanism.
To this end, user agents should ensure that when deleting data, it is promptly deleted from the underlying storage.
11.5 Security
Because of the potential for DNS spoofing attacks, one cannot guarantee that a host claiming to be in a certain domain really is from that domain.
To mitigate this, pages can use TLS. Pages using TLS can be sure that only the user, software working on behalf of the user, and other pages
using TLS that have certificates identifying them as being from the same domain, can access their storage areas.
11.4.2 Sensitivity of data
11.5.1 DNS spoofing attacks
949
19
Different authors sharing one host name, for example users hosting content on the now defunctgeocities.com, all share one local storage
object. There is no feature to restrict the access by pathname. Authors on shared hosts are therefore urged to avoid using these features, as it
would be trivial for other authors to read the data and overwrite it.
The two primary risks when implementing these persistent storage features are letting hostile sites read information from other domains, and letting
hostile sites write information that is then read from other domains.
Letting third-party sites read data that is not supposed to be read from their domain causesinformation leakage, For example, a user's shopping
wishlist on one domain could be used by another domain for targeted advertising; or a user's work-in-progress confidential documents stored by a
word-processing site could be examined by the site of a competing company.
Letting third-party sites write data to the persistent storage of other domains can result ininformation spoofing, 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 identifier to a known ID that the hostile site
can then use to track the user's actions on the victim site.
Thus, strictly following theoriginp767
model described in this specification is important for user security.
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.
Note
11.5.2 Cross-directory attacks
11.5.3 Implementation risks
950
Documents you may be interested
Documents you may be interested
