Re: Response from Director to formal objection "Turn off EME by default and activate only with express permission from user"

On Tue, Apr 11, 2017 at 3:49 PM, Harry Halpin <hhalpin@ibiblio.org> wrote:

>
>
> On Tue, Apr 11, 2017 at 11:39 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>>
>>
>> On Tue, Apr 11, 2017 at 2:45 PM, Harry Halpin <hhalpin@ibiblio.org>
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 10, 2017 at 7:09 AM, Mark Watson <watsonm@netflix.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Apr 10, 2017 at 10:22 AM, Harry Halpin <hhalpin@ibiblio.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 10, 2017 at 6:18 AM, Mark Watson <watsonm@netflix.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Harry,
>>>>>>
>>>>>> I agree you should have a response to your objection.
>>>>>>
>>>>>> You should take a look at the Chrome bug you cited. I believe what
>>>>>> happened is that the ability to disable Widevine went away when the ability
>>>>>> to disable plugins went away (along, I presume, with the ability to install
>>>>>> arbitrary plugins). Chrome have now introduced an explicit setting for
>>>>>> disabling protected content.
>>>>>>
>>>>>> You don't mention the main argument on this issue which is that User
>>>>>> Agent implementors are best placed to decide what permissions should be
>>>>>> mandatory, considering the security of their whole platform and the
>>>>>> relative risks from different components based on their own detailed
>>>>>> knowledge of those components. You argue that CDMs are necessarily a
>>>>>> greater risk than the rest of the implementation but even if this is true
>>>>>> we cannot say that the difference in risk is always sufficient that it
>>>>>> justifies mandatory *a priori* consent. Only the UA implementor has
>>>>>> the knowledge and broader perspective on their implementation to make that
>>>>>> judgement.
>>>>>>
>>>>>>
>>>>> That is clearly not true, as there is a conflict of interest by UA
>>>>> implementers who are also trying to make money from DRM-enabled content
>>>>> (such as Google creates both Chrome and  Youtube Red).
>>>>>
>>>>
>>>> ​Different from their conflict-of-interest when it comes to making
>>>> money from ads ?
>>>>
>>>
>>>
>>> Browser vendors can have conflicts of interest. In theory, this could be
>>> making money from ads. However, in this case, DRM is a clear conflict of
>>> interest. Google owns both Widevine and the browser, for example, and
>>> stands to make money from streaming content that requires DRM.
>>>
>>
>> ​I mean, more explicitly, that Google could clearly gain advantage by
>> having their browser pony up privacy-sensitive tracking information that
>> would enhance their ad targeting and hence their ad sales. Yet users trust
>> them not to do this in a user-hostile way. ​I don't see the situation is
>> any different with DRM, except that the amount of money Google stand to
>> make from DRM is probably insignificant compared to their ad revenue.
>>
>
> Not so. Thus interest in various ad-blockers, privacy-enhanced browsing,
> etc.
>
> One of the likely causes for this latest round of support by DRM by media,
> pushing, and now even Web companies is the long-term unreliability of
> advertising revenue. See joint Google/Microsoft study: On the near
> impossibility of measuring the returns to advertising by Randall Lewis
> (Google) and Justin Rao  (Microsoft): http://justinmrao.com/lewis_
> rao_nearimpossibility.pdf
>
>
>>
>>
>>>
>>>
>>>
>>>> If you don't trust the UA vendor with user security and privacy, I
>>>> think all bets are off.​
>>>>
>>>
>>> As someone who is currently in a room with the two crypto-engineers with
>>> Mozilla, of course users should not trust the UA vendors with security and
>>> privacy 100%. Browser vendors are usually under-resourced in terms of
>>> security and de-prioritize user-privacy. Therefore, for *powerful features*
>>> we require TLS. For *dangerous features* we require user consent.
>>>
>>> For example, with WebRTC, we keep audio/video *off by default* without
>>> user permissions. Can you please explain how WebRTC audio/video is more
>>> dangerous than opaque DRM code? After all, both are sandboxed, no?
>>>
>>
>> ​I'm not familiar with the WebRTC security considerations. Perhaps you
>> could point me at the rational for mandatory consent in that case ?​
>>
>
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#page-12
>
> See 5.2
>

​As far as I can see, that is about privacy, as David said. Obviously there
is a huge privacy problem if sites could access camera / microphone without
user permission.​ I don't think any security or privacy risk associated
with a CDM is necessarily of the same order of magnitude (which I think it
what you are claiming with this analogy).


>
>
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> Furthermore, UA implementers may not be aware of the security bugs in
>>>>> their own browsers, and thus the need for independent security research and
>>>>> audits by neutral third-parties, including end-users.
>>>>>
>>>>
>>>> ​This is why they do things like pwn2own.
>>>>
>>>
>>> See above. I am sympathetic to UA implementors, but they are
>>> under-resourced. At least in every company I've talked to, including
>>> Mozilla and Google, the security and privacy engineers (if they have a
>>> backbone, which most do) have been against DRM openly due to the security
>>> concerns brought up in the EFF petition and consider this entire
>>> standardization effort to be driven by DMCA requirements re streaming
>>> encrypted content The wider and neutral security community has spoken out
>>> and said shipping DRM with browsers that can access it via EME in dangerous.
>>>
>>
>> ​Just for for the record, as one of the organizations driving this
>> effort, our rationale for this has nothing at all to do with the DMCA and
>> everything to do with improving the user experience: specifically plug-in
>> free access to our service and access to hardware decoders to improve
>> battery life and video quality.​ Improvement in security and privacy vs
>> Silverlight is also a benefit. That's really it: hardware decoders enabling
>> 4K and soon HDR are a big deal for us. This has been a lot of work for a
>> technical refactoring exercise.
>>
>
> However, none of this technical re-factoring benefits are loss by having
> it off by default. They would only cause a problem if there was concern re
> user retention or profit loss.
>

