diff --git a/README.md b/README.md
index 1b1c900..f17c948 100644
--- a/README.md
+++ b/README.md
@@ -2,4 +2,18 @@ This repository contains the [Editor's Draft](https://w3ctag.github.io/security-
The questionnaire is a joint product of the [TAG](https://tag.w3.org/) and [PING](https://www.w3.org/Privacy/IG/).
-When folks request a [design review](https://github.com/w3ctag/design-reviews) from the TAG or a [privacy review](https://github.com/w3cping/privacy-reviews/issues) from PING, [filling out](questionnaire.markdown) the security and privacy questionnaire helps everyone to understand potential security and privacy issues and mitigations for the design, and can save us asking redundant questions.
+When folks request a [design review](https://github.com/w3ctag/design-reviews) from the TAG, [filling out](questionnaire.markdown) the security and privacy questionnaire helps the TAG to understand potential security and privacy issues and mitigations for the design, and can save us asking redundant questions.
+
+Before requesting security and
+privacy review
+from the security reviewers and PING, respectively, documents must
+contain both "Security Considerations" and "Privacy Considerations"
+sections for their documents, as described in Section 2.15. While
+your answers to the questions in this document will inform your
+writing of those sections, it is not appropriate to merely copy this
+questionnaire into those sections.
+
+[Further instructions on requesting security and privacy reviews can be found in the Guide.](https://w3c.github.io/documentreview/#how_to_get_horizontal_review)
+
+
+
diff --git a/index.bs b/index.bs
index f092af5..f2cc88f 100644
--- a/index.bs
+++ b/index.bs
@@ -31,7 +31,9 @@ This document contains a set of questions
intended to help spec authors
as they think through
the security and privacy implications
-of their work.
+of their work and write the narrative Security Considerations and Privacy
+Considerations sections for inclusion in-line in their specifications,
+as described below in [[#considerations]].
It also documents mitigation strategies
that spec authors can use to address
security and privacy concerns they encounter as they work on their spec.
@@ -58,30 +60,56 @@ to protect their users' privacy and security.
These questions should be kept in mind throughout work on any specification.
Spec authors should periodically revisit this questionnaire
to continue to consider the privacy and security implications of
-their features, as their design changes over time.
-
-TAG and PING reviews and this questionnaire
+their spec's features, particularly as their design changes over time.
+
+TAG, PING, and security reviews and this questionnaire
+
+Before requesting
+privacy and
+security reviews from the [Privacy Interest Group
+(PING)](https://www.w3.org/Privacy/IG/) and security reviewers,
+respectively, authors must write both "Security Considerations" and
+"Privacy Considerations" sections for their documents, as described in
+[[#considerations]]. While your answers to the questions in this
+document will inform your writing of those sections, it is not
+appropriate to merely copy this questionnaire into those sections.
+Instructions for requesting security and privacy reviews can be
+found in the
+[Guide](https://w3c.github.io/documentreview/#how_to_get_horizontal_review).
When authors request
a [review](https://github.com/w3ctag/design-reviews)
from the [Technical Architecture Group (TAG)](https://www.w3.org/2001/tag/),
the TAG asks that authors provide answers
to the questions in this document.
-The [Privacy Interest Group (PING)](https://www.w3.org/Privacy/IG/)
-also considers answers to these questions
-while conducting
-[privacy reviews](https://github.com/w3cping/privacy-reviews/issues).
-The TAG and PING use this document
+The TAG may use this document
to record security and privacy questions
-which come up during our reviews.
+which come up during their reviews.
Working through these questions can save
both spec authors and the people performing design reviews
a lot of time.
To make it easier for anyone requesting a review
-to provide their answers to these questions to the reviewers,
-we've prepared [a list of these questions in Markdown](https://raw.githubusercontent.com/w3ctag/security-questionnaire/master/questionnaire.markdown).
+to provide their answers to these questions to the TAG,
+we have prepared [a list of these questions in Markdown](https://raw.githubusercontent.com/w3ctag/security-questionnaire/master/questionnaire.markdown).
+
+
+Additional resources
+
+This document is only one of the tools you should use to inform your
+consideration of privacy and security issues in your
+spec.
+
+The Mitigating Browser Fingerprinting in Web Specifications
+[[FINGERPRINTING-GUIDANCE]] document published by PING goes into
+further depth about browser fingerprinting and should be considered in
+parallel with this document.
+
+The IETF's RFC about privacy considerations, [[RFC6973]], is a
+wonderful resource. We recommend that all spec authors read section 7
+of RFC6973.
+
Questions to Consider
@@ -102,13 +130,13 @@ See also
* [[DESIGN-PRINCIPLES#priority-of-constituencies]]
- Is this specification exposing the minimum amount of information necessary
- to power its features?
+ Do features in your specification expose the minimum amount of information
+ necessary to enable their intended uses?
Features should only expose information
-when it's absolutely necessary to satisfy its use cases.
-If your feature exposes more information than is necessary,
+when it's absolutely necessary to satisfy use cases.
+If a feature exposes more information than is necessary,
why does it do so?
See also
@@ -116,7 +144,7 @@ See also
* [[#data-minimization]]
- How does this specification deal with personal information,
+ How do the features in your specification deal with personal information,
personally-identifiable information (PII), or information derived from
them?
@@ -187,7 +215,7 @@ See also
* [[DESIGN-PRINCIPLES#consent]]
- How does this specification deal with sensitive information?
+ How do the features in your specification deal with sensitive information?
Personal information is not the only kind of sensitive information.
@@ -204,13 +232,14 @@ that would be harmless in one country
might be used in another country
to detain, kidnap, or imprison them.
-Note:
+Examples of sensitive information include:
caste,
citizenship,
color,
credentials,
criminal record,
demographic information,
+disability status,
employment status,
ethnicity,
financial information,
@@ -223,8 +252,7 @@ race,
religious beliefs or nonbeliefs,
sexual preferences,
and
-trans status
-are all examples of sensitive information.
+trans status.
When a feature exposes sensitive information to the web,
its designers must take steps
@@ -267,8 +295,8 @@ See also
* [[DESIGN-PRINCIPLES#do-not-expose-use-of-assistive-tech]]
- Does this specification introduce new state for an origin that persists
- across browsing sessions?
+ Do the features in your specification introduce new state for an origin
+ that persists across browsing sessions?
There are many existing mechanisms
@@ -357,10 +385,11 @@ is vital.
+
(Underlying platform information includes
user configuration data,
the presence and attributes of hardware I/O devices such as sensors,
@@ -377,7 +406,7 @@ or indirect
(because the data may be combined with other data to form a fingerprint). [[FINGERPRINTING-GUIDANCE]]
When considering whether or not to expose such information,
-specifications and user agents
+specs and user agents
should not consider the information in isolation,
but should evaluate the risk of adding it
to the existing fingerprinting surface of the platform.
@@ -401,7 +430,7 @@ by ordering a list of available resources—but sometimes,
more complex mitigations may be necessary.
See [[#mitigations]] for more.
-If your specification exposes such data
+If features in your spec expose such data
and does not define adequate mitigations,
you should ensure that such information
is not revealed to origins
@@ -429,8 +458,40 @@ See also:
* [[DESIGN-PRINCIPLES#device-ids|Use care when exposing identifying information about devices]]
* [[DESIGN-PRINCIPLES#device-enumeration|Use care when exposing APIs for selecting or enumerating devices]]
+
+
+If so, what kind of data can be sent?
+
+Platforms differ in how they process data passed into them,
+which may present different risks to users.
+
+Don't assume the underlying platform will safely handle the data that is passed.
+Where possible, mitigate attacks by limiting or structuring the kind of data is passed to the platform.
+
+
+URLs may or may not be dereferenced by a platform API,
+and if they are dereferenced,
+redirects may or may not be followed.
+If your specification sends URLs to underlying platform APIs,
+the potential harm of *your* API
+may vary depending on
+the behavior of the various underlying platform APIs it's built upon.
+
+What happens when `file:`, `data:`, or `blob:` URLs
+are passed to the underlying platform API?
+These can potentially read sensitive data
+directly form the user's hard disk or from memory.
+
+Even if your API only allows `http:` and `https:` URLs,
+such URLs may be vulnerable to [=CSRF=] attacks,
+or be redirected to `file:`, `data:`, or `blob:` URLs.
+
+
- Does this specification allow an origin access to sensors on a user’s
+ Do features in this specification allow an origin access to sensors on a user’s
device
@@ -448,50 +509,48 @@ is relatively stable, for example for short time periods (seconds, minutes, even
is consistent across-origins. In fact, if two user-agents expose the same
sensor data the same way, it may become a cross-browser, possibly even a cross-device identifier.
-
-As gyroscopes advanced, their sampling rate had to be lowered to
-prevent them from being used as a microphone as one such example
-[[GYROSPEECHRECOGNITION]].
-
+ As gyroscopes advanced, they could be used as
+microphones [[GYROSPEECHRECOGNITION]]. This was mitigated by lowering
+their sample rates.
-ALS sensors could allowed for an attacker to exfiltrate whether or not a
+Ambient light sensors could allow an attacker to learn whether or not a
user had visited given links [[OLEJNIK-ALS]].
Even relatively short lived data, like the battery status, may be able to
-serve as an identifier if misused/abused [[OLEJNIK-BATTERY]].
+serve as an identifier [[OLEJNIK-BATTERY]].
- What data does this specification expose to an origin? Please also
- document what data is identical to data exposed by other features, in the
+ What data do the features in 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.
As noted above in [[#sop-violations]], the [=same-origin policy=] is an
important security barrier that new features need to carefully consider.
-If a specification exposes details about another origin's state, or allows
+If a feature exposes details about another origin's state, or allows
POST or GET requests to be made to another origin, the consequences can be
severe.
Content Security Policy [[CSP]] unintentionally exposed redirect targets
cross-origin by allowing one origin to infer details about another origin
-through violation reports (see [[HOMAKOV]]). The working group eventually
+through violation reports (see [[HOMAKOV]]). The working group
mitigated the risk by reducing a policy's granularity after a redirect.
-
-Beacon [[BEACON]] allows an origin to send POST requests to an endpoint
-on another origin. They decided that this feature didn't add any new
-attack surface above and beyond what normal form submission entails, so
-no extra mitigation was necessary.
-
+ Beacon [[BEACON]] allows an origin to send POST
+requests to an endpoint on another origin. The working group concluded
+that this feature did not add any new attack surface above and beyond
+what normal form submission entails, so no extra mitigation was
+necessary.
- Does this specification enable new script execution/loading mechanisms?
+ Do feautres in this specification enable new script execution/loading
+ mechanisms?
* HTML Imports [[HTML-IMPORTS]] create a new script-loading mechanism, using
@@ -505,10 +564,11 @@ no extra mitigation was necessary.
* What about style?
- Does this specification allow an origin to access other devices?
+ Do features in this specification allow an origin to access other devices?
-If so, what devices does this specification allow an origin to access?
+If so, what devices do the features in this specification allow an origin to
+access?
Accessing other devices, both via network connections and via
direct connection to the user's machine (e.g. via Bluetooth,
@@ -525,7 +585,7 @@ risk:
location.
* Enumerating the devices on a user’s local network provides significant
entropy that an attacker may use to fingerprint the user agent.
-* If the specification exposes persistent or long lived identifiers of
+* If features in this spec expose persistent or long lived identifiers of
local network devices, that provides attackers with a way to track a user
over time even if a user takes steps to prevent such tracking (e.g.
clearing cookies and other stateful tracking mechanisms).
@@ -553,8 +613,8 @@ See [[WEBUSB#security-and-privacy]] for more.
- Does this specification allow an origin some measure of control over a user
- agent's native UI?
+ Do features in this specification allow an origin some measure of control over
+ a user agent's native UI?
Features that allow for control over a user agent’s UI (e.g. full screen
@@ -565,8 +625,8 @@ user agent’s UI, can it effect security / privacy controls? What analysis
confirmed this conclusion?
- What temporary identifiers might this this specification create or expose
- to the web?
+ What temporary identifiers do the feautures in this specification create or
+ expose to the web?
If a standard exposes a temporary identifier to the web, the identifier
@@ -575,16 +635,19 @@ the risk of this identifier being used to track a user over time. When a
user clears state in their user agent, these temporary identifiers should be
cleared to prevent re-correlation of state using a temporary identifier.
-If this specification does create or expose a temporary identifier to the
-web, how is it exposed, when, to what entities, and, how frequently is it
-rotated?
+If features in this spec create or expose temporary identifiers to the
+web, how are they exposed, when, to what entities, and, how frequently are
+those temporary identifiers rotated?
Example temporary identifiers include TLS Channel ID, Session Tickets, and
IPv6 addresses.
+
The index attribute in the Gamepad API [[GAMEPAD]] — an integer that starts
at zero, increments, and is reset — is a good example of a privacy friendly
temporary identifier.
+
+
How does this specification distinguish between behavior in first-party and
@@ -604,24 +667,22 @@ availability or functionality of certain features to third parties if the
third parties are found to be abusing the functionality.
- How does this specification work in the context of a user agent’s Private
- Browsing or "incognito" mode?
+ How do the features in this specification work in the context of a browser’s
+ Private Browsing or Incognito mode?
-Each major user agent implements a private browsing / incognito mode feature
-with significant variation across user agents in threat models,
-functionality, and descriptions to users regarding the protections afforded
-[[WU-PRIVATE-BROWSING]].
+Most browsers implement a private browsing or incognito mode,
+though they vary significantly in what functionality they provide and
+how that protection is described to users [[WU-PRIVATE-BROWSING]].
-One typical commonality across user agents' private browsing / incognito
-modes is that they have a set of state than the user agents’ in their
-‘normal’ modes.
+One commonality is that they provide a different set of state
+than the browser's 'normal' state.
-Does the specification provide information that would allow for the
-correlation of a single user's activity across normal and private browsing /
-incognito modes? Does the specification result in information being written
-to a user’s host that would persist following a private browsing / incognito
-mode session ending?
+Do features in this spec provide information that would allow for the
+correlation of a single user's activity across normal and private
+browsing / incognito modes? Do features in the spec result in
+information being written to a user’s host that would persist
+following a private browsing / incognito mode session ending?
There has been research into both:
@@ -631,79 +692,85 @@ There has been research into both:
non-private mode sessions for a given user. [[OLEJNIK-PAYMENTS]]
- Does this specification have a "Security Considerations" and "Privacy
- Considerations" section?
+ Does this specification have both "Security Considerations" and "Privacy
+ Considerations" sections?
-Documenting the various concerns and potential abuses in "Security
-Considerations" and "Privacy Considerations" sections of a document is a good
-way to help implementers and web developers understand the risks that a
-feature presents, and to ensure that adequate mitigations are in place.
-Simply adding a section to your specification with yes/no responses to the
-questions in this document is insufficient.
-
-If it seems like a feature does not have security or privacy impacts,
-then say so inline in the spec section for that feature:
-
-> There are no known security or privacy impacts of this feature.
-
-Saying so explicitly in the specification serves several purposes:
-
-1. Shows that a spec author/editor has explicitly considered security and
- privacy when designing a feature.
-1. Provides some sense of confidence that there might be no such impacts.
-1. Challenges security and privacy minded individuals to think of and find
- even the potential for such impacts.
-1. Demonstrates the spec author/editor's receptivity to feedback about such
- impacts.
-1. Demonstrates a desire that the specification should not be introducing
- security and privacy issues
-
-[[RFC3552]] provides general advice as to writing Security Consideration
-sections. Generally, there should be a clear description of the kinds of
-privacy risks the new specification introduces to for users of the web
-platform. Below is a set of considerations, informed by that RFC, for
-writing a privacy considerations section.
-
-Authors must describe:
-
-1. What privacy attacks have been considered?
-1. What privacy attacks have been deemed out of scope (and why)?
-1. What privacy mitigations have been implemented?
-1. What privacy mitigations have considered and not implemented (and why)?
-
-In addition, attacks considered must include:
-
-1. Fingerprinting risk;
-1. Unexpected exfiltration of data through abuse of sensors;
-1. Unexpected usage of the specification / feature by third parties;
-1. If the specification includes identifiers, the authors must document what
- rotation period was selected for the identifiers and why.
-1. If the specification introduces new state to the user agent, the authors
- must document what guidance regarding clearing said storage was given and
- why.
-1. There should be a clear description of the residual risk to the user
- after the privacy mitigations has been implemented.
-
-The crucial aspect is to actually considering security and privacy. All new
-specifications must have security and privacy considerations sections to be
-considered for wide reviews. Interesting features added to the web platform
-generally often already had security and/or privacy impacts.
+Specifications should have both "Security Considerations" and "Privacy
+Considerations" sections to help implementers and web developers
+understand the risks that a feature presents and to ensure that
+adequate mitigations are in place. While your answers to the
+questions in this document will inform your writing of those sections,
+do not merely copy this questionnaire into those sections. Instead,
+craft language specific to your specification that will be helpful to
+implementers and web developers.
+
+[[RFC6973]] is an excellent resource to consult when considering
+privacy impacts of your specification, particularly Section 7 of
+RFC6973. [[RFC3552]] provides general advice as to writing Security
+Consideration sections, and Section 5 of RFC3552 has specific requirements.
+
+Generally, these sections should contain clear descriptions of the
+privacy and security risks the features in this spec introduce. It is also
+appropriate to document risks that are mitigated elsewhere in the
+specification and to call out details that, if implemented
+other-than-according-to-spec, are likely to lead to vulnerabilities.
+
+If it seems like none of the features in your specification have security or
+privacy impacts, say so in-line, e.g.:
+
+> There are no known security impacts of the features in this specificaiton.
+
+Be aware, though, that most specifications include features that have at least some
+impact on the fingerprinting surface of the browser. If you believe
+your specification in an outlier, justifying that claim is in
+order.
- Does this specification allow downgrading default security characteristics?
+ Do features in your specification enable origins to downgrade default
+ security protections?
-Does this feature allow for a site to opt-out of security settings to
-accomplish some piece of functionality? If so, in what situations does your
-specification allow such security setting downgrading and what mitigations
-are in place to make sure optional downgrading doesn't dramatically increase
-risks?
+Do features in your spec
+enable an origin to opt-out of security settings
+in order to accomplish something?
+If so,
+in what situations do these features allow such downgrading, and why?
+
+Can this be avoided in the first place?
+If not, are mitigations in place
+to make sure this downgrading doesn’t dramatically increase risk to users?
+For instance,
+[[PERMISSIONS-POLICY]] defines a mechanism
+that can be used by sites to prevent untrusted <{iframe}>s from using such a feature.
+
+
+The {{Document/domain|document.domain}} setter can be used to relax the [=same-origin policy=].
+The most effective mitigation
+would be to remove it from the platform (see [[#drop-feature]]),
+though that
+[may be challenging](https://github.com/mikewest/deprecating-document-domain/)
+for compatibility reasons.
+
-* {{Document/domain|document.domain}}
-* [[CORS]]
-* [[WEBMESSAGING]]
-* [[REFERRER-POLICY]]'s "unsafe-url"
+
+The Fullscreen API enables
+a (portion of a) web page
+to expand to fill the display. [[FULLSCREEN]]
+This can hide
+several User Agent user interface elements
+which help users to understand
+what web page they are visiting
+and whether or not the User Agent believes they are [safe](https://w3ctag.github.io/design-principles/#safe-to-browse).
+
+Several mitigations are defined in the specification
+and are widely deployed in implementations.
+For instance, the Fullscreen API is a [=policy-controlled feature=],
+which enables sites to disable the API in <{iframe}>s.
+[[FULLSCREEN#security-and-privacy-considerations]] encourages implementations
+to display an overlay which informs the user that they have entered fullscreen,
+and to advertise a simple mechanism to exit fullscreen (typically the `Esc` key).
+
What should this questionnaire have asked?
@@ -823,9 +890,9 @@ another. For example:
attacker tricking an origin into executing attacker-controlled code in
the context of a target origin.
-* Cross-site request forgery attacks trick user agents into exerting a
- user's ambient authority on sites where they've logged in by submitting
- requests on their behalf.
+* Cross-site request forgery attacks trick user
+ agents into exerting a user's ambient authority on sites where they've
+ logged in by submitting requests on their behalf.
* Data leakage occurs when bits of information are inadvertently made
available cross-origin, either explicitly via CORS headers [[CORS]],
@@ -861,7 +928,7 @@ Even when powerful features are made available to developers, it does not
mean that all the uses should always be a good idea, or justified; in fact,
data privacy regulations around the world may even put limits on certain uses
of data. In the context of first party, a legitimate website is potentially
-able to interact with powerful features to learn about the user behavior or
+able to interact with powerful features to learn about user behavior or
habits. For example:
* Tracking the user while browsing the website via mechanisms such as mouse
@@ -869,14 +936,14 @@ habits. For example:
* Behavioral profiling of the user based on the usage patterns
-* Accessing powerful features enabling to reason about the user system,
- himself or the user surrounding, such as a webcam, Web Bluetooth or
- sensors
+* Accessing powerful features that enable the first-party to learn about
+ the user's system, the user themselves, or the user's susurroundings, such
+ as could be done through a webcam or sensors
This point is admittedly different from others - and underlines that even if
something may be possible, it does not mean it should always be done,
including the need for considering a privacy impact assessment or even an
-ethical assessment. When designing a specification with security and privacy
+ethical assessment. When designing features with security and privacy
in mind, all both use and misuse cases should be in scope.
@@ -884,9 +951,8 @@ in mind, all both use and misuse cases should be in scope.
To mitigate the security and privacy risks you’ve identified in your
-specification as you’ve filled out the questionnaire,
-you may want to apply one or more of the mitigations described below to your
-feature.
+specification,
+you may want to apply one or more of the mitigations described below.
Data Minimization
@@ -934,7 +1000,8 @@ only providing information on the mouse's behaviour when certain events take
place. The approach is therefore to expose event handling (e.g., triggering
on click, move, button press) as the sole interface to the device.
-Two features that have minimized the data they make available are:
+Two specifications that have minimized the data their features expose
+are:
* [[BATTERY-STATUS]] The user agent should not expose high precision readouts
* [[GENERIC-SENSOR]] Limit maximum sampling frequency
,
@@ -1000,12 +1067,12 @@ parties?
Explicitly restrict the feature to first party origins
-As described in the "Third-Party Tracking" section, a significant feature of
-the web is the mixing of first and third party content in a single page, but,
-this introduces risk where the third party content can use the same set of web
-features as the first party content.
+As described in the "Third-Party Tracking" section, web pages mix
+first and third party content into a single application, which
+introduces the risk that third party content can misuse the same set of web
+features as first party content.
-Authors should explicit specify the feature's scope of availability:
+Authors should explicitly specify a feature's scope of availability:
* When a feature should be made available to embedded third parties -- and
often first parties should be able to explicitly control that (using
@@ -1015,7 +1082,7 @@ Authors should explicit specify the feature's scope of availability:
* Whether a feature should be available to offline service workers.
* Whether events will be fired simultaneously
-Third party’s access to a feature should be an optional implementation for
+Third party access to a feature should be an optional implementation for
conformance.
@@ -1049,7 +1116,7 @@ is to drop the feature,
though you should keep in mind that some security or privacy risks
may be removed or mitigated
by adding features to the platform.
-Every feature in a spec
+Every feature in a specification
should be seen as
potentially adding security and/or privacy risk
until proven otherwise.
@@ -1092,18 +1159,17 @@ Examples
Making a privacy impact assessment
-Some features are potentially supplying very sensitive data, and it is
+Some features potentially supply sensitive data, and it is
the responsibility of the end-developer, system owner, or manager to realize
-this and act accordingly in the design of his/her system. Some use may
+this and act accordingly in the design of their system. Some use may
warrant conducting a privacy impact assessment, especially when data
relating to individuals may be processed.
-Specifications that expose such sensitive data should include a
-recommendation that websites and applications adopting the API — but not
-necessarily the implementing user agent — conduct a privacy impact assessment
-of the data that they collect.
+Specifications that include features that expose sensitive data should include
+recommendations that websites and applications adopting the API conduct a
+privacy impact assessment of the data that they collect.
-A features that recommends such is:
+A feature that does this is:
* [[GENERIC-SENSOR]] advises to consider performing of a privacy impact
assessment
diff --git a/questionnaire.markdown b/questionnaire.markdown
index a201614..d2a6500 100644
--- a/questionnaire.markdown
+++ b/questionnaire.markdown
@@ -6,32 +6,34 @@ For your convenience, a copy of the questionnaire's questions is quoted here in
> 01. What information might this feature expose to Web sites or other parties,
> and for what purposes is that exposure necessary?
-> 02. Is this specification exposing the minimum amount of information necessary
-> to power its features?
-> 03. How does this specification deal with personal information,
+> 02. Do features in your specification expose the minimum amount of information
+> necessary to enable their intended uses?
+> 03. How do the features in your specification deal with personal information,
> personally-identifiable information (PII), or information derived from
> them?
-> 04. How does this specification deal with sensitive information?
-> 05. Does this specification introduce new state for an origin that persists
-> across browsing sessions?
-> 06. Does this specification expose information about the underlying
-> platform to origins?
-> 07. Does this specification allow an origin access to sensors on a user’s
+> 04. How do the features in your specification deal with sensitive information?
+> 05. Do the features in your specification introduce new state for an origin
+> that persists across browsing sessions?
+> 06. Do the features in your specification expose information about the
+> underlying platform to origins?
+> 07. Do features in this specification allow an origin access to sensors on a user’s
> device
-> 08. What data does this specification expose to an origin? Please also
-> document what data is identical to data exposed by other features, in the
+> 08. What data do the features in 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.
-> 09. Does this specification enable new script execution/loading mechanisms?
-> 10. Does this specification allow an origin to access other devices?
-> 11. Does this specification allow an origin some measure of control over a user
-> agent's native UI?
-> 12. What temporary identifiers might this this specification create or expose
-> to the web?
+> 09. Do feautres in this specification enable new script execution/loading
+> mechanisms?
+> 10. Do features in this specification allow an origin to access other devices?
+> 11. Do features in this specification allow an origin some measure of control over
+> a user agent's native UI?
+> 12. What temporary identifiers do the feautures in this specification create or
+> expose to the web?
> 13. How does this specification distinguish between behavior in first-party and
> third-party contexts?
-> 14. How does this specification work in the context of a user agent’s Private
-> Browsing or "incognito" mode?
-> 15. Does this specification have a "Security Considerations" and "Privacy
-> Considerations" section?
-> 16. Does this specification allow downgrading default security characteristics?
+> 14. How do the features in this specification work in the context of a browser’s
+> Private Browsing or Incognito mode?
+> 15. Does this specification have both "Security Considerations" and "Privacy
+> Considerations" sections?
+> 16. Do features in your specification enable origins to downgrade default
+> security protections?
> 17. What should this questionnaire have asked?