From 7ae6844f7a19a7087d6f5b5d167a19aa58623e05 Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Thu, 20 Jun 2024 14:51:59 +0100
Subject: [PATCH 01/12] Added TAG security and privacy questionnaire

---
 security-privacy-questionnaire.md | 148 ++++++++++++++++++++++++++++++
 1 file changed, 148 insertions(+)
 create mode 100644 security-privacy-questionnaire.md

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
new file mode 100644
index 0000000..0fffb55
--- /dev/null
+++ b/security-privacy-questionnaire.md
@@ -0,0 +1,148 @@
+# Encrypted Media Exensions v2 Self-Review Questionnaire: Security and Privacy
+
+Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 2024)
+
+## 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 using setting the device to sleep/resume, or switching monitors. Sites will not be able to know the exact reason. This exposure is necessary for sites to provide the best user experience.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 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 expose an enum summarizing the reason.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 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 info is exposed.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.4 How do the features in your specification deal with sensitive information?
+
+**Handling hardware context reset:** No sensitive information.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.5 Do the features in your specification introduce state that persists across browsing sessions?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+
+## 2.6 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 an Windows OS if it happens.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.7 Does this specification allow an origin to send data to the underlying platform?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.8 Do features in this specification enable access to device sensors?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.9 Do features in this specification enable new script execution/loading mechanisms?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.10 Do features in this specification allow an origin to access other devices?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.11 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:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.12 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:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.13 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:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.14 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:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.15 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.16 Do features in your specification enable origins to downgrade default security protections?
+
+**Handling hardware context reset:** No.
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.17 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:** TODO
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.18 What happens when a document that uses your feature gets disconnected?
+
+**Handling hardware context reset:** TODO
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.19 What should this questionnaire have asked?
+
+N/A

From 950d10d4c1cf28e925639ff41b1c8dec9fb30298 Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Thu, 8 Aug 2024 20:18:19 +0100
Subject: [PATCH 02/12] Update security and privacy questionnaire

---
 security-privacy-questionnaire.md | 59 +++++++++++++++----------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index 0fffb55..c44077b 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -12,7 +12,7 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 ## 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 expose an enum summarizing the reason.
+**Handling hardware context reset:** Yes. It only exposes an enum summarizing the reason.
 
 **Querying encryption scheme support:** TODO
 
@@ -20,100 +20,99 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 ## 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 info is exposed.
+**Handling hardware context reset:** No such information is exposed.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No such information is exposed.
 
-**HDCP policy detection:** TODO
+**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:** No sensitive information.
+**Handling hardware context reset:** The features do not deal with any sensitive information.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** The features do not deal with any sensitive information.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** The features do not deal with any sensitive information.
 
 ## 2.5 Do the features in your specification introduce state that persists across browsing sessions?
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
-
-**HDCP policy detection:** TODO
+**Querying encryption scheme support:** No.
 
+**HDCP policy detection:** No.
 
 ## 2.6 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 an Windows OS if it happens.
 
-**Querying encryption scheme support:** TODO
+**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:** TODO
+**HDCP policy detection:** The `MediaKeys.getStatusForPolicy()` method returns information about which HDCP policy versions the underlying platform supports.
 
 ## 2.7 Does this specification allow an origin to send data to the underlying platform?
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.8 Do features in this specification enable access to device sensors?
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.9 Do features in this specification enable new script execution/loading mechanisms?
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.10 Do features in this specification allow an origin to access other devices?
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.11 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:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.12 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:** TODO
+**Querying encryption scheme support:** No temporary identifiers.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No temporary identifiers.
 
 ## 2.13 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:** TODO
+**Querying encryption scheme support:** As above.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** As above.
 
 ## 2.14 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:** TODO
+**Querying encryption scheme support:** No difference.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No difference.
 
 ## 2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
 
@@ -123,9 +122,9 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 **Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.17 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?
 

