Proposal for Screen Capture Protection API in EME Configuration

[Chokoabigail]

Summary:
This proposal suggests adding a configuration option to the EME API that enables screen capture protection with clear-key and/or other DRM providers (i.e., screen capture protection independently from the key deliver or management solution chosen).

Problem Statement:
Screen capture protection in video playback depends entirely on the DRM vendor's implementation. There is no standard way for developers to request or check screen capture protection through the EME API. This lack of control causes confusion and limits developers' ability to provide even best-effort protection against screen capture for sensitive content.

Proposed Solution:
Introduce a new optional configuration field in the EME API initialization that allows developers to request screen capture protection.

Use Case:
Video streaming platforms can enforce (at least as a best effort) screen capture protection when required, currently, the only option is to use a full fladge DRM (even if all the end-user care is a simple solution for non-tech people, and not interested in the full-fladge real DRM)

Benefits:
Standardizes screen capture protection requests.
Reduces developer confusion about EME and provides a clear API-level intent.
Encourages more consistent DRM implementations across platforms.

Considerations:

• Browser vendors will need to align with DRM vendors to ensure consistent support.
• This feature would be best-effort, not guaranteed, depending on OS and DRM system capabilities, for those who want high-level security they would still need to go through a proper DRM.

[tanalam]

In the content license there is capture protection & redistribution property (content sharing on another screen) .
This is controlled by the content provider.
Will not there be a conflict when this control is given at app level. License may have different attribute than what the application sets.
Secondly, what is the point of having a feature which is best effort based (Consider from user experience point of view).
A user may have in-consistent effort

[joeyparrish]

My opinion is that this should be parallel to fields like persistent-state. If we had a field called screen-capture-protection, and it worked like persistent-state and distinctive-identifier, these would be true:

1. An application queries EME with screen-capture-protection: "required". If the request succeeds, the application knows screen caps will be prevented by the key system. The application can use this information to make high-level business decisions about streaming (do stream UHD, etc).
2. Same as above, but the request fails. The application can make a second request without that requirement, and will know that no screen cap protection will be provided. The app can use this information to make high-level business decisions about streaming (maybe don't stream UHD, etc).

Today, applications have no idea if screen cap protection is happening or not. For example, I don't believe this exists for Widevine on Linux, but does for Widevine on other platforms. It would be an improvement, IMO, to provide an API to ask, rather than require apps to guess or hard-code implementation details that may change (like assuming protection on Windows, but not on Linux).

This would be in line with what already exists in EME: for robustness, for persistent-state, for distinctive-identifier, EME allows an app to say "required" and get a clear response on those requirements.

@Chokoabigail, is this in line with what you want? Would this solve your problem?

[Chokoabigail]

@joeyparrish Yes, this can be a good start.
In addition, building upon your suggestion, I propose we explore enhancing EME to offer an optional, best-effort capture protection mechanism for ClearKey.

Currently, EME is DRM-agnostic, with CDMs handling DRM-specific logic, including key management and policy enforcement. We have two primary paths:

A. ClearKey: A simple, cost-effective encryption method. Its primary drawback is the lack of robust security features, particularly the absence of TEE-based protection, making it vulnerable.
B. Full DRM Systems (Widevine, PlayReady, etc.): Offer comprehensive protection, especially with hardware-backed security. However, achieving broad compatibility often involves using less strict configurations, creating a security-usability tradeoff.

My proposal: Extend EME to allow the option for a software-based, best-effort capture protection mechanism to be implemented when using ClearKey.

Rationale:
A. Address a Gap: While ClearKey is inherently less secure, adding a best-effort capture protection layer (similar to Widevine L3's capabilities) would offer an incremental improvement.
B. Security-Usability Balance: ClearKey remains the simplest and least restrictive option. For content where robust DRM is overkill or cost-prohibitive, this addition provides a middle ground.
C. Content Creator Choice: Content creators needing stronger, guaranteed protection can still utilize TEE-based DRM solutions. This proposal simply adds a lightweight option for ClearKey users.
D. Leverage Browser Capabilities: Browsers already possess APIs (as seen with Widevine L3 and other less restrictive DRM flavors) that could be used to implement software-based capture protection.

This would not make ClearKey as secure as a full DRM, but it would provide a valuable, optional layer of basic capture protection within its existing framework.