Add security questionnaire answers

README.md

@@ -385,7 +385,27 @@ AI models are admittedly the biggest motivation for working on COS, so one alter
 
 ## Security and privacy considerations
 
-See the complete [questionnaire](security-questionnaire.md) for details.
+See the complete [questionnaire](security-privacy-questionnaire.md) for details.
+
+### Security considerations
+
+The API mandates [explicit user consent](#user-consent-and-permissions) before any file access or storage operation, and permission prompts clearly inform users of the requesting site's intent, providing options to allow or deny access. There's no implicit cross-origin information leakage as files in COS are inaccessible without explicit user permission, ensuring no site can infer the presence or absence of specific files without user interaction. User agents can customize permission prompts to minimize confusion while providing transparency. For example, user agents may decide that origins that stored files previously may access them without prompting, provided user agents deem it safe.
+
+Access is scoped to individual files, [identified by their hashes](#hashing). Developers can't arbitrarily access all files, ensuring limited and precise access control. Files are uniquely identified by their cryptographic hashes (for example, SHA-256), ensuring data integrity. Hashes prevent tampering with the file contens, that is, a site can be sure it gets the same contents from COS as if it had downloaded the file itself as COS guarantees that the file content matches its hash.
+
+File handles provided by the API can [only perform specific operations based on their context](#user-consent-and-permissions) (for example, writing, but not reading, during creation). Misuse of file handles is mitigated by these constraints.
+
+User agents are envisioned to offer [settings UI for managing COS files](#handling-of-eviction), showing stored files and their associated origins. Users can manually evict files or clear all COS data, maintaining control over their storage.
+
+### Privacy considerations
+
+The use of explicit user permission ensures that COS cannot be exploited for tracking or persistent storage across origins without user awareness. Files in COS can't become unvolunatary [supercookies](https://blog.mozilla.org/en/internet-culture/mozilla-explains-cookies-and-supercookies/) without the user noticing.
+
+Prompts can [differentiate between file existence checks and access requests](#user-consent-and-permissions), reducing the risk of misuse or user misunderstanding. Recent origin access to a file is only visible to users via envisioned browser settings UI, not to other origins.
+
+COS [use cases](#use-cases) are limited on purpose to mitigate abuse. The API is designed for large files, discouraging use for smaller assets like JavaScript libraries. Its permission model inherently discourages overuse due to user interruption.
+
+Files in COS may be evicted under critical storage pressure, maintaining system performance and preventing abuse of storage space.
 
 ## Stakeholder feedback / opposition
 
@@ -400,10 +420,6 @@ See the complete [questionnaire](security-questionnaire.md) for details.
 
 ## Acknowledgements
 
-Many thanks for valuable feedback from:
-
-- **François Beaufort**, Google Chrome
-
 Many thanks for valuable inspiration or ideas from:
 
 - **Kenji Baheux**, Google Chrome

security-questionnaire.md → security-privacy-questionnaire.md

@@ -2,88 +2,88 @@
 
 ## 01. What information does this feature expose, and for what purposes?
 
-
+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.
 
 ## 02. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
 
-
+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.
 
 ## 03. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
 
-
+No.
 
 ## 04. How do the features in your specification deal with sensitive information?
 
-
+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.
 
 ## 05. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
 
-
+No.
 
 ## 06. Do the features in your specification introduce state that persists across browsing sessions?
 
-
+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.
 
 ## 07. Do the features in your specification expose information about the underlying platform to origins?
 
-
+No.
 
 ## 08. Does this specification allow an origin to send data to the underlying platform?
 
-
+No.
 
 ## 09. Do features in this specification enable access to device sensors?
 
-
+No.
 
 ## 10. Do features in this specification enable new script execution/loading mechanisms?
 
-
+No.
 
 ## 11. Do features in this specification allow an origin to access other devices?
 
-
+No.
 
 ## 12. Do features in this specification allow an origin some measure of control over a user agent's native UI?
 
-
+No.
 
 ## 13. What temporary identifiers do the features in this specification create or expose to the web?
 
-
+None.
 
 ## 14. How does this specification distinguish between behavior in first-party and third-party contexts?
 
-
+Explicit user consent is required for cross-origin access.
 
 ## 15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
 
-
+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.
 
 ## 16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
 
-
+Yes. The specification includes detailed sections addressing [security considerations](README.MD#security-considerations) and [privacy implications](README.MD#privacy-considerations).
 
 ## 17. Do features in your specification enable origins to downgrade default security protections?
 
+Yes, upon explicit user consent.
 
+## 18. What happens when a document that uses your feature is kept alive in BFCache?
 
-## 18. What happens when a document that uses your feature is kept alive in BFCache
-
-
+The BFCache behavior is aligned with that of the File System Standard ([whatwg/fs#17](https://github.com/whatwg/fs/issues/17)).
 
 ## 19. What happens when a document that uses your feature gets disconnected?
 
-
+The file access operation will terminate, and any pending storage or retrieval will fail gracefully with appropriate errors.
 
 ## 20. Does your spec define when and how new kinds of errors should be raised?
 
-
+No.
 
 ## 21. Does your feature allow sites to learn about the user's use of assistive technology?
 
-
+No.
 
 ## 22. What should this questionnaire have asked?
 
-
+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.