Extending Storage Access API (SAA) to non-cookie storage

2. Extending SAA to non-cookie storage

This specification defines a method to request access to unpartitioned data beyond just cookies ( requestStorageAccess(types) ), and a method to check if cookie access has specifically been granted ( hasUnpartitionedCookieAccess() ).

window.localStorage.setItem("userid", "1234");

let handle = await document.requestStorageAccess({localStorage: true});
let userid = handle.localStorage.getItem("userid");

2.1. Changes to Document

dictionary StorageAccessTypes {
  boolean all = false;
  boolean cookies = false;
  boolean sessionStorage = false;
  boolean localStorage = false;
  boolean indexedDB = false;
  boolean locks = false;
  boolean caches = false;
  boolean getDirectory = false;
  boolean estimate = false;
  boolean createObjectURL = false;
  boolean revokeObjectURL = false;
  boolean BroadcastChannel = false;
};
interface StorageAccessHandle {
  readonly attribute Storage sessionStorage;
  readonly attribute Storage localStorage;
  readonly attribute IDBFactory indexedDB;
  readonly attribute LockManager locks;
  readonly attribute CacheStorage caches;
  Promise<FileSystemDirectoryHandle> getDirectory();
  Promise<StorageEstimate> estimate();
  DOMString createObjectURL((Blob or MediaSource) obj);
  undefined revokeObjectURL(DOMString url);
  BroadcastChannel BroadcastChannel(DOMString name);
};
partial interface Document {
  ();
  );

  Promise<boolean> hasUnpartitionedCookieAccess();
  Promise<StorageAccessHandle> requestStorageAccess(StorageAccessTypes types);
};

A StorageAccessHandle object has an associated StorageAccessTypes types .

When invoked on Document doc , the hasUnpartitionedCookieAccess() method must run these steps:

1. Return the invocation of hasStorageAccess() on doc .

Note: Now that requestStorageAccess(types) can be used to request unpartitioned data with or without specifically requesting cookies, it must be made clear that hasStorageAccess() only returns true if first-party-site context cookies are accessable to the current document. As a function name, hasUnpartitionedCookieAccess() more clearly communicates this. For now hasStorageAccess() is not considered deprecated, but that may be worth taking up in future.

When invoked on Document doc , the requestStorageAccess(types) method must run these steps:

1. Let p be a new promise .

2. If types . all is false and types . cookies is false and types . sessionStorage is false and types . localStorage is false and types . indexedDB is false and types . locks is false and types . caches is false and types . getDirectory is false and types . estimate is false and types . createObjectURL is false and types . revokeObjectURL is false and types . BroadcastChannel is false :

   1. Reject p with an " InvalidStateError " DOMException .

   2. Return p .

3. Let requestUnpartitionedCookieAccess be true if types . all is true or types . cookies is true , and false otherwise.

4. Let accessPromise be the result of running request storage access with doc with requestUnpartitionedCookieAccess .

5. If accessPromise rejects with reason r :

   1. Reject p with r .

6. Else:

   1. Let handle be a new object of type StorageAccessHandle with .

   2. Set handle ’s types to types .

   3. Resolve p with handle .

7. Return p .

2.2. Changes to requestStorageAccess()

Redefine requestStorageAccess() to:

1. Return the result of running request storage access with doc and requestUnpartitionedCookieAccess being true .

Modify requestStorageAccess() to instead be the algorithm request storage access which takes a Document doc and a boolean argument requestUnpartitionedCookieAccess .

Modify requestStorageAccess() at step 14.1.1.1.1 to read:

1. If requestUnpartitionedCookieAccess is true , then set global ’s has storage access to true.

2.3. Changes to various client-side storage mechanisms

For all of the following getters and methods, consider the following modifications:

1. When attempting to obtain a storage key the returned key will use Client-Side Storage Partitioning § relaxing-additional-keying if the tuple does not simply contain an origin .

Clarify client-side storage mechanism changes in more detail. [Issue #19]

2.3.1. DOM Storage Web storage

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types , the sessionStorage getter must run these steps:

1. If types . all is false and types . sessionStorage is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of sessionStorage .

When invoked on StorageAccessHandle handle with StorageAccessTypes types , the localStorage getter must run these steps:

1. If types . all is false and types . localStorage is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of localStorage .

2.3.2. IndexedDB Indexed Database API

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types , the indexedDB getter must run these steps:

1. If types . all is false and types . indexedDB is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of indexedDB on doc .

2.3.3. Web Locks API

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types , the locks getter must run these steps:

1. If types . all is false and types . locks is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of locks on Navigator .

2.3.4. Cache Storage

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types , the caches getter must run these steps:

1. If types . all is false and types . caches is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of caches .

2.3.5. File System

When invoked on StorageAccessHandle handle with StorageAccessTypes types , the getDirectory() method must run these steps:

1. Let p be a new promise .

2. If types . all is false and types . getDirectory is false :

   1. Reject p with an " InvalidStateError " DOMException .

3. Let directoryPromise be the result of running getDirectory() on Navigator . storage .

4. If directoryPromise rejects with reason r :

   1. Reject p with r .

5. Else if directoryPromise resolves with FileSystemDirectoryHandle f :

   1. Resolve p with f .

6. Return p .

2.3.6. Storage Manager

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types , the estimate() method must run these steps:

1. Let p be a new promise .

2. If types . all is false and types . estimate is false :

   1. Reject p with an " InvalidStateError " DOMException .

3. Let estimatePromise be the result of running estimate() on Navigator . storage .

4. If estimatePromise rejects with reason r :

   1. Reject p with r .

5. Else if estimatePromise resolves with StorageEstimate e :

   1. Resolve p with e .

6. Return p .

2.3.6. 2.3.7. File API

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types and Blob or MediaSource obj , the createObjectURL(obj) method must run these steps:

1. If types . all is false and types . createObjectURL is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of createObjectURL on URL with obj .

When invoked on StorageAccessHandle handle with StorageAccessTypes types and DOMString url , the revokeObjectURL(url) method must run these steps:

1. If types . all is false and types . revokeObjectURL is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of revokeObjectURL on URL with url .

2.3.7. 2.3.8. Broadcast Channel

TBD When invoked on StorageAccessHandle handle with StorageAccessTypes types and DOMString name , the BroadcastChannel(name) method must run these steps:

1. If types . all is false and types . BroadcastChannel is false :

   1. Throw an " InvalidStateError " DOMException .

2. Return the invocation of new BroadcastChannel with name .

2.3.8. 2.3.9. Shared Worker

TBD

3. Security & Privacy considerations

In extending an existing access-granting API, care must be taken not to open additional security issues or abuse vectors relative to comprehensive cross-site cookie blocking and storage partitioning. Except for Service Workers (which will not be supported in this extension) non-cookie storage and communication APIs don’t enable any capability that could not be built with cookie access alone.

For more detailed discussions see The Storage Access API § 6 Privacy considerations and The Storage Access API § 7 Security considerations .