Re: The TAG and the Security Disclosures BP doc

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