[encrypted-media] Feedback from the TAG

hadleybeeman has just created a new issue for https://github.com/w3c/encrypted-media:

== Feedback from the TAG ==
We the TAG have been discussing this document and its broader context in EME — especially since it seems to be in response to [our 2015 call for the protection of security and privacy research on the web](https://www.w3.org/blog/TAG/2015/11/16/strong-web-platform-statement/).  Though we haven’t had time to get formal TAG consensus, we did want to share some of our thoughts with you.

As the work on Encrypted Media Extensions in the W3C progresses forward, the TAG remain concerned regarding some of the user privacy implications of the architecture. Specifically we remain concerned with the imposition of an opaque piece of software, the CDM, as a required piece of the EME architecture – that this piece of software may be gathering more information about the user than is strictly required to fulfill the intended use case and that the user is not able to limit or audit the activities of this piece of software. Two mitigations against this threat which have been proposed are the effective sandboxing of the CDM and ensuring that security and privacy researchers have a free hand (pursuant to industry best practices) to disclose privacy or security vulnerabilities in the CDM without fear of prosecution under legislation such as the DMCA.

Regarding sandboxing, as the CDM is generally a closed-source proprietary component, without an opt-out mechanism users are required to execute untrusted third-party code which may not have gone through a proper security/privacy audit process. To avoid users being exploited by the malicious CDM code intentionally or unintentionally doing anything outside of the intended functionality (in this case, being content decryption) implementations are expected to sandbox the CDM’s execution environment to ensure privacy and security of the users.

This would also mitigate potential security exploits such as arbitrary code execution exploits (e.g. via buffer overflows) which target CDMs.  We would be interested in the implications of turning this SHOULD in section 10 of the EME spec ("If a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured, the user agent SHOULD ensure that users are fully informed and/or give explicit consent before loading or invoking it") into a MUST.

We also appreciate the initial work on the W3C Security Disclosure Best Practices and find that they do contribute to fostering a web ecosystem that benefits from continual testing.  We are pleased to see progress against the situation outlined in our 2015 resolution, [Assuring a Strong and Secure Web Platform](https://www.w3.org/blog/TAG/2015/11/16/strong-web-platform-statement/).

However, we find that this document covers just the use case of inadvertent security vulnerabilities in a web technology. We note that some of the concerns raised during the development of EME centre around the possibility of deliberately unethical or malicious implementations of EME — for example an implementation that might use EME APIs to exfiltrate sensitive data from a user’s operating system. These Best Practices are unlikely to help a security researcher in such a situation.  The Best Practices appear to be supporting vulnerabilities that both researchers and the specific implementor would agree need attention; our additional concern is for potential exploits that might not meet this use case. 

We want to make clear that, while this effort is a useful contribution to the problem we outlined in our resolution, it is not sufficient to adequately protect security researchers who are helping us build a stronger web.  We encourage continued development of these best practices, and want to further encourage W3C policy to continue to find new ways to assure that broad testing and security audit is able to grow on a scale in line with the development in the web.

Sincerely,
The W3C TAG

Please view or discuss this issue at https://github.com/w3c/encrypted-media/issues/389 using your GitHub account

Received on Friday, 14 April 2017 03:57:24 UTC