Added TAG security and privacy questionnaire

encrypted-media-respec.html

@@ -8172,6 +8172,29 @@ <h3>
           have been visited and information stored for those sites. In particular, [=Key Systems=]
           MUST not share key or other data between [=origins=].
         </p>
+        <p>
+          Several features in this specification expose capability information that may
+          marginally contribute to fingerprinting:
+        </p>
+        <ul>
+          <li>
+            <p>
+              The {{MediaKeySystemMediaCapability/encryptionScheme}} member of
+              {{MediaKeySystemMediaCapability}} reveals which encryption schemes a
+              [=Key System=] supports. This information is largely determined by the
+              [=Key System=] itself and so adds little beyond what is already implied
+              by the application's choice of [=Key System=].
+            </p>
+          </li>
+          <li>
+            <p>
+              {{MediaKeys/getStatusForPolicy()}} reveals whether a specified HDCP
+              policy can be enforced. This reflects the capabilities of the
+              currently-connected display chain, and may change during a session if
+              the user reconfigures their displays.
+            </p>
+          </li>
+        </ul>
       </section>
       <section id="privacy-leakage">
         <h3>

security-privacy-questionnaire.md

@@ -0,0 +1,173 @@
+# Encrypted Media Extensions v2 Self-Review Questionnaire: Security and Privacy
+
+Questionnaire: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-20250418/ (from 18 April 2025)
+
+## 2.1 What information does this feature expose, and for what purposes?
+
+**Handling hardware context reset:** Information about certain device state changes will be exposed indirectly to Web sites, e.g. session closed due to "hardware context reset", which could be caused by setting the device to sleep/resume, or switching monitors. Sites will not be able to know the exact reason. This allows the application to distinguish recoverable closures (where it should create a new session and resume playback) from unrecoverable ones.
+
+**Querying encryption scheme support:** The API exposes which encryption schemes (such as `cenc` or `cbcs`) the implementation supports. These encryption schemes are incompatible with each other, so the API allows websites to make intelligent choices about what content to serve to which user agents.
+
+**HDCP policy detection:** The API exposes whether an HDCP version is supported by the implementation. This allows websites to know before fetching content if HDCP (and what version) can be enforced, which allows them, for example, to start pre-fetching high resolution content rather than starting at a low resolution or waiting for the license exchange.
+
+## 2.2 Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
+
+**Handling hardware context reset:** Yes. It only exposes an enum summarizing the reason.
+
+**Querying encryption scheme support:** Yes. The API exposes only the negotiated encryption scheme(s) per content type, via the `MediaKeySystemMediaCapability.encryptionScheme` attribute returned from `MediaKeySystemAccess.getConfiguration()`. No CDM internals are revealed.
+
+**HDCP policy detection:** Yes. `MediaKeys.getStatusForPolicy()` returns only a single `MediaKeyStatus` per query, not raw HDCP capabilities or display chain details.
+
+## 2.3 Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
+
+**Handling hardware context reset:** No such information is exposed.
+
+**Querying encryption scheme support:** No such information is exposed.
+
+**HDCP policy detection:** No such information is exposed.
+
+## 2.4 How do the features in your specification deal with sensitive information?
+
+**Handling hardware context reset:** The features do not deal with any sensitive information.
+
+**Querying encryption scheme support:** The features do not deal with any sensitive information.
+
+**HDCP policy detection:** The features do not deal with any sensitive information.
+
+## 2.5 Does data exposed by your specification carry related but distinct information that may not be obvious to users?
+
+**Handling hardware context reset:** The `hardware-context-reset` reason aggregates multiple internal causes (such as sleep/resume and display configuration changes), but since these can only be triggered by user actions and not by the page, the `hardware-context-reset` reason is not a useful fingerprinting vector.
+
+**Querying encryption scheme support:** Supported encryption schemes correlate with the underlying CDM, and the chosen `keySystem` already implies most of this information. Any marginal additional fingerprinting surface is described in the [Fingerprinting](https://w3c.github.io/encrypted-media/#privacy-fingerprinting) section.
+
+**HDCP policy detection:** HDCP version support is a property of the connected display chain, so it can change when the user moves the window between displays. This is consistent with similar information already conveyed through `MediaKeyStatus` for active sessions.
+
+## 2.6 Do the features in your specification introduce state that persists across browsing sessions?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.7 Do the features in your specification expose information about the underlying platform to origins?
+
+**Handling hardware context reset:** Currently "hardware context reset" only happens on Windows. So the site could guess it's a Windows OS if it happens.
+
+**Querying encryption scheme support:** The `MediaKeySystemMediaCapability.encryptionScheme` attribute, returned from MediaKeySystemAccess.getConfiguration(), indicates the encryption scheme associated with the content type. This gives an indication of which encryption schemes the underlying platform supports.
+
+**HDCP policy detection:** The `MediaKeys.getStatusForPolicy()` method returns information about which HDCP policy versions the underlying platform supports.
+
+## 2.8 Does this specification allow an origin to send data to the underlying platform?
+
+EME allows an origin to send encrypted media to a platform-level content decryption module (CDM) for playback, as well as a browser-intermediated negotiation of license keys between the origin and the CDM.
+
+**Handling hardware context reset:** No additional data beyond the above.
+
+**Querying encryption scheme support:** No additional data beyond the above.
+
+**HDCP policy detection:** No additional data beyond the above.
+
+## 2.9 Do features in this specification enable access to device sensors?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.10 Do features in this specification enable new script execution/loading mechanisms?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.11 Do features in this specification allow an origin to access other devices?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.12 Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.13 What temporary identifiers do the features in this specification create or expose to the web?
+
+**Handling hardware context reset:** No temporary identifiers.
+
+**Querying encryption scheme support:** No temporary identifiers.
+
+**HDCP policy detection:** No temporary identifiers.
+
+## 2.14 How does this specification distinguish between behavior in first-party and third-party contexts?
+
+**Handling hardware context reset:** Not distinguished. But EME usage in general is controlled by permission policy. https://w3c.github.io/encrypted-media/#permissions-policy-integration
+
+**Querying encryption scheme support:** As above.
+
+**HDCP policy detection:** As above.
+
+## 2.15 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
+**Handling hardware context reset:** No difference.
+
+**Querying encryption scheme support:** No difference.
+
+**HDCP policy detection:** No difference.
+
+## 2.16 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
+Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Privacy](https://w3c.github.io/encrypted-media/#privacy) sections.
+
+## 2.17 Do features in your specification enable origins to downgrade default security protections?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.18 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?
+
+**Handling hardware context reset:** These features do not introduce new BFCache-related behavior beyond what already applies to EME. EME does not currently specify BFCache handling.
+
+**Querying encryption scheme support:** These features do not introduce new BFCache-related behavior beyond what already applies to EME. EME does not currently specify BFCache handling.
+
+**HDCP policy detection:** These features do not introduce new BFCache-related behavior beyond what already applies to EME. EME does not currently specify BFCache handling.
+
+## 2.19 What happens when a document that uses your feature gets disconnected?
+
+**Handling hardware context reset:** These features do not introduce new behavior for disconnected documents beyond what already applies to EME.
+
+**Querying encryption scheme support:** These features do not introduce new behavior for disconnected documents beyond what already applies to EME.
+
+**HDCP policy detection:** These features do not introduce new behavior for disconnected documents beyond what already applies to EME.
+
+## 2.20 Does your spec define when and how new kinds of errors should be raised?
+
+**Handling hardware context reset:** Yes. When a hardware context reset occurs, the session is closed and the `closed` promise resolves with `MediaKeySessionClosedReason.hardware-context-reset`.
+
+**Querying encryption scheme support:** Yes. `requestMediaKeySystemAccess()` rejects with `NotSupportedError` when no configuration with a recognized encryption scheme can be supported.
+
+**HDCP policy detection:** Yes. `getStatusForPolicy()` resolves with a `MediaKeyStatus` value reflecting whether the policy can be supported (e.g., `usable` or `output-restricted`).
+
+## 2.21 Does your feature allow sites to learn about the user’s use of assistive technology?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** No.
+
+**HDCP policy detection:** No.
+
+## 2.22 What should this questionnaire have asked?
+
+N/A