Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update security questionnaire to current version #427

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

nathanmemmott
Copy link

Updates each question to use the current version's wording. Answers questions that were added, and removes ones that were removed.

Updates each question to use the current version's wording. Answers
questions that were added, and removes ones that were removed.
Copy link
Collaborator

@a-sully a-sully left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM. Thanks for making these changes!

@@ -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?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text is outdated. Let's add another TODO to update this once we publish our proposal for #297?

security-privacy-questionnaire.md Show resolved Hide resolved

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?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

https://www.w3.org/TR/2021/NOTE-security-privacy-questionnaire-20211216/#persistent-origin-specific-state


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?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prior to this sentence, we should mention explicitly that a page may continue to hold a lock after being BFCached

@a-sully
Copy link
Collaborator

a-sully commented Sep 19, 2023

FYI merge conflicts are due to dd9f1f9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants