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.

Sign up for GitHub

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

Jump to bottom

Update security questionnaire to current version #427

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

Update security questionnaire to current version #427

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 24 additions & 19 deletions security-privacy-questionnaire.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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


This feature exposes files and directories the user explicitly selects to share with web sites with those web sites. This feature doesn't expose any more information than is already exposed via `<input type=file>` and `<input type=file webkitdirectory>` today.

However this feature does make it possible for browsers to extend the time web sites have access to this information. I.e. permission grants and handles received through this API could be persisted giving web sites access to the same files/directories on disk when a user later returns to the website (or when a service worker for the origin is processing an event). At least for the Chrome implementation, we're only planning on having these grants persist for installed PWAs. On the drive-by web, access will only be as long as the web site is open, requiring re-prompting in subsequent visits.

### 2.2. Is this specification exposing the minimum amount of information necessary to power the feature?
### 2.2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes, we're only exposing files and directories explicitly selected by the user. Of course, web sites could ask for access to a directory when all it needs is access to some files, but the same is already true today. At least as far as exposing information to web sites is concerned, this API doesn't expose any more information than existing APIs do today.

### 2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof?
### 2.3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

No data is exposed without the user explicitly choosing what files or directories to expose to the web site.

### 2.4. How does this specification deal with sensitive information?
### 2.4. How do the features in your specification deal with sensitive information?

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


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?


Expand All @@ -30,50 +30,55 @@ Additionally, user agents could also choose to persist the last directory a file

The `getUniqueId()` method will require a user agent to persist information (e.g. a salt) to provide unique identifiers for handles which are stable across browsing sessions, but which are invalidated once the user clears storage for the site. This state will not be exposed to the website.

### 2.6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?
### 2.6. Do the features in your specification expose information about the underlying platform to origins?

Anything that exists on disk in files could be exposed by the user to the web. However, user agents are encouraged to maintain a block list of certain directories with particularly sensitive files, and thus somewhat restrict which files and directories the user is allowed to select. For example, things like Chrome's "Profile" directory, and other platform configuration data directories are likely going to be on this block list.
Yes, anything that exists on disk in files could be exposed by the user to the web. However, user agents are encouraged to maintain a block list of certain directories with particularly sensitive files, and thus somewhat restrict which files and directories the user is allowed to select. For example, things like Chrome's "Profile" directory, and other platform configuration data directories are likely going to be on this block list.

### 2.7. Does this specification allow an origin access to sensors on a user’s device
### 2.7 Does this specification allow an origin to send data to the underlying platform?
Yes, files and directories explicitly selected by the user can be modified on disk.

No, unless a device exposes such sensors as files or directories. User agents are encouraged to block access to such files or directories (for example `/dev` on linux like systems).

### 2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
### 2.8. Do features in this specification enable access to device sensors?

The data this specification lets a user expose to an origin is identical to the data exposed via `<input type=file>` and `<input type=file webkitdirectory>`. The differences are in giving the origins the ability to re-prompt for access to files they previously had access to (if handles were stored in IndexedDB), and in the ability for origins to write back to the files (after explicit permission is granted for that).
No, unless a device exposes such sensors as files or directories. User agents are encouraged to block access to such files or directories (for example `/dev` on linux like systems).

### 2.9. Does this specification enable new script execution/loading mechanisms?
### 2.9. Do features in this specification enable new script execution/loading mechanisms?

No.

### 2.10. Does this specification allow an origin to access other devices?
### 2.10. Do features in this specification allow an origin to access other devices?

Not really. The exception would be devices that are exposed as files or directories by the platform. I.e. network shares or cloud storage sync clients could expose data on other devices in a way that looks like regular files or directories. The user agent could let the user pick these files or directories, thereby giving an origin implicit access to this other device. This API doesn't have any functionality to let a website enumerate all network shares on the local network, only explicitly selected files or directories can be accessed by an origin.

### 2.11. Does this specification allow an origin some measure of control over a user agent’s native UI?
### 2.11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

The origin can pop up native file or directory pickers, and have some control over what appears inside that native UI (e.g. accepted file types, starting directory and suggested file names), but that control is very limited. The spec does put limitations on what is allowed as an accepted file type and suggested file name to limit the security impact of allowing websites to control the native UI. User agents are expected to employ similar mechanisms to sanitize the sugessted file names as are used to sanitize for example suggested file names in `<a download="foo.ln">` today.

### 2.12. What temporary identifiers might this this specification create or expose to the web?
### 2.12. What temporary identifiers do the features in this specification create or expose to the web?
a-sully marked this conversation as resolved.
Show resolved Hide resolved

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


The feature will work mostly the same as in regular mode, except no handles or permission grants will be persistent. Web sites can use this API to store data to disk even in private browsing mode, but to later be able to read this data again (either from private browsing or regular mode), the user would have to explicitly re-pick the same file or directory.

### 2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section?
### 2.15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes.

### 2.16. Does this specification allow downgrading default security characteristics?
### 2.16. Do features in your specification enable origins to downgrade default security protections?

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


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


### 2.17. What should this questionnaire have asked?

Perhaps something about how a feature might impact privacy and security in a bigger picture. Particularly this questionnaire focuses on all the ways it might make privacy or security worse. And while that is important, and while adding new capabilities like this looks scary, from a higher level perspective we do believe that this actually makes things better. Adding these capabilities to the web will lead to Web replacements for one-off native apps, resulting in a net benefit for user security & privacy.