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.

   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. Web storage

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. Indexed Database API

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

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

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

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.7. File API

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.8. Broadcast Channel

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