The full questionnaire is at https://w3ctag.github.io/security-questionnaire/.
For your convenience, a copy of the questionnaire's questions is included here in Markdown, so you can easily include your answers in an explainer.
-
What information does this feature expose, and for what purposes?
This features is mostly focused on functionality, and it exposes little information, but there are 2 pieces of information it does expose:
- User's permission status (same as the Permissions API query method) - by design
- User's default browser language (same as the input type=file element - by the contents of the element using a user-known locale by default
-
Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes
-
Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No
-
How do the features in your specification deal with sensitive information?
No sensitive information exposed
-
Does data exposed by your specification carry related but distinct information that may not be obvious to users?
No
-
Do the features in your specification introduce state that persists across browsing sessions?
The feature makes use of permission status which is sometimes persisted across browsing session, but this is not a concept introduced by this feature.
-
Do the features in your specification expose information about the underlying platform to origins?
No
-
Does this specification allow an origin to send data to the underlying platform?
No
-
Do features in this specification enable access to device sensors?
No
-
Do features in this specification enable new script execution/loading mechanisms?
No
-
Do features in this specification allow an origin to access other devices?
No
-
Do features in this specification allow an origin some measure of control over a user agent's native UI?
Yes, depending on implementation details. A user agent might choose to place the prompt near where the permission element is positioned.
-
What temporary identifiers do the features in this specification create or expose to the web?
None that I can think of
-
How does this specification distinguish between behavior in first-party and third-party contexts?
Permission policy and the CSP frame-ancestors directive are required for subframes to make use of the feature
-
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
No special considerations are made for privacy browsing/incognito mode. Up to user agent implementaion and their specific permission model details.
-
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Not yet, WIP.
-
Do features in your specification enable origins to downgrade default security protections?
No.
-
What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
The feature should work as normal.
-
What happens when a document that uses your feature gets disconnected?
The feature does not work in a disconnected document. Since it requires user interaction in the first place (which can't happen in the document is disconnected), the permission element will simply not do anything until re-connected.
-
Does your spec define when and how new kinds of errors should be raised?
No
-
Does your feature allow sites to learn about the user's use of assistive technology?
No
-
What should this questionnaire have asked?
Perhaps a question as to whether the exposed information is already available today via other APIs.