search

w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
177 stars 79 forks source link

Clarity regarding Robustness string in EME Spec #521

Open gvking opened 6 months ago

gvking commented 6 months ago

In the EME Spec, it currently states

Exact configuration of the CDM is implementation-specific,and implementations MAY configure the CDM to use the highest robustness level in the configuration even if a higher robustness level is available.

On reading this, 1) it's kind of hard to understand 2) Does it make more sense that the sentence is replaced with: MAY configure the CDM to use the highest robustness level in the configuration even if a lower robustness level is available.

This second sentence makes a little more sense to me, since highest -> higher doesn't add up.

gvking commented 6 months ago

It may also make sense that the spec was trying to say

MAY configure the CDM to use the lowest robustness level in the configuration even if a higher robustness level is available, and then lead into how when robustness is the empty string, the implementation may default to the lowest one available.

In any case, this bug is for discussion so we can get some clarity over what the sentence is supposed to be.

joeyparrish commented 2 months ago

AFAICT, there is nothing specified about how robustness levels are chosen or defined.

I believe a robustness level in a configuration is a minimum requirement for the application. Therefore, the CDM could provide a higher level, but never a lower one than requested. If I say "I'll take level 3000 please", the CDM may only have the DRM vendor's level 5000 available, but that's fine. It's more robust than my application's minimum requirement.

The full note currently says:

Implementations MUST configure the CDM to support at least the robustness levels specified in the configuration of the MediaKeySystemAccess object used to create the MediaKeys object. Exact configuration of the CDM is implementation-specific, and implementations MAY configure the CDM to use the highest robustness level in the configuration even if a higher robustness level is available. If only the empty string is specified, implementations MAY be configured to use the lowest robustness level the implementation supports.

I believe it should say:

Implementations MUST configure the CDM to support at least the robustness levels specified in the configuration of the MediaKeySystemAccess object used to create the MediaKeys object. Exact configuration of the CDM is implementation-specific, and implementations MAY configure the CDM to use a higher robustness level than those in the configuration, but is not required to provide the highest level available. If only the empty string is specified, implementations MAY be configured to use the lowest robustness level the implementation supports.

I welcome everyone's feedback, but if I don't hear anything in the next couple of weeks, I'll go ahead and edit the spec accordingly and close this issue.

joeyparrish commented 2 months ago

@xhwang-chromium, @jernoble, would this make sense to y'all in particular?

gregwfreedman commented 1 month ago

On one platform, we noticed that there was a problem with a specific robustness, which happened to be the highest. We wanted the CDM to be configured with the lower robustness. Using the robustness levels above as an example, we specified 3000 in the configuration. Even though the platform has 5000 available, we specifically didn’t want the CDM to use that configuration.

So even though a “higher robustness level is available”, we relied on the fact that the CDM would “use the highest level in the configuration” and not higher.

I think the confusion comes from the fact that the argument is a sequence of MediaKeySystemMediaCapability.

joeyparrish commented 1 month ago

On one platform, we noticed that there was a problem with a specific robustness, which happened to be the highest. We wanted the CDM to be configured with the lower robustness. Using the robustness levels above as an example, we specified 3000 in the configuration. Even though the platform has 5000 available, we specifically didn’t want the CDM to use that configuration.

I'm familiar with this pattern. But I'm a little unsure if we want to specify this selection behavior. I think we could, maybe with something like: "select the lowest-robustness CDM with a robustness equal to or greater than the requested robustness".

Robustness strings that exist for key systems I'm familiar with are ordered. PlayReady's are actual numbers, which makes the "greater than" part clear, but Widevine's are descriptive text whose ordering is less clear without documentation from Widevine. I think we could maybe say that the exact strings and their order are key-system-specific.

