The COS API exposes the availability of files identified by their hash across different origins. The purpose is to enable efficient sharing of large files (for example, AI models, SQLite databases, Wasm modules) to reduce redundant downloads and storage.
Yes, after explicit user consent, the API exposes only the existence of a file with a known hash and provides read access to it. No additional metadata is exposed. Write access is always granted, just like any page can freely and until its storage quota is reached store arbitrary data in other storage mechanisms like the bucket file system (origin private file system), IndexedDB, or the Cache API.
Possibly. If a COS file is only used on a couple websites, then a site can discover that the user visited those sites by checking for the file’s presence. The attacker site would need to probe hashes of resources it’s interested in, which the user would need to approve by granting permission to do so. One such attack could be checking for the presence of game engines, and thereby deriving that the user may be interested in gaming.
Files can only be accessed with explicit user consent. The API does not allow arbitrary file discovery or sharing of sensitive user data without permission.
No.
Yes. Files stored in COS persist across sessions. However, their access is gated by user consent, and user agents can manage eviction policies to maintain control over this state.
No.
No.
No.
No.
No.
No.
None.
Explicit user consent is required for cross-origin access.
Files previously stored in COS are not accessible in Private Browsing or Incognito mode. Browser vendors may allow COS to work during an Incognito session, but the data would not be retained. Alternatively, browser vendors may disable COS entirely.
Yes. The specification includes detailed sections addressing security considerations and privacy implications.
Yes, upon explicit user consent.
The BFCache behavior is aligned with that of the File System Standard (whatwg/fs#17).
The file access operation will terminate, and any pending storage or retrieval will fail gracefully with appropriate errors.
No.
No.
It could include a question about whether the API promotes transparency in user-facing permission prompts to enhance user understanding of the implications of granting access.