- From: Philippe Le Hégaret <plh@w3.org>
- Date: Thu, 27 Apr 2017 14:20:09 -0400
- To: Hadley Beeman <hadley@linkedgov.org>
- Cc: www-tag <www-tag@w3.org>
Hi Hadley, I spent time with Dan while in Beijing to go over the TAG issue. I wanted to make sure I understand the issue first. Regarding the BP document, it's not clear to me whether we'll continue the work or not yet. We heard concerns that the BP may be more harmful than helpful, in particular from the EFF. I expect to work with Tim on the particular TAG issue btw since he had similar concerns regarding the sandboxing. He met with the Group last week but, due to the AC meeting, I didn't have time to close the loop with him on this front. There is also the user content part as well. Having said that, here are some thoughts below. On 4/27/2017 3:06 AM, Hadley Beeman wrote: > 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. First, let me state that the best way to address the issue is by changing the laws themselves, DMCA or WIPO. Short of that, W3C may be able to come up with some useful adjuncts but you can't expect those to be applicable to the entire industry or even all W3C Members. We already looked into making the covenant a requirement and concluded it's unlikely that the most interesting part of our Members would sign up on this, even if it was refined. Narrowing the scope of the covenant to some agreeable text by all parties failed (unlike our Patent Policy). It's also important to differentiate EME and the underlying CDM in this debate. If there is a deliberate malicious implementation of EME, you're probably using the wrong browser anyway and there is nothing we can do to force that browser to change in any case (besides public pressure). After all, we saw cases of user agents claiming to be the most secure browser ... after they had removed all cross-origin checks! If the EME implementation is not deliberately malicious, malicious CDM implementations could be constrained by using sandboxing when implementing EME. It's possible on desktop, but less on mobile however. I also suspect set-top boxes don't use sandboxing but those boxes are pretty opaque to start with in general. It's possible to monitor communications coming out of the CDM (as well as checking File IO access). The EME spec is clear that the CDM must not perform message exchanges for the purpose of individualization for example. Section 11.3 talks about threats related to information leakage as well but several of those are difficult to check. I didn't explore the legal implications of investigating the EME implementation rather than the underlying CDM. The BP were written with an attempt to protect both the security and the privacy of the users. Assuming we'd do more work on those, I'd be certainly interested in improvements (I'm also sure they are way more competent folks than me to do the next version). The burden of proof might be difficult to resolve however, ie who gets to say if something is security research and whether the level of information disclosed is sufficient (I was recently pointed to [1] btw). > 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. > > I'm not sure about the status of the BP document. Will work on it > continue? Is that feedback useful, or can I do anything to make it more > useful? We do want to support the effort. It would certainly be a disappointment to stop the work on the security guidelines, so thank you for your encouragement. I can't tell yet whether the work will continue or not. Philippe [1] https://www.hackerone.com/disclosure-guidelines
Received on Thursday, 27 April 2017 18:20:19 UTC