​Being able to visit a site and watch video without annoying and confusing
consent prompts is a user experience benefit. Just to be clear, I'm not
saying there should never be prompts. I'm arguing that browsers are best
placed to decide whether and when there should be prompts.
​

>
>
>
>>
>>
>>>
>>> If there is a Google, Mozilla, or Microsoft security or privacy engineer
>>> who would like stand up and say EME is a *good thing* for user security and
>>> the wider academic community is wrong, I'm all ears to hear their
>>> explanation.
>>>
>>
>> ​I've not heard anyone argue that Flash and Silverlight etc. were better
>> for user security and privacy ​than EME. Is that what you're claiming ?
>>
>
>
> No, and I would appreciate it if you didn't claim I did.
>

>  However, wiith third-party plug-ins users had a *choice* to install them
> and they were *off by default*. So, I'm asking for EME/DRM to give users
> the same level of control and 'off-by-default' as existed pre-EME, rather
> than the loss of capabilities.
>

​I understand. But your request is predicated on the assumption that EME
CDMs _always_ and _necessarily_ bring security and privacy risks ​that are
sufficient to justify such consent and I don't think we have the evidence
for that strong an assumption.



>
>
>>
>>
>>>
>>> I'm actually *more* sympathetic to browser vendors who are being forced
>>> to implement this without adequate user protection (i.e., without it being
>>> "off by default") than by supposedly "neutral" W3C staff and PR people who
>>> are actively pushing a pro-DRM line in social media.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> Therefore, due to the bizarre legal framework around DRM and the DMCA,
>>>>> the *conservative* and safe bet is to believe that the risk MUST justify
>>>>> mandatory a priori consent. If we did it for WebRTC, I see no reason why it
>>>>> cannot be done for EME.
>>>>>
>>>>
>>>> ​We're not arguing about whether it could be done, only whether it
>>>> should be done.
>>>>
>>>
>>> Agreed, and I think it should.
>>>
>>>   cheers,
>>>       harry
>>>
>>>
>>>> ​
>>>>
>>>>>
>>>>>
>>>>>   cheers,
>>>>>     harry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ...Mark
>>>>>>
>>>>>> On Mon, Apr 10, 2017 at 9:54 AM, Harry Halpin <hhalpin@ibiblio.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Everyone,
>>>>>>>
>>>>>>> Perhaps Tim Berners-Lee (the Director) overrode my objection, but I
>>>>>>> haven't been updated and see no evidence. Also, as is often, if Tim
>>>>>>> Berners-Lee did not actually attend the transition call for Encrypted Media
>>>>>>> Extensions but either PLH or Ralph Swick acted as Director, I would like to
>>>>>>> know and demand an explicit response to my formal objection, which was
>>>>>>> viewed as in-scope by both the editors and the chair of the HME WG.
>>>>>>>
>>>>>>> Barring a decision I agree with from, I'm going to re-file my formal
>>>>>>> objection. Note that recently there has been moves to make EME (and thus,
>>>>>>> DRM) not only on-by-default, but mandatory - and hard, if not impossible,
>>>>>>> at least to disable by users [1]. This is a blatant violation of the rights
>>>>>>> of the user to control what software is on their device, and I'm surprised
>>>>>>> this feature was not agreed on by HME WG.
>>>>>>>
>>>>>>> Furthermore, it is blatantly hypocritical of the W3C to not address
>>>>>>> this concern in the Proposed Recommendation, as user control has been
>>>>>>> enforced in other specifications such as WebRTC where there are similar
>>>>>>> concerns for user fatigue. Indeed, I am stating that a user MUST be
>>>>>>> informed at least once and explicitly agree *before* an EME and, if not
>>>>>>> already pre-installed in the OS, the black box of CDM is sent to their
>>>>>>> device.
>>>>>>>
>>>>>>> The arguments from W3C PR and the HME WG that a 'sandbox' is somehow
>>>>>>> a magical solution to user concerns over security and privacy with DRM is
>>>>>>> equally incorrect. Browsers, including in particular sandboxes, routinely
>>>>>>> have vulnerabilities [2]. There is plenty of evidence that no sandbox is
>>>>>>> secure, including those put around CDMs. For an evidence, see the recent
>>>>>>> pwn2own results, and we should expect more hacks soon particularly on the
>>>>>>> kinds of DRM enabled by EME.
>>>>>>>
>>>>>>>      cheers,
>>>>>>>         harry
>>>>>>>
>>>>>>> [1] http://boingboing.net/2017/01/30/google-quietly-makes-option
>>>>>>> a.html
>>>>>>> [2] https://venturebeat.com/2016/03/18/pwn2own-2016-chrome-edge-
>>>>>>> and-safari-hacked-460k-awarded-in-total/
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>