From e6f54deb2f8ed2c3dd79dfa95de04592b2403e50 Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Fri, 9 Aug 2024 15:48:51 +0100
Subject: [PATCH 03/12] Add more detail to security and privacy questionnaire

---
 security-privacy-questionnaire.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index c44077b..7095e24 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -6,9 +6,9 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 **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 using setting the device to sleep/resume, or switching monitors. Sites will not be able to know the exact reason. This exposure is necessary for sites to provide the best user experience.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** The API exposes whether the implementation supports CENC or CBCS encryption, or both. These two encryption schemes are incompatible, so the API allows websites to make intelligent choices about what content to serve to which user agents.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** The API exposes whether a 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?
 
@@ -52,11 +52,13 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 ## 2.7 Does this specification allow an origin to send data to the underlying platform?
 
-**Handling hardware context reset:** No.
+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.
 
-**Querying encryption scheme support:** No.
+**Handling hardware context reset:** No additional data beyond the above.
 
-**HDCP policy detection:** No.
+**Querying encryption scheme support:** No additional data beyond the above.
+
+**HDCP policy detection:** No additional data beyond the above.
 
 ## 2.8 Do features in this specification enable access to device sensors?
 

From 5952bc0d1bc3619828accb51d886b0d68c963827 Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Thu, 21 Aug 2025 10:46:45 +0100
Subject: [PATCH 04/12] Update to latest S&P questionnaire

---
 security-privacy-questionnaire.md | 56 ++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 16 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index 7095e24..d6bd437 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -1,6 +1,6 @@
 # Encrypted Media Exensions v2 Self-Review Questionnaire: Security and Privacy
 
-Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 2024)
+Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 18 April 2025)
 
 ## 2.1 What information does this feature expose, and for what purposes?
 
@@ -34,7 +34,15 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 **HDCP policy detection:** The features do not deal with any sensitive information.
 
-## 2.5 Do the features in your specification introduce state that persists across browsing sessions?
+## 2.5 Does data exposed by your specification carry related but distinct information that may not be obvious to users?
+
+**Handling hardware context reset:** TODO
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.6 Do the features in your specification introduce state that persists across browsing sessions?
 
 **Handling hardware context reset:** No.
 
@@ -42,7 +50,7 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 **HDCP policy detection:** No.
 
-## 2.6 Do the features in your specification expose information about the underlying platform to origins?
+## 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 an Windows OS if it happens.
 
@@ -50,7 +58,7 @@ Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 24 May 202
 
 **HDCP policy detection:** The `MediaKeys.getStatusForPolicy()` method returns information about which HDCP policy versions the underlying platform supports.
 
-## 2.7 Does this specification allow an origin to send data to the underlying platform?
+## 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.
 
@@ -60,7 +68,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No additional data beyond the above.
 
-## 2.8 Do features in this specification enable access to device sensors?
+## 2.9 Do features in this specification enable access to device sensors?
 
 **Handling hardware context reset:** No.
 
@@ -68,7 +76,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No.
 
-## 2.9 Do features in this specification enable new script execution/loading mechanisms?
+## 2.10 Do features in this specification enable new script execution/loading mechanisms?
 
 **Handling hardware context reset:** No.
 
@@ -76,7 +84,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No.
 
-## 2.10 Do features in this specification allow an origin to access other devices?
+## 2.11 Do features in this specification allow an origin to access other devices?
 
 **Handling hardware context reset:** No.
 
@@ -84,7 +92,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No.
 
-## 2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+## 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.
 
@@ -92,7 +100,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No.
 
-## 2.12 What temporary identifiers do the features in this specification create or expose to the web?
+## 2.13 What temporary identifiers do the features in this specification create or expose to the web?
 
 **Handling hardware context reset:** No temporary identifiers.
 
@@ -100,7 +108,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No temporary identifiers.
 
-## 2.13 How does this specification distinguish between behavior in first-party and third-party contexts?
+## 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
 
@@ -108,7 +116,7 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** As above.
 
-## 2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+## 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.
 
