Update security questionnaire to current version #427
Conversation
Updates each question to use the current version's wording. Answers questions that were added, and removes ones that were removed.
| @@ -1,24 +1,24 @@ | |||
| https://www.w3.org/TR/2019/NOTE-security-privacy-questionnaire-20190523/ | |||
| https://www.w3.org/TR/2021/NOTE-security-privacy-questionnaire-20211216/ | |||
|
|
|||
| ### 2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? | |||
There was a problem hiding this comment.
This question now has sub-questions, requiring explicit consideration of four distinct "parties". Let's add a TODO to address this in a follow-up?
https://www.w3.org/TR/2021/NOTE-security-privacy-questionnaire-20211216/#purpose
|
|
||
| No data is exposed without the user explicitly choosing what files or directories to expose to the web site, so only sensitive data that the user explicitly decides to share via this API will be shared. Furthermore, this API is only exposed in secure contexts, and third-party iframes (i.e. iframes that are cross origin from the top-level frame) won't be able to show pickers or permission prompts and can only access data they were already granted access to from a top-level same origin frame. | ||
|
|
||
| ### 2.5. Does this specification introduce new state for an origin that persists across browsing sessions? | ||
| ### 2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions? | ||
|
|
||
| Yes, this specification lets websites store handles they've gotten access to (via a file or directory picker) in IndexedDB. User agents could also persist the permission grants that go with these handles, but at least in the Chrome implementation, these permission grants will only be persistent for installed PWAs. The drive-by web will only have enough state to allow it to re-prompt for access, but the access itself won't be persistent. |
There was a problem hiding this comment.
This text is outdated. Let's add another TODO to update this once we publish our proposal for #297?
|
|
||
| No data is exposed without the user explicitly choosing what files or directories to expose to the web site, so only sensitive data that the user explicitly decides to share via this API will be shared. Furthermore, this API is only exposed in secure contexts, and third-party iframes (i.e. iframes that are cross origin from the top-level frame) won't be able to show pickers or permission prompts and can only access data they were already granted access to from a top-level same origin frame. | ||
|
|
||
| ### 2.5. Does this specification introduce new state for an origin that persists across browsing sessions? | ||
| ### 2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions? |
There was a problem hiding this comment.
This question gives IndexedDB as an example... which suggests the BucketFS should be included here. Or it might be worth creating a separate questionnaire on the whatwg spec?... Anyways, let's just add a TODO for now?
|
|
||
| The `getUniqueId()` method will create a temporary unique identifier for a given handle. This ID will become invalid if the user clears storage for the site. | ||
|
|
||
| ### 2.13. How does this specification distinguish between behavior in first-party and third-party contexts? | ||
|
|
||
| It is expected that user agents do not allow third-party contexts to prompt for any kind of access using this API. I.e. third-party contexts can potentially access files or directories that their origin was already granted access to in a first-party context (by sharing handles via IndexedDB or postMessage), but can't trigger any new file/directory pickers or permission requests. | ||
|
|
||
| ### 2.14. How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode? | ||
| ### 2.14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? |
There was a problem hiding this comment.
If we decide to include discussions of the BucketFS in this questionnaire (in a follow-up, presumably), we should mention that it's expected to be implemented using an in-memory file system in this case
|
|
||
| No. | ||
|
|
||
| ### 2.17. How does your feature handle non-"fully active" documents? | ||
|
|
||
| This feature uses a locking system to prevent data races when modifying/reading a handle. Locks are acquired on the handle. These locks are held by the user agent, not the platform. |
There was a problem hiding this comment.
Locks are acquired on the handle.
Well, not exactly... This doesn't add much IMHO so I would recommend leaving it out
These locks are held by the user agent, not the platform.
Not necessarily. This is up to the user agent's implementation and is subject to change. Should probably also leave this out
|
|
||
| This feature uses a locking system to prevent data races when modifying/reading a handle. Locks are acquired on the handle. These locks are held by the user agent, not the platform. | ||
|
|
||
| When lock contention occurs between a "fully active" and non-"fully active" document, the latter is discarded and its locks released. |
There was a problem hiding this comment.
Prior to this sentence, we should mention explicitly that a page may continue to hold a lock after being BFCached
|
FYI merge conflicts are due to dd9f1f9 |
Updates each question to use the current version's wording. Answers questions that were added, and removes ones that were removed.