EME: making a covenant into a exit condition

Prior to his decision to renew this group's charter, the director
considered three different possibilities for the disposition of this
group's work product in relationship to the various versions of the
nonaggression covenant that we've discussed:

1. Require members to sign on to a covenant (the EFF version, the Yandex
version, or some other version) as a condition of renewal of its charter

2. Make a covenant an exit condition of this group -- EME would not
become a W3C recommendation until the group agreed to some covenant

3. Allow the group to continue without a covenant

The director chose 3. I think this is because no consensus had emerged
on 1, and 2 had not yet been discussed among the WG's participants.

I'd like to propose 2, and have a discussion in this forum (and more
widely in the W3C) on what sort of covenant this group will adopt as an
exit condition. The group's charter will be up for renewal in September,
and this would be a good time to insert a covenant into our charter as
we proceed toward recommendation.

To continue where we left off, our discussion on the text of the
covenant was principally on the scope of the agreement. There seemed to
be an emerging consensus on the risk to security researchers. I don't
believe we had begun to discuss in detail our concerns regarding
interoperability.

The reason for including interop in the covenant is that, unlike other
W3C recommendations, EME will limit interop to browsers that have
explicit deals with publishers -- that is, the publishers will have to
bless an element of the user-agent (the CDM) for the user-agent to
render its content.

This is a new step for the W3C, and for the browser ecology. It's true
that the Web allows servers to distinguish among clients based on things
like auth tokens (my bank's web-server won't let your browser see my
account details), and of course browsers have always been able choose
not to implement the decoding or display of certain content. But this
creates a new situation where only certain implementations of otherwise
identical user-agents are acceptable; that choice is determined by
publishers and enforced by law. EME allows servers to pick and choose
among implementations.

There are profoundly anticompetitive implications for this. Thinking
back on the history of browsers, imagine if the Best Viewed With
Netscape... Best Viewed With IE... era had co-existed with a
technological and legal regime that allowed publishers to enforce those
preferences, by refusing to serve browsers unless they presented a
legally protected cryptographic element that established their bona fides.

More significantly, imagine the history of pop-up blockers if such a
regime had been in place: servers could have blocked any user-agent that
was (or could be) configured to reject pop-ups. Speaking as the owner of
a publisher that was under enormous pressure from advertisers to accept
pop-ups, I'm very glad that we could argue that user-agents were
increasingly configured to ignore pop-ups, as that argument carried the
day and largely ended pop-up advertising online.

The covenant leaves all causes of action apart from anti-circumvention
intact. A company that has adopted the covenant can still sue a
user-agent producer that allows people to bypass authentication
(accessing subscription services without a subscription), still sue
users who infringe, and still have a cause of action against companies
that facilitate infringement.

What the covenant allows is for creators of user-agents to produce and
distribute technology that allows users to do legal things, even when
rightsholders dislike them. In other words, it makes EME into a
technical standard for expressing preferences, not a means for turning
commercial preferences into legal obligations.

Our analysis of 46 major court decisions that involved a DMCA
anticircumvention claim showed that the covenant would not have
prevented a single one of them:

https://www.eff.org/document/list-1201-threats