@@ -116,11 +124,11 @@ EME allows an origin to send encrypted media to a platform-level content decrypt
 
 **HDCP policy detection:** No difference.
 
-## 2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+## 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.16 Do features in your specification enable origins to downgrade default security protections?
+## 2.17 Do features in your specification enable origins to downgrade default security protections?
 
 **Handling hardware context reset:** No.
 
@@ -128,7 +136,23 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 **HDCP policy detection:** No.
 
-## 2.17 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?
+## 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:** TODO
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.19 What happens when a document that uses your feature gets disconnected?
+
+**Handling hardware context reset:** TODO
+
+**Querying encryption scheme support:** TODO
+
+**HDCP policy detection:** TODO
+
+## 2.20 Does your spec define when and how new kinds of errors should be raised?
 
 **Handling hardware context reset:** TODO
 
@@ -136,7 +160,7 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 **HDCP policy detection:** TODO
 
-## 2.18 What happens when a document that uses your feature gets disconnected?
+## 2.21 Does your feature allow sites to learn about the user’s use of assistive technology?
 
 **Handling hardware context reset:** TODO
 
@@ -144,6 +168,6 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 **HDCP policy detection:** TODO
 
-## 2.19 What should this questionnaire have asked?
+## 2.22 What should this questionnaire have asked?
 
 N/A

From fb0495559c50bf53402a89baafb57d73596d020d Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Thu, 21 Aug 2025 10:50:23 +0100
Subject: [PATCH 05/12] Update to link to S&P questionnaire

---
 security-privacy-questionnaire.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index d6bd437..f09a33b 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -1,6 +1,6 @@
 # Encrypted Media Exensions v2 Self-Review Questionnaire: Security and Privacy
 
-Questionnare: https://w3ctag.github.io/security-questionnaire/ (as at 18 April 2025)
+Questionnare: 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?
 

From 7d0bdb26cea0c1ebbedcce2b14fdf0743fd44126 Mon Sep 17 00:00:00 2001
From: Chris Needham <chris@chrisneedham.com>
Date: Thu, 21 Aug 2025 15:17:17 +0100
Subject: [PATCH 06/12] Added info to S&P questionnaire

---
 security-privacy-questionnaire.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index f09a33b..362c125 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -162,11 +162,11 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 ## 2.21 Does your feature allow sites to learn about the user’s use of assistive technology?
 
-**Handling hardware context reset:** TODO
+**Handling hardware context reset:** No.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** No.
 
-**HDCP policy detection:** TODO
+**HDCP policy detection:** No.
 
 ## 2.22 What should this questionnaire have asked?
 

From 01f2895cddc89f1d21ba41a9358de4b96f1547bc Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 15:02:54 -0700
Subject: [PATCH 07/12] Fill in remaining TODO answers

---
 security-privacy-questionnaire.md | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index 362c125..a40bf78 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -14,9 +14,9 @@ Questionnare: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-202
 
 **Handling hardware context reset:** Yes. It only exposes an enum summarizing the reason.
 
-**Querying encryption scheme support:** TODO
+**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:** TODO
+**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?
 
@@ -36,11 +36,11 @@ Questionnare: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-202
 
 ## 2.5 Does data exposed by your specification carry related but distinct information that may not be obvious to users?
 
-**Handling hardware context reset:** TODO
+**Handling hardware context reset:** The `hardware-context-reset` reason aggregates multiple internal causes (such as sleep/resume and display configuration changes). The spec deliberately collapses these so that the specific cause is not exposed.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** Supported encryption schemes correlate with the underlying CDM, but that information is already implied by the chosen `keySystem` string. No novel fingerprinting surface is added.
 
-**HDCP policy detection:** TODO
+**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?
 
