Note: Not a full review.

One bit from a API consistency perspective: If there are other cases in the platform that allow scoping of versions, it probably would make sense for this to be consistent. (e.g. One API requiring {'over': '1.0'} and another requiring {'minVersion': '1.0'} would be suboptimal.)

Curious how this would tie into [1] remote playback devices which are connected to a HDCP display - the current spec design seems like even if one has a HDCP capable playback device/display pair as a remote device one would still get a low-res fallback.

[1] https://w3c.github.io/remote-playback

Note: also not a full review.

This proposal involves a privacy/performance tradeoff that I'm concerned with.

The performance benefit of having a way to do an upfront HDCP policy check is that sites which use EME can know whether or not, and what level of, HDCP playback is available before loading any media. This performance benefit is real, but fairly small.

The existing way to check for HDCP requires a successful key exchange, which means that only sites trusted by the CDM can query this. The proposed API can be called by sites that are not trusted by the CDM. Thus, the privacy cost is that a much larger set of sites would now have access to approximately four bits of fingerprinting.

Have you considered PING's security and privacy questionnaire? I think question 4.6 is particularly relevant: https://w3ctag.github.io/security-questionnaire/#underlying-platform-data

Hi @joeyparrish,

We briefly discussed this issue at our F2F today, and we're wondering if you could quantify the performance benefit here?

Some question about what the status is here... We have discussed today closing this issue preemptively.

Looks like this is shipping in Chrome.

Sorry, everyone, for dropping the ball on responding to the feedback given here.

@cynthia, we have no plans for a maximum HDCP version check, as content security policies only ever go in one direction.

To your point about the remote playback API, we hadn't really considered that. And I don't see any mention of EME in the remote playback spec, so I'm not sure how remote playback will work with EME generally. I will reach out to the editors of the remote playback spec about this.

@hober, re:

The existing way to check for HDCP requires a successful key exchange, which means that only sites trusted by the CDM can query this.

There's no such thing as "sites trusted by the CDM". The CDM has no knowledge of the context in which it is running, and the license exchange is actually carried out by the web app. So the reality is that the sites which can do this today are "sites that have access to a license server". Several open-access license servers exist for the purposes of testing and integration, and their CORS headers allow access from "*". So this becomes all sites running in a secure context. Any HTTPS-hosted site can do a license exchange with these open license servers.

@hober, moving privacy vs performance discussion to https://github.com/WICG/hdcp-detection/issues/11. Thanks!

@cynthia, moving discussion of remote playback vs EME to https://github.com/w3c/remote-playback/issues/124. Thanks!

It looks like it’s implemented in Gecko as well as Blink.

Hi,

@plinss and I looked at this at our Cupertino F2F. It looks like this is implemented in two browser engines, but there’s a bunch of spec work left to do. Please let us know when the spec is more fleshed out.

We’re going to close this issue, as all of the concerns TAG participants raised earlier have been filed as issues on the spec. Please open a new design review issue if you significantly change the API.