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, highly popular JavaScript libraries, Wasm modules) to reduce redundant downloads and storage. Exposing this information is optionally subject to user consent, depending on the user agent’s policy.
Yes, possibly after 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 store arbitrary data until its storage quota is reached in other storage mechanisms like the bucket file system (origin private file system), IndexedDB, or the Cache API. User agents that allow third-party cookies by default may consider exposing this API without a prompt.
Possibly. If a COS file is only used on a couple of websites, 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 agent may optionally allow the user to approve by granting permission to do so. One such attack could be checking for the presence of highly popular JavaScript libraries, deriving that the user visits sites using specific frameworks. In user agents that allow third-party cookies, this information may already be exposed.
Files can only be accessed with optional user consent or user agent approval. The API does not allow arbitrary file discovery or sharing of sensitive user data without permission or user agent consent.
No.
Yes. Files stored in COS persist across sessions. However, their access is gated by optional user consent or user agent approval, and user agents can manage eviction policies to maintain control over this state.
No.
No.
No.
No.
No.
No.
None.
Optional user consent or user agent approval is required for cross-origin access. User agents that allow third-party cookies may consider exposing this API without a prompt.
Files previously stored in COS are not accessible in Private Browsing or Incognito mode. User agents may allow COS to work during an Incognito session, but the data would not be retained. Alternatively, user agents may disable COS entirely.
Yes. The specification includes detailed sections addressing security considerations and privacy implications.
Yes, upon optional user consent or user agent approval.
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.
Yes. The specification defines specific use cases for NotAllowedError and NotFoundError DOMExceptions.
No.
It could include a question about whether the API promotes transparency in user-facing permission prompts, enhancing user understanding of the implications of granting access.