@@ -138,27 +138,27 @@ Yes, see the [Security](https://w3c.github.io/encrypted-media/#security) and [Pr
 
 ## 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:** TODO
+**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:** TODO
+**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:** TODO
+**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:** TODO
+**Handling hardware context reset:** These features do not introduce new behavior for disconnected documents beyond what already applies to EME.
 
-**Querying encryption scheme support:** TODO
+**Querying encryption scheme support:** These features do not introduce new behavior for disconnected documents beyond what already applies to EME.
 
-**HDCP policy detection:** TODO
+**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:** TODO
+**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:** TODO
+**Querying encryption scheme support:** Yes. `requestMediaKeySystemAccess()` rejects with `NotSupportedError` when no configuration with a recognized encryption scheme can be supported.
 
-**HDCP policy detection:** TODO
+**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?
 

From a7ea5af1ed96362997ab8bb0948e5e3397abab37 Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 15:04:21 -0700
Subject: [PATCH 08/12] Fix typos and grammar

---
 security-privacy-questionnaire.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index a40bf78..e01be6c 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -1,14 +1,14 @@
-# Encrypted Media Exensions v2 Self-Review Questionnaire: Security and Privacy
+# Encrypted Media Extensions v2 Self-Review Questionnaire: Security and Privacy
 
-Questionnare: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-20250418/ (from 18 April 2025)
+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 using setting the device to sleep/resume, or switching monitors. Sites will not be able to know the exact reason. This exposure is necessary for sites to provide the best user experience.
+**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 exposure is necessary for sites to provide the best user experience.
 
 **Querying encryption scheme support:** The API exposes whether the implementation supports CENC or CBCS encryption, or both. These two encryption schemes are incompatible, 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 a 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.
+**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?
 
@@ -52,7 +52,7 @@ Questionnare: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-202
 
 ## 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 an Windows OS if it happens.
+**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.
 

From da63e81eaecfc16ecc952e1ed349338e82ec1480 Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 15:55:15 -0700
Subject: [PATCH 09/12] Clarify purpose statements in 2.1

---
 security-privacy-questionnaire.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index e01be6c..1da2648 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -4,9 +4,9 @@ Questionnaire: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-20
 
 ## 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 exposure is necessary for sites to provide the best user experience.
+**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 whether the implementation supports CENC or CBCS encryption, or both. These two encryption schemes are incompatible, so the API allows websites to make intelligent choices about what content to serve to which user agents.
+**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.
 

From 616877f519081621207d1c866cbf49e1250bafb3 Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 16:53:54 -0700
Subject: [PATCH 10/12] Note v2 capability detection features in Fingerprinting
 section

---
 encrypted-media-respec.html | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/encrypted-media-respec.html b/encrypted-media-respec.html
index 67e8d78..c7b233b 100644
--- a/encrypted-media-respec.html
+++ b/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>

From 9a3b815323e53a73c7adfcd8bf3891b588a7d0ad Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 16:53:59 -0700
Subject: [PATCH 11/12] Refine 2.5 answer for hardware-context-reset

---
 security-privacy-questionnaire.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index 1da2648..3d4b7ba 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -36,7 +36,7 @@ Questionnaire: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-20
 
 ## 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). The spec deliberately collapses these so that the specific cause is not exposed.
+**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, but that information is already implied by the chosen `keySystem` string. No novel fingerprinting surface is added.
 

From 8be538f9008b9e9261c3fc1d50a2848062c3b154 Mon Sep 17 00:00:00 2001
From: Joey Parrish <joey.parrish@gmail.com>
Date: Thu, 7 May 2026 17:02:13 -0700
Subject: [PATCH 12/12] Align 2.5 encryption scheme answer with Fingerprinting
 section

---
 security-privacy-questionnaire.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security-privacy-questionnaire.md b/security-privacy-questionnaire.md
index 3d4b7ba..075b72c 100644
--- a/security-privacy-questionnaire.md
+++ b/security-privacy-questionnaire.md
@@ -38,7 +38,7 @@ Questionnaire: https://www.w3.org/TR/2025/NOTE-security-privacy-questionnaire-20
 
 **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, but that information is already implied by the chosen `keySystem` string. No novel fingerprinting surface is added.
+**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.