Allow getStatusForPolicy() to reject the promise with NotSupportedError

[xhwang-chromium]

The getStatusForPolicy() API was proposed as the solution to https://github.com/w3c/encrypted-media/issues/311, to provide a method to early detect the HDCP status.

The current explainer is at https://github.com/WICG/hdcp-detection/blob/main/explainer.md, which states that:

If HDCP is available at the specified version, the promise should return a MediaKeyStatus of "usable". Otherwise, the promise should return a MediaKeyStatus of "output-restricted"...

A MediaKeyStatus value of "status-pending" must never be returned. Implementers must give decisive actionable return values for developers to make decisions about what content to fetch.

However, there are platforms where the CDM can enforce HDCP status internally, but there's no easy way (e.g. lack of exposed API) to detect the HDCP status without creating a MediaKeySession or obtaining a license. In this case, returning usable or output-restricted are both wrong and misleading.

After talking with @joeyparrish, we propose to allow getStatusForPolicy() to return a rejected promise with NotSupportedError, when the CDM might be able to enforce HDCP, but there's no way to detect it in advance. Applications can still use other ways to detect HDCP status, e.g. after obtaining a license.

User agents should strive to return a meaningful status whenever possible. If we know that a certain class of device or a certain version of the OS can't enforce HDCP at all, we should return output-restricted.

[xhwang-chromium]

@gregwfreedman Please share your thoughts on this issue. Thanks!

Also, this should be in EME V2 since https://github.com/w3c/encrypted-media/issues/311 is scheduled to be in V2.

[gregwfreedman]

I agree that the promise should be rejected with NotSupportedError when the user agent/cdm cannot detect HDCP capabilities in advance.

OOC, under what circumstances would a user agent/cdm not be able to determine the HDCP capabilities?

[xhwang-chromium]

OOC, under what circumstances would a user agent/cdm not be able to determine the HDCP capabilities?

For example, older Android devices don't have a way to determine HDCP capabilities without doing a license exchange. Though we don't need support those older Android device anymore, the same issue could happen on other OS or devices.

[xhwang-chromium]

I tried to update https://github.com/WICG/hdcp-detection/blob/main/explainer.md with this proposal, but that repo is in read-only mode:

This repository has been archived by the owner on Feb 15, 2023. It is now read-only.

So I'll try to propose an edit here instead.

Instead of:

If HDCP is available at the specified version, the promise should return a MediaKeyStatus of "usable". Otherwise, the promise should return a MediaKeyStatus of "output-restricted". The determination of HDCP status should be done in the same way that the CDM would enforce such a restriction during playback. In this way, application developers can get a reasonable hint to allow them to optimize what content they fetch to start playback.

I propose to change it to be:

If the HDCP status cannot be determined (e.g. lack of API to do so), the promise should be rejected with "NotSupportedError". Otherwise, the promise should be resolved with "usable" or "output-restricted", if HDCP is available or unavailable at the specified version. The determination of HDCP status should be done in the same way that the CDM would enforce such a restriction during playback. In this way, application developers can get a reasonable hint to allow them to optimize what content they fetch to start playback.

[xhwang-chromium]

Also, for the record, we discussed this issue during the Media WG meeting, and there was no concerns on the idea.

[chrisn]

@xhwang-chromium I have copied the explainer to this repo, here, Would you like to update it?

[gregwfreedman]

@Chris Needham @.***> is that one different than the one here https://wicg.github.io/hdcp-detection/?

On Tue, Dec 12, 2023 at 9:04 AM Chris Needham @.***> wrote:

@xhwang-chromium https://github.com/xhwang-chromium I have copied the explainer to this repo, here https://github.com/w3c/encrypted-media/blob/main/hdcp-detection-explainer.md, Would you like to update it?

— Reply to this email directly, view it on GitHub https://github.com/w3c/encrypted-media/issues/513#issuecomment-1852448301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVHVMN4AXXN3LCPBUYV4SDYJCFBHAVCNFSM6AAAAAA5ZPE57SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJSGQ2DQMZQGE . You are receiving this because you were mentioned.Message ID: @.***>

[chrisn]

https://wicg.github.io/hdcp-detection/ is the original draft spec, now merged into the main EME spec. The document I copied over is different, it's the explainer, in case it needs updating (which we can't do in an archived repo).

[xhwang-chromium]

@xhwang-chromium I have copied the explainer to this repo, here, Would you like to update it?

@chrisn Thanks for the ping. Do we still want to maintain the explainer given we already merged it into the main EME spec?

[chrisn]

I think it's worth adding your proposed edit in https://github.com/w3c/encrypted-media/issues/513#issuecomment-1760505297, but beyond that, probably not.

[joeyparrish]

The explainer was updated, and the editor's draft spec already specifies getStatusForPolicy rejecting with NotSupportedError, so I think this can be closed.

If the CDM cannot determine the MediaKeyStatus for the dictionary member, then reject promise with NotSupportedError and abort these steps.