Skip to content
This repository has been archived by the owner on Feb 16, 2023. It is now read-only.

TAG review: performance benefit vs privacy #11

Open
joeyparrish opened this issue Jul 1, 2019 · 6 comments
Open

TAG review: performance benefit vs privacy #11

joeyparrish opened this issue Jul 1, 2019 · 6 comments

Comments

@joeyparrish
Copy link
Member

Noted by @hober in w3ctag/design-reviews#323 (comment):

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.

@joeyparrish
Copy link
Member Author

Re: privacy, and who can get this information, when you say "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.

@joeyparrish
Copy link
Member Author

As for performance benefit, I can say abstractly that early HDCP detection could enable a player to accurately decide what to fetch. For example, in Shaka Player avoids HD and UHD content until it has a license, then uses the key status to enable access to those resolutions if the keys are available. With the HDCP detection API, Shaka Player might be able to fetch HD/UHD before the license exchange, which would enable the user to start playback at a higher resolution.

Shaka Player hasn't made use of this API yet, and is just middleware without its own user-facing service. So my comments about performance benefit are purely abstract and not backed by data. @mwatson2, do you have anything concrete to offer about the benefits of this API for Netflix?

@joeyparrish
Copy link
Member Author

@mwatson2, do you have anything concrete to offer about the performance benefits of this API?

@joeyparrish
Copy link
Member Author

The TAG review stated that "the privacy cost is that a much larger set of sites would now have access to approximately four bits of fingerprinting". @gregwfreedman, do you have anything to offer about the performance benefits of this API? Are y'all using it, and if so, what has it enabled you to do that you couldn't otherwise do or that would cost more to do?

@mwatson2
Copy link

It's noted elsewhere in the TAG discussion that the information is already available to anyone with access to a license server, which is reasonably easy to obtain. So, this API just makes it a little easier. I wonder if the issue could be mitigated by having the implementation return a default (lowest) value to sites that have never successfully installed a license ?

Without this API, sites must either:

  • discard high quality data that has already been downloaded when the license is installed and the key status reveals high quality is not supported.
  • start playback at low quality and begin downloading high quality only after the license is installed

Depending on the approach taken by the site without the API, the availability of this API enables either faster playback start (due to never needing to download data) or higher starting quality.

Testing of other features at Netflix has revealed significant (both statistically and in magnitude) positive user response to both faster playback start and higher initial quality.

@gregwfreedman
Copy link

To add to @mwatson2, HDCP engagement can take many seconds.

  • This API allows us to start this time consuming process on page load (while user browses for content), and not wait for a license to be installed.
  • Without this API, we not only have to wait for the license to be installed, but also for KeyStatus to reach usable before downloading high quality data (which could be ~10 seconds after license is installed). In practice we see minutes of low quality data buffered on high bandwidth networks during this time.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants