-
Notifications
You must be signed in to change notification settings - Fork 3
Considerations for the Privacy and Security Reviews
- Privacy
- Write a "Privacy Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, Mitigating Browser Fingerprinting in Web Specifications, and RFC6973 - raised as issue #166 and pull request #168
- request a review via GitHub from the Privacy Interest Group
- Security - raised as w3cping/privacy-request#122
- Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy - raised as issue #166 and pull request #168
- request a review via GitHub - raised as w3c/security-request#59
This questionnaire is based on the TAG security questionnaire.
- What information does/might this feature expose, and for what purposes?
One of DAPT's goals is to be a resource consumed by browsers for the provision of audio description; that provision may include synchronised playback of external audio resources fetched from some origin. Therefore any origin receiving requests for such audio resources could infer that the user is playing media, which media is being played, and that, in the typical expected use case, the user requires audio description, which could be because they have vision impairment or are blind. Playback of the DAPT resource itself might be used to infer the same information, though there is no requirement that DAPT is used solely for audio description.
- Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
We believe so; indeed it is possible to embed audio resources directly within the DAPT document and therefore not expose anything other than the request for the DAPT document.
- Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
DAPT documents typically contain the names of characters or people who feature within the associated media, either fictional or real. It is expected that this information would be present within the media itself or public via other routes anyway, or if there is sensitivity associated with their being publicly named, that the information would be redacted prior to distribution.
- How do the features in your specification deal with sensitive information?
No sensitive information is expected to be present.
- Do the features in your specification introduce state that persists across browsing sessions?
No.
- Do the features in your specification expose information about the underlying platform to origins?
DAPT documents can reference a set of alternate external audio resources for the same fragment of audio, where the processor is expected to select one of the alternatives based on features such as format support. If this pattern is used, it is possible that the processor's choice of audio resource, being exposed to the origin, reveals information about that processor, such as its preferred audio format.
- Does this specification allow an origin to send data to the underlying platform?
data: and other URLs are permitted for referencing external audio resources. It is likely that some Javascript implementations will dereference those URLs using the underlying platform, i.e. the user agent. Implementations written in other languages are likely to use language-native features for decoding those URLs and if necessary, requesting the associated resource.
- 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?
No.
- What temporary identifiers do the features in this specification create or expose to the web?
None.
- How does this specification distinguish between behavior in first-party and third-party contexts?
There is no mandatory support required for 3rd party resources: everything can be 1st party.
- How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
No features require any information that would allow a user's activity to be tracked across browser sessions.
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Not yet! Raised as issue #166
- 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?
No API is associated with a DAPT document. Reuse should have no negative effects.
- What happens when a document that uses your feature gets disconnected?
This question does not seem to be applicable to DAPT.
- What should this questionnaire have asked?
Is it possible to provide the accessibility benefits without generating potential privacy concerns?
If DAPT is used server-side to pre-generate alternate audio renditions of media, incorporating the audio description or dubbing, then by definition no client-side information is given up; however in that case the user can not change the rendering of the audio to suit their own needs, for example adjusting the relative loudness of the main audio compared to the audio description audio, and the text alternative of the audio description cannot be provided to assistive technology, for example to render the descriptions on a Braille display. Where content providers wish to offer these accessibility features, we believe that the privacy footprint of DAPT is as small as it could reasonably be.