Note loosening impl requirements is out of scope in SOTD

[tidoust]

Concerns were raised during the review of the new Media Working Group charter about the possible impact of the features being added to EME on user privacy, interoperability, royalty-free implementation of the standard and access to media.

This adjusts the Status of this Document section to clarify that loosening of implementation requirements that were published in the W3C Recommendation is per charter out of scope for the Media Working Group.

---

Preview | Diff

[npdoty]

I think it's good to have clarity on scope. I do think the group should plan to make updates to the privacy considerations section, though, to note the potential impacts of the new method and its likely use for fingerprinting users and detecting whether hardware is attached or not.

[marcoscaceres]

A bit more expanded:

This specification defines an extension to the Encrypted Media Extensions (EME) framework. It does not modify the baseline implementation requirements for Content Decryption Modules (CDMs) or user agents, as defined in the EME specification.

However, the Media Working Group recognizes that new features related to content protection, device capabilities, and hardware enforcement can have broader impacts on user rights and platform interoperability. In particular, this extension may introduce new considerations around:

• Privacy, such as fingerprinting surfaces related to hardware or CDM configuration;
• Accessibility, where content protection mechanisms may interfere with assistive technologies or prevent post-processing for accessible media presentation;
• Equitable access, where technical or commercial constraints may disproportionately limit access for users on alternative platforms, older devices, or in under-resourced settings;
• Interoperability, as inconsistencies in CDM behavior, hardware enforcement, or media capability queries can result in divergent implementations across browsers and devices.

These impacts are discussed further in the Privacy and Security Considerations, Accessibility Considerations, and related sections. Where applicable, the Working Group documents known risks and trade-offs, and encourages implementers to mitigate negative effects.

The Working Group aims to support an interoperable web ecosystem and encourages future extensions to explicitly balance content protection goals with user privacy, accessibility, equitable media access, and multi-vendor interoperability.

This might be in it's own section, or the introduction or something...

[chrisn]

We have a work in progress PR that considers the security and privacy impacts of each feature addition the group has been working on so far: #550. Our charter requires us to document accessibility considerations in each spec. EME doesn't currently have an Accessibility Considerations section, but this could be a place to document them.

[npdoty]

Just saying more broadly that all of these features will have impacts, but that the impacts will be documented and hopefully balanced in some way doesn't appear to set any clear limits on the scope at all. I agree that the group should document those things if it chooses to standardize this new and potentially harmful technology.

Balancing "content protection goals" against these other properties would seem to be re-negotiating the priority of constituencies in a way that significantly demotes users. I think better would be to explicitly note that the group will prioritize privacy, accessibility, media access and interoperability. If a proposal harms those features, then the group shouldn't pursue it, even if it advances some other stakeholder's goals.

[joeyparrish]

Concerns were raised during the review of the new Media Working Group charter about the possible impact of the features being added to EME on user privacy, interoperability, royalty-free implementation of the standard and access to media.

I don't think I understand these concerns. Can you give some specific concerns? How does this change address them?

[npdoty]

The comments I noted in the Advisory Committee review were (I can make them public since I wrote them myself):

I'm concerned that more expansive work on DRM-related technology has the potential to invade user privacy (and require effort to maintain what privacy protections exist), break interoperability, interfere with royalty-free implementation of web standards and reduce access to media. If the group wants to do further development in that direction, let's try to work on reducing those potential harms.

Those were noted to be similar to comments from the W3C TAG.

More specifically, some concerns are that extensions of EME would reveal to sites more detailed information about the equipment that people have that might be used to display media, and could be used to programmatically exclude access to people with equipment that doesn't support the most specific or most restrictive HDCP levels, or require royalties to implement particular versions. Providing that kind of detail and more specific restriction could hurt users and reduce access to media.

[chrisn]

Discussed in Media WG meeting, 12 May 2026: https://www.w3.org/2026/05/12-mediawg-minutes.html#fee2

Thanks @npdoty. There was a suggestion in our last meeting to rephrase our intent in a more positive sense, so I've just changed the proposed text.

To address the concerns, we'll need to discuss further in the working group.

Some of the features added, e.g., continuous key rotation, can be argued to make more media content available to users on the web, e.g., for live sports events or other high value continuous live streams.

Given there's more work to do on those concerns, and there's only so much we can address via the SOTD, is the proposed change enough to resolve this particular issue?

[npdoty]

I agree that addressing the concerns will take further work in the Working Group. That work might consist of documenting the harms of DRM to privacy, security, accessibility, interoperability, royalty-free implementation and access to media, defining specific principles for what the WG is and is not willing to accept on each of those, and giving specific reasoning for how additional DRM functionality will be designed in order to ensure that the trade-offs for users on those fronts are more likely to be beneficial.

For this PR, though, I'm unclear what would change. That a spec cites its own requirements and says that sections of requirements will continue to be requirements doesn't add any new meaning. That isn't a commitment to a particular scope, or a commitment that user privacy and security won't be decreased from where they are today, or a description of any principles about how the Working Group will try to ensure that features lead to more access to media rather than less access to media. If the Working Group instead wants to indicate that there will be no loosening of requirements from previously published Recommendations and no regression in user privacy and security as a result of updates to the spec, that would be a useful clarification. But my current understanding is that the changes in the spec definitely won't satisfy that.

There isn't a particular open issue that's being addressed here. I raised a concern during the charter update. W3C declined to address that concern during chartering. Updating the Status of the Document to mention other sections of the spec doesn't seem like useful guidance; if that's all that's acceptable, I think it would be simpler to close this PR without merging.