Re: The TAG and the Security Disclosures BP doc

Hadley, all,

As I explained in my response to your GitHub post, the *intention* of EME
is that users could not be exposed to unethical or malicious
implementations of EME without browser or OS *collusion* or at least
*negligence*.

So I am concerned that you have neither refuted nor acknowledged my
assertion and yet repeat the notion of unethical or malicious
implementations of EME as a serious concern.

Do you believe that users could be exposed to such implementations *without*
browser or OS collusion or negligence ? If so, I'd like to close that
loophole! Please provide more detail on how you think that could happen.

Or, are you concerned about the case of browser or OS collusion or
negligence ? If so, can you explain why you pick on EME specifically ?

Browsers and OS implementors are strongly incentivized to retain user
trust. And so, EME represents a significant change in how DRM is integrated
and the scope for "unethical or malicious" behaviour. W3C has played a
significant role in effecting this change but the TAG's lack of recognition
of this point risks undermining this (in particular, W3C's ability to
communicate this aspect of the EME architecture to the wider world).

...Mark



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
>