Re: Formal objections to Encrypted Media Extensions

Harry, all,

Regarding Harry's objection, I do agree with Harry that it is in scope of
the group and he has made a concrete proposal. IIUC, the "user harm" Harry
is referring to is the increased security and privacy risk that he believes
users are *necessarily* subjected to through the unprompted use of EME. He
argues that users are *necessarily* subjected to this risk with EME because
of the effect of the DMCA on security research (Harry, correct me if I am
paraphrasing incorrectly).

It's true that we have not had extensive discussion on this, but several
people have posted the reasons why they disagree. And I have not seen a lot
of support.

Whilst it is obvious that users are necessarily subjected to privacy risks
by unprompted disclosure of goe-location, it is not obvious that
significantly increased security and privacy risks *necessarily* follow
from the use of EME: Indeed, we have made substantial efforts to avoid this
and it is one of the key advantages of EME over plugins. There are
certainly cases where there are privacy concerns - in particular when
distinctive identifiers are used - and we do require prompts in those
cases. However, the overall risk depends very much on the User Agent
implementation and the steps the User Agent implementor has taken to
mitigate those risks. I would like to incentivize  user agent implementors
to take such steps as are necessary to bring their implementation to a risk
level where prompts are not necessary. I would also like to give sites an
incentive to move from plugins to EME. Mandating a prompt removes one such
incentive.

A further point was that user attention to security prompts is a scarce
resource. Decisions on it's use - where there is doubt - should be take at
a User Agent level, not at the level of individual features.

...Mark



On Tue, Sep 6, 2016 at 11:16 PM, David Singer <singer@apple.com> wrote:

>
> > On Sep 7, 2016, at 0:37 , Harry Halpin <hhalpin@w3.org> wrote:
> >
> > Paul,
> >
> > My change requested is a "substantive change", as it would effect
> conformance. The change is within charter, but adds more user protection
> given the controversy. However, has the EME Working Group officially
> considered this as a possibility?
> >
> > I did not see much official discussion on either github, the mailing
> list, or the telecon.
> > I do not think that it is unreasonable and would allay (I hope) the
> large number of concerns that this can be met via this simple technical
> change that involves *no legal or policy questions be resolved*. I believe
> this earlier problem was the main reason the EFF covenant and Wendy's
> objection were overriden.
> >
> > Mark Watson did not seem to think the proposal was unreasonable, but
> that it was a in principle difference over whether the UA or a user should
> be able to judge the security of a controversial feature. Given that users
> have this choice with regards Geolocation and other powerful features and
> given some of the UAs also have a business model in getting as many people
> to adopt DRM as possible (thus their work on EME at W3C), I think giving
> users the choice of opting-in to EME and DRM is common sense. I do strongly
> believe the web should take the interest of rights of users first. See the
> Priority of Constituencies document: https://www.w3.org/TR/html-
> design-principles/#priority-of-constituencies.  It is possible some users
> won't turn it on, in order to respects their rights we MUST allow them that
> choice given the level of legal uncertainty and security issues that EME
> raises.
> >
> > David Singer thought there was not clear evidence that DRM and EME could
> cause 'user harm’.
>
> No, I repeatedly asked you to substantiate your claim that it would or
> might. You have so far failed.
>
> > First, it does not appear the Working Group has thought through the
> possibility that clearKey, despite being ineffective, may be covered by the
> DMCA (I do not see an open github issue on this rather important matter).
>
> And where is the possibility of user harm in this?
>
> > Second, the security research community believes this feature in
> browsers can cause 'user harm': https://www.eff.org/deeplinks/
> 2016/06/call-security-community-w3cs-drm-must-be-investigated.
>
> Have you linked the wrong article?  This is Cory’s argument that there is
> risk to security researchers.  ‘User harm’ does not appear in the article,
> indeed ‘harm’ does not, and ‘user’ only to refer to billions of them.
>
> > While I respect David's desire to know more about the details of user
> harm,
>
> Evidence, or a reasonable argument. Not more, which implies you have
> documented some; any evidence of a possibility of ‘user harm’.
>
> You’re asking the specs to insist something is done in order to mitigate
> user harm, but have yet to show what harm you’re trying to mitigate, so we
> have no idea whether the cure matches the problem (if there is a problem).
>
> > the many signatories of this web-page have produced ample work in this
> regard (as referenced from Wikipedia) and I'm sure some would be happy to
> discuss in more detail. It does set a precedent that in terms of user
> security and privacy that this Working Group is overriding the concerns not
> just of W3C's legal counsel, Wendy Seltzer, but also notable security
> researchers such as Bruce Schneier and Ron Rivest.
>
> Now you’re mixing things up again. Please.
>
> >
> > Thus, I would like the Working Group and the Chair to reconsider closing
> this issue. I'm happy to come to the next telecon to discuss if I am given
> a spot on the agenda. If not, I hope the Director takes this objection,
> which does require any legal discussions unlike Wendy or the EFF proposals,
> but is *purely technical*, into account and rules in its favour.
> >
> >   cheers,
> >      harry
> >
> >
> >
> >
> > On 09/06/2016 08:26 PM, Paul Cotton wrote:
> >> The HME WG has recently received several Formal Objections to EME
> progressing to Proposed Recommendation.
> >>
> >> These recent formal objections are listed below:
> >>
> >> a) ISSUE-288: "EME is not intended to be an interface to technical
> protection measures"
> >> https://github.com/w3c/encrypted-media/issues/288
> >> Author: Wendy Seltzer
> >>
> >> b) ISSUE-304: Turn off EME by default and activate only with express
> permission from user
> >> https://github.com/w3c/encrypted-media/issues/304
> >> Author: Harry Halpin
> >>
> >> c) ISSUE-305: Formal objection to Encrypted Media Extensions advancing
> to Proposed Recommendation
> >> https://github.com/w3c/encrypted-media/issues/305
> >> Author:  Ruben Rodriguez
> >>
> >> Since these formal objections:
> >> a)      cannot be satisfied without making “substantive changes” [1] to
> the EME specification or halting work on the specification entirely, and/or
> >> b)     are identical to previous formal objections that the Director
> has chosen not to sustain, and/or
> >> c)      there is no consensus within the HME WG for the required
> changes especially this late in the EME specification development,
> >> in my role as HME WG Chair I am ruling that these issues should be
> closed with no action for EME V1.
> >>
> >> Each of these Formal Objections will be added to the summary page of
> formal objections [1] and will be presented to the Director when he reviews
> a request to progress EME to Proposed Recommendation status.
> >>
> >> FTR I responded with background earlier on the topic of EME formal
> objections in:
> >> https://lists.w3.org/Archives/Public/public-html-media/
> 2016Aug/0081.html
> >> https://lists.w3.org/Archives/Public/public-html-media/
> 2016Aug/0078.html
> >>
> >> /paulc
> >> HME WG Chair
> >>
> >> [1] http://www.w3.org/2015/Process-20150901/#substantive-change
> >> [2] https://dev.w3.org/html5/status/formal-objection-status.html
> >>
> >> Paul Cotton, Microsoft Canada
> >> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> >> Tel: (425) 705-9596 Fax: (425) 936-7329
> >>
> >
> >
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>
>