What we have to be careful about is that we can't simply say "highest in the configuration". We have to allow for a higher robustness to be chosen by the UA. I may have a device that only contains Widevine L1 in hardware, but no L3 software-only CDM. If I ask for SW_SECURE_DECODE, I will get HW_SECURE_ALL, because that's what there is. The one available implementation at level HW_SECURE_ALL is the correct choice, it satisfies my requirement, and it doesn't break my app.

I think the confusion comes from the fact that the argument is a sequence of MediaKeySystemMediaCapability.

Ah, I see. So this part?

Implementations MUST configure the CDM to support at least the robustness levels specified...

Supporting the plural levels here is confusing?

I think the way "levels" makes sense is that audio and video robustness often vary. We should make the note more explicit in any case.

xhwang-chromium commented 1 month ago

Sorry for being late in the discussion.

Pasting the current text here (from https://github.com/w3c/encrypted-media/issues/521#issuecomment-2111188345) for easier reading:

Implementations MUST configure the CDM to support at least the robustness levels specified in the configuration of the MediaKeySystemAccess object used to create the MediaKeys object. Exact configuration of the CDM is implementation-specific, and implementations MAY configure the CDM to use the highest robustness level in the configuration even if a higher robustness level is available. If only the empty string is specified, implementations MAY be configured to use the lowest robustness level the implementation supports.

My thoughts on this text:

With that, here's my understanding of the full note (all "levels" are robustness levels):

  1. the actual level of the CDM MUST >= the highest level in the configuration
  2. the actual level of the CDM MAY == the highest level in the configuration, even if a higher level is supported by the CDM.
  3. if only empty level specified, the actual level of the CDM MAY == the lowest level supported by the CDM.

(2) doesn't rule out the possibility of "the actual level of the CDM > the highest level in the configuration", which is what's being debated in https://github.com/w3c/encrypted-media/issues/521#issuecomment-2123264496 and https://github.com/w3c/encrypted-media/issues/521#issuecomment-2127653041. @joeyparrish's argument makes sense from content security perspective, that a higher robustness level is a super set of a lower robustness level in terms content security features. But I guess @gregwfreedman is more from a stability perspective, that if a higher robustness level is less stable, the player would rather use a lower robustness level and doesn't want the "upgrade".

In Chromium, we do the "auto upgrade" in one platform when we are sure that both the content security and robustness levels are better, and in the majority cases we strictly use "the highest level in the configuration" to allow the JS application to control the exact behavior.

So we need to decide on whether we allow "the actual level of the CDM > the highest level in the configuration". It's probably cleaner to disallow it in the spec, but in reality we already have existing systems that are not compliant. So it's probably simpler to just allow this flexibility?

chrisn commented 1 month ago

We shouldn't have normative requirements in notes, so I wonder if we should take the current spec text out of the note and a new note to provide an illustrative example.

xhwang-chromium commented 1 month ago

Good point! Does that mean we should not have MUST in notes? Searching in the current spec and we actually have multiple cases where we use MUST or MUST NOT in notes... Sometimes we use lowercase must and must not in notes. Are those okay?

chrisn commented 1 month ago

Yes, it means we shouldn't say MUST in notes, but also other RFC 2119 words (see the style guide). The Conformance section of the spec suggests lower case is OK, but I think it's better to avoid that.

I suggest we review all the notes, but in a separate issue. Some of them seem to place requirements on authors (which relates to https://github.com/w3c/encrypted-media/issues/531).

joeyparrish commented 1 month ago

With that, here's my understanding of the full note (all "levels" are robustness levels):

  1. the actual level of the CDM MUST >= the highest level in the configuration
  2. the actual level of the CDM MAY == the highest level in the configuration, even if a higher level is supported by the CDM.
  3. if only empty level specified, the actual level of the CDM MAY == the lowest level supported by the CDM.

In the meeting, we agreed to drop point 2, which is a logical implication of point 1. If X must be >= Y, X may be == Y.

We also agreed to move point 1 to normative text. Point 3 can be an explanatory note.

I'll make a PR.