security vulnerability and the CDMs

Dear Tag,

I am really surprised and not a little disappointed to see the TAG doubling down on the so-far unsubstantiated claim that all CDMs are necessarily, by virtue of being CDMs, untrustworthy and suspect, especially after Mark and I discussed it with you both in email, and with Dan face to face. You seem to remain confused about the differences between any module:
a) downloaded by the user in binary form: all these are suspect, and this is not a characteristic unique to CDMs;
b) accepted by the browser or platform vendor in binary form and distributed by them: the entity distributing them to the user had better be reasonably sure the binary module won’t do anything it should not; again, nothing specific to CDMs
c) implemented by the browser or platform vendor: there is no reason to consider the CDM as any different from all the other code supplied by the same vendor. If that vendor wants to spy on the user, they supplied the browser and/or OS; why would they focus on putting such spying in the CDM module?

I think you need to explain your thinking here, or retract the assumption — for that is what it appears to be. Can you explain what circumstance you envisage, as it is less than clear?

Thanks

> 
> On Thu, Apr 27, 2017 at 12:06 AM, Hadley Beeman <
> hadley@linkedgov.org
> >
> wrote:
> 
> > Hello PLH,
> >
> > In our TAG face-to-face, we've just discussed the Security Disclosures
> > doc.  As you've probably seen from the issues threads in GitHub[1,2], we
> > left the following comments:
> >
> > 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.
> >
> > 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.
> >
> >
> >
> > 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.
> >
> > Cheers,
> >
> >    Hadley
> >
> >
> >
> > [1] 
> https://github.com/w3c/security-disclosure/issues/4
> 
> > [2] 
> https://github.com/w3c/encrypted-media/issues/389
> #
> > issuecomment-294899194
> >
David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 27 April 2017 16:28:24 UTC