In the HTML5 context, adaptive streaming is done with the MSE API. This involves fetching the media data using XHR. Since mixed-content XHR is blocked, if the a

In the HTML5 context, adaptive streaming is done with the MSE API. This involves fetching the media data using XHR. Since mixed-content XHR is blocked, if the app is on an https origin, the media data has to come from https origins, because cross-scheme CORS is blocked for security reasons. You want to have the app on https for several reason, starting with the security of session cookies, but in the case of DRM, there's a reason for browsers to seek to limit the EME API (the JS API for communicating with the DRM component) to https (though AFAIK no browser does so at the moment): DRM schemes usually implement node locking, i.e. anti-cloneability of the DRM state from one device to another. The obvious way to do this involves keys that no other device has. If information about the possession of a persistent key that no other device has is exposed to a network eavesdropper (e.g. by presenting, in the clear, a certificate for a unique key), the eavesdropper can use that piece of information to track devices and, therefore, users. While this problem could be mitigated in the design of the DRM protocol, to move addressing the problem out of what the DRM component controls to what the browser controls, limiting EME to https is the most straight-forward solution that can be implemented on the browser level. And as noted above, this has the side effect of limiting the MSE-feeding XHR to https, which means the media data needs to be served over https.