Formal objection: new browsers and EME

[doctorow]

EFF has repeatedly raised the issue of new browsers and EME, on-list, in calls and during the earlier covenant process. We reiterate these concerns, first published here (https://www.eff.org/deeplinks/2016/03/interoperability-and-w3c-defending-future-present) as a formal objection:

The W3C has always stood for the ability of anyone to make a browser. By following the recommendations of the W3C, new companies and projects can make a browser that can view all the standards-compliant documents and files on the entire World Wide Web. While there are only a few major browsers in use today, they include several of relatively recent vintage, and are vastly outnumbered by all the browsers that have come and gone since the first days of the Web.

The Web's future depends on new browsers coming into existence to replace the ones that will inevitably fade away.

Any new browser coming on the scene after the standardization of EME will enter a fundamentally different world than all the ones that have come before: for that browser to receive and display content that is defined by the W3C, it will have to enter into a commercial partnership with one of a handful of companies that have been blessed as being entitled to produce a CDM.

A browser that can't strike such a partnership -- either because all possible partners are in exclusive relationships with existing browsers, or because it lacks the commercial or structural ability to enter into a commercial partnership (say, because it is a community-based free software project) will be frozen out of rendering part of the standards-defined Web.

It would be a return to the bad old days of websites that advised that they were "Best viewed with Netscape" or "Best viewed with Internet Explorer," because the new browsers would be locked out of some of their content.

However, if there is a covenant protecting interoperability, new browsers can bypass the refusal to deal from incumbent manufacturers and make their own EME-CDM combination that can play all the content that meets the W3C's standards.

[benbucksch]

As a former browser vendor, which was purely open-source, and a developer of browsers for other companies, I agree that EME will create a significant burden for new browser vendors. Because users expect - as a matter of course -, that things that work in older browsers also work in the new browser. If Netflix works in other big browsers, a new browser will be forced to support it as well. But as doctorow said, this is not easy to obtain, because of proprietary implementations and the required signature.

EME puts a small browser vendor, or one that insists on pure open source, into a very difficult position.

Due to the required signature, EME is inherently supporting an oligopoly of browsers, and inherently cannot be implemented by anybody. Thus, W3C should not give it the seal of a standard.

I formally object to EME.

[gvlx]

To further reinforce this objection, I recall a previous issue #305 "Formal objection to Encrypted Media Extensions advancing to Proposed Recommendation" by @rubenquidam and supported by @zakkai, @adrianzo, @haary, @sampablokuper, @zutje, @pikurasa, @marado and @emanuil-tolev, which should have been kept open.

Another related issue was @graviszro's #188 "the EME WG is ignoring "inconvenient" issues" which should have been a start of discussion of the many questions now addressed by several Formal Objections.

The ongoing discussion on this subject is creating a clear divide between "small browser vendor[s]" (as @benbucksch puts it) and large corporations.

Everyone has their own agenda, of course, but the decision process seems to be weighted only on the economic influence of the participants and the desire to formally establish a statement on the Web's body of standards without a more thoughtful regard of the end user's interests.

The end result is very likely to remove these smaller, bright, innovative and independent vendors away from the specification efforts and, hence, W3C, diminishing this organization's role as a consensus generator and central point of discussion of the future of the Web and the Internet.

There will be no winners.

[mwatson2]

@benbucksch wrote:

EME puts a small browser vendor, or one that insists on pure open source, into a very difficult position.

How would your position be improved if W3C did not publish the EME specification ?

@gvlx wrote of:

the desire to formally establish a statement on the Web's body of standards

To be clear, I don't believe anyone is asking W3C to recommend that people use or implement DRM or to make a pro-DRM statement on the many associated political issues. These are not in W3C's scope. The Proposed Recommendation describes a recommended common technical approach, should you choose to integrate DRM with a browser and it imposes valuable security and privacy protections within that approach.

[doctorow]

This is not a "political issue," it's an issue related to open standards. Standards are more open when fewer people can forbid someone from implementing them.

It was on this basis that the W3C undertook its patent policy: rather than taking a position on the fitness of patenting software, W3C took a position on the effect of patents on standards, and concluded that standards were more open when patent encumbrances were removed.

It is unequivocal -- obvious on its face -- that EME is more open if you don't face legal liability for implementing it in ways that violate no enumerated right of any copyright proprietor. The covenant seeks to to establish such a regime, to ensure that EME is not a sui generis exception to the entirety of the W3C's work product, subject to a layer of IP encumbrances that solely exist to prevent interoperability without permission.

Given that the covenant safeguards every enumerated right of members -- the right to prevent primary and secondary infringement, the right to prevent theft of trade secrets, the right to remedy against tortious interference with members' contracts -- the unwillingness of a few members to even discuss adopting it (let alone involve their companies' legal departments in such a discussion) suggests that some members are interested in EME not just for the technical sufficiency to their business needs, but because this also provides a vehicle for claiming new legal rights that no legislature has ever granted them.

This is an improper use of the standards-setting process. The possibility of a covenant turns the publication of EME into a plebiscite on using standards to create new legal rights for members of an SDO.

In that light, it's obvious what voting down EME gets members: an affirmation that if corporations want to secure new legal rights to prevent interoperation, they should seek those in the legislature, not in SDOs.

EME with a covenant is a purely technical matter. Remove the covenant and EME becomes, primarily, a means of creating private law.

Cory

On 04/12/2017 04:37 PM, mwatson2 wrote:

@benbucksch https://github.com/benbucksch wrote:

EME puts a small browser vendor, or one that insists on pure open
source, into a very difficult position.

How would your position be improved if W3C did not publish the EME specification ?

@gvlx https://github.com/gvlx wrote of:

the desire to formally establish a statement on the Web's body of
standards

To be clear, I don't believe anyone is asking W3C to recommend that people use or implement DRM or to make a pro-DRM statement on the many associated political issues. These are not in W3C's scope. The Proposed Recommendation describes a recommended common technical approach, /should you choose to integrate DRM with a browser/ and it imposes valuable security and privacy protections within that approach.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/encrypted-media/issues/379#issuecomment-293736726, or mute the thread https://github.com/notifications/unsubscribe-auth/ASadlgNBdNu6-LoZLBtJDdE2kM-SfbS1ks5rvWBRgaJpZM4MnXhZ.

[benbucksch]

How would your position be improved if W3C did not publish the EME specification ?

Without EME, we're back to a level playing field where I can do the same that the big browsers do. Content providers would be left with only choices that open-source can also support.

Right now, YouTube and NYTimes use plain HTML5

If bad guys try to shoot the new settler, we should at least try to stop them. And we surely shouldn't be approving them. Or even making them sheriff.

[zutje]

There is a (big) problem in this reasoning here:

On 04/13/2017 01:37 AM, mwatson2 wrote:

To be clear, I don't believe anyone is asking W3C to recommend that people use or implement DRM or to make a pro-DRM statement on the many associated political issues. These are not in W3C's scope. The Proposed Recommendation describes a recommended common technical approach, /should you choose to integrate DRM with a browser/ and it imposes valuable security and privacy protections within that approach.

once it is a standard, it will be used, and there is no real choise left but to implement. Especially since the large content providers /will/ use the DRM opportunity and cater many web users. Smaller browser providers will have essentially no choise but to implement, or diminish even more.

Next to that, as far as I understood it, DRM plugins are allowed to be written in the language and for the operating system of choise of the provider of the DRM plugin. This may mean that users of minority operating systems, like the GNU/Linux or others, are shut out of contents available on the web in formats "conforming" to W3C standards, well, standards on how DRM plugins can communicate to browsers... But only if the DRM plugin vendor wants it's plugin to.

And there lies exactly the problem of this proposed W3C "standard". It is intentionally /not/ for all! While W3C should only standardise what /is/ for all.

Best regards,

Tjeerd Pinkert

[marado]

Hi,

Smaller browser providers will have essentially no choise but to implement, or diminish even more.

In this regard, I'd like to highlight that small browser providers aren't even warranted to be able to choose implementing/supporting a specific CDM, as there is no provision mandating that CDM providers must provide it. Thus, the probable outcome would really be a diminishing market share for currently considered "alternative browsers", or the appearance of new browsers.

On Apr 15, 2017 21:44, "zutje" notifications@github.com wrote:

There is a (big) problem in this reasoning here:

On 04/13/2017 01:37 AM, mwatson2 wrote:

To be clear, I don't believe anyone is asking W3C to recommend that people use or implement DRM or to make a pro-DRM statement on the many associated political issues. These are not in W3C's scope. The Proposed Recommendation describes a recommended common technical approach, /should you choose to integrate DRM with a browser/ and it imposes valuable security and privacy protections within that approach.

once it is a standard, it will be used, and there is no real choise left but to implement. Especially since the large content providers /will/ use the DRM opportunity and cater many web users. Smaller browser providers will have essentially no choise but to implement, or diminish even more.

Next to that, as far as I understood it, DRM plugins are allowed to be written in the language and for the operating system of choise of the provider of the DRM plugin. This may mean that users of minority operating systems, like the GNU/Linux or others, are shut out of contents available on the web in formats "conforming" to W3C standards, well, standards on how DRM plugins can communicate to browsers... But only if the DRM plugin vendor wants it's plugin to.

And there lies exactly the problem of this proposed W3C "standard". It is intentionally /not/ for all! While W3C should only standardise what /is/ for all.

Best regards,

Tjeerd Pinkert

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/encrypted-media/issues/379#issuecomment-294316826, or mute the thread https://github.com/notifications/unsubscribe-auth/AACBi33gqgr_4nxNC7eoU8TxR2uPale2ks5rwSwRgaJpZM4MnXhZ .

[mwatson2]

@benbucksch

Without EME, we're back to a level playing field where I can do the same that the big browsers do. Content providers would be left with only choices that open-source can also support.

I asked how W3C publishing EME or not would make a difference, but your answer is about how big browsers supporting EME or not will make a difference. The four major browsers already support EME - in one form or another - and I expect will continue to do so as long as their users value access to the sites that are based on it. It is market forces, not W3C, that has caused this. So, again, what difference does W3C publication make to you ?

@doctorow Unequivocally, the W3C is not a legislative body, it has no legal power. Could you explain how it could ever create "new legal rights" - I honest don't understand this point.

[GravisZro]

@mwatson2

It doesn't matter what browser XYZ supports if it's not a standard. You could have the most revolutionary concept for how page layout could work but it doesn't matter if it never becomes a standard because it too will be washed away with the sands of time never to be reimplemented again.

[mwatson2]

@graviszro Seems unlikely in this case. Do you expect browsers to re-introduce plugins when they drop support for EME ? Or drop support for the rather popular sites using EME ? Which browser do you think will go first ?

[GravisZro]

You speak as if today's browsers will be around forever. You clearly have no perspective of the bigger picture. Honestly, you have no business being involved in making any standard if you are really this myopic.

[mwatson2]

I'll take the resort to ad hominem as the end of the discussion then.

[GravisZro]

Hardly.

Seems unlikely in this case. Do you expect browsers to re-introduce plugins when they drop support for EME ? Or drop support for the rather popular sites using EME ?

My reply of "You speak as if today's browsers will be around forever." makes it clear that what is going to happen is that the browsers that support the EME (and probably the sites dependent on it) will not stand the test of time if the EME is not standardize.

This is why it matters if it's a standard or not.

I'll take the resort to ad hominem

I find it difficult to make a fish understand what life is outside of water, especially when it doesn't want to know. You do not want to understand my side of the argument because your salary depends on you not understanding it which is an obvious conflict of interest.

[mwatson2]

The problem is that you have not presented any actual arguments. Your first statement above is simply an assertion, with no argumentation or evidence, and then you return to personal attacks.

[benbucksch]

So, again, what difference does W3C publication make to you ?

I answered that at the end of in my last comment above. Whether it's just something that the big bullies do, or it's officially sanctioned and an official Internet standard, makes a difference.

The problem is, stated in a very simple way: It's a proposed Internet standard that I cannot actually implement myself to a point that actually works in practice. I can implement EME, but not the plugins (CDMs for DRM) necessary to actually decode the real-world content.

In other words, this proposed "standard" does not actually ensure interoperability between websites and browsers, and multiple equally functional implementations. Which is the whole purpose of having a standard in the first place. As such, it fails the basic bar of a standard.

The problem is that you have not presented any actual arguments

I have done so. Here, and in #378, and in other tickets. I'm speaking as open-source browser vendor, about the problems this creates from that perspective. The EFF (@doctorow) is speaking out for privacy, security and end users.

[GravisZro]

@mwatson2

The four major browsers already support EME - in one form or another - and I expect will continue to do so as long as their users value access to the sites that are based on it. It is market forces, not W3C, that has caused this.

This argument is outside the scope of a technical specification. It is irrelevant what browser XYZ or site ZYX does if it is not standards complaint.

[doctorow]

I confess to being mystified by the argument -- promulgated by DRM advocates -- that standardization at W3C doesn't matter to the viability of DRM on the web.

On the one hand, we have lots of urgent talk about the user harms arising from the difficulty of implementing DRM in the HTML5 world where NDAPI and its like have been abolished, leaving browser vendors and publishers to strike expensive, difficult-to-sustain deals as a series of one-offs to synchronize proprietary components at both ends that would create technical problems for users that cause them to reject the publishers' products.

On the other hand, we have the argument that DRM on the web is inevitable and actually a fait accompli, entirely separate from the outcome of the W3C process, such that the decision not to publish EME as a W3C standard would make no "difference" ("difference" being the thing that we must seemingly enumerate in order to advance this debate).

But if DRM will happen regardless of W3C standardization, with no "difference," then there will be no "difference" if the W3C doesn't publish it, or requires members to agree to a nonaggression covenant as a condition of doing so.

DRM's "difference" and inevitability is thus posed as simultaneously maximum and minimum, totally irrelevant and utterly salient. I believe the technical term for this in SDOs is "having one's cake and eating it too."

Thrown into this mix is the asserted inevitability of the web itself being sidelined in favor of apps and walled gardens if DRM doesn't become part of HTML5, but this is usually uttered in the same breath as a blank assertion that DRM is coming to HTML5 no matter what the W3C does. Only one of these things can be true.

A note on accessibility: DRM laws make any accessibility features built into the spec the ceiling, not the floor, on accessibility. Notably, the current spec excludes any kind of third-party automated bulk or realtime processing, such as feeding cleartexts into a machine-learning system to spot and interdict seizure-causing strobes; to shift color-gamuts for color-blind people, or to add subtitles/descriptive tracks.

The oft-repeated assertion that humans could manually add these features to EME-locked videos is obviously deficient. UC Berkeley just killed 20,000 hours of instructional videos because they couldn't adequately subtitle them -- the fact that an army of humans who produced a set of subtitles could then add them to the video is nice, but in the absence of such an army, and in the presence of ever-better machine subtitling tools, it's utterly, blatantly obvious that EME will stand in the way of the future of legitimate, powerful accessibility adaptation.

Is there anyone who believes that in the future the majority of accessibility adaptation for any media will be done by humans, working by hand?

Here's what I think:

• DRM-protecting laws mean that making DRM easier to implement on the web makes the web intrinsically less open, less safe, and less accessible

• Standardization matters and makes technology more viable

• EME is unfinished and will require future versions (this was the argument for pursuing a W3C policy interest group that couldn't affect EME -- it would affect the inevitable future versions), so the W3C walking away from EME would have material effect on its viability

• This means that DRM standardization advocates need the W3C process to continue, and must work with people who want to safeguard open web equities in the Consortium if they are to make progress

• The EME process -- and the W3C's credibility -- are now at a crossroads because DRM advocates literally refused any further discussion of this, 13 months ago, at an AC meeting in Cambridge

• As a result, we are now in a situation where a large plurality of W3C members do not want to see EME published until a covenant is arrived at, but having done nothing on that front for more than a year, we have a lopsided world where the technology is asserted to be ready for launch and the policy component is still on the drawing board

Whether a refusal to discuss this issue was a deliberate calculation or a tragic misjudgment, it was a terrible mistake. Because of a leadership decision to steamroller the opposition rather than compromise with it (or even continue talks with it), the W3C has, for the very first time in its history, arrived at the moment of publication with no consensus in sight, and no path to consensus in sight either.

Publication at this point would mark not one, but THREE sea-changes in the W3C's nature:

1. The W3C is now the kind of body that makes standards to allow browser vendors to restrict how users can use the data they receive

2. The W3C is now the kind of body that allows members' IPRs to control who may interoperate with its standards

3. The W3C is now the kind of body where deeply divisive issues are settled by allowing one group to simply declare the other group to be out-of-bounds, out-of-touch, out-of-scope or out-of-order and to thus publish things that large numbers of its members have deep moral, technical and legal objections to, rather than deliberating and compromising to resolve these divisions

DRM opponents at the W3C extended a significant compromise to DRM advocates: a covenant that would allow DRM users to enforce copyright, torts and trade secrecy (and every other right they have in law), while making DRM. The members who want DRM insisted they would only proceed if DRM could also be a tool for asserting rights that no legislature ever granted them.

That is what brought us to this juncture: an unwillingness on one side to make any compromise whatsoever. That is not in the spirit of multistakeholder processes or the history of the W3C. Any future progress on EME at the W3C will require compromise on both sides, not blithe assertions that no "difference" is to be found in going down one path or the other.

Cory

On 04/16/2017 06:59 AM, Ben Bucksch wrote:

So, again, what difference does W3C publication make to you ?

I answered that at the end of in my last comment above. Whether something is officially sanctioned and an official Internet standard, or it's just something that the big bullies do, makes a difference.

The problem is, stated in a very over-simplified way: It's an Internet standard that I cannot actually implement myself to a point that actually works in practice. I can implement EME, but not the plugins necessary to actually decode the content. I am forced to use the implementation of Google and Adobe.

In other words, this "standard" does not actually ensure interoperability between websites and browsers, and multiple equally functional implementations. Which is the whole purpose of having a standard in the first place. As such, it fails the basic bar of a standard.

The problem is that you have not presented any actual arguments

I have, thank you very much. Here, and in #378 https://github.com/w3c/encrypted-media/issues/378, and in other tickets. I'm speaking as open-source browser vendor, about the problems this creates from that perspective. The EFF (@doctorow https://github.com/doctorow) is speaking out for privacy, security and end users. Whereas are you are working for Netflix and flood the objections with your comments.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/encrypted-media/issues/379#issuecomment-294353237, or mute the thread https://github.com/notifications/unsubscribe-auth/ASadlrNCyNfSnhfwpCdS3R5weIBJrNQFks5rwh7egaJpZM4MnXhZ.

--

[GravisZro]

Seems unlikely in this case. Do you expect browsers to re-introduce plugins when they drop support for EME ? Or drop support for the rather popular sites using EME ? Which browser do you think will go first ?

If that's the case and it really doesn't matter, then there is no need for the EME to be standardized at all. So why do you want to make it a standard if it doesn't matter?

[ghost]

and which browsers should we use for avoiding drm? are Iceweasel and Chromium enough?

[mwatson2]

I argued that standardization of EME at W3C made no difference for this issue (new browsers). Obviously, it would be inconsistent or argue that it made no difference at all and simultaneously hold a position on whether it should happen or not.

EME itself (the technology, rather than the standard) indeed has pros and cons for new browsers, compared to NPAPI. On the one hand there is as yet no de facto or otherwise standard API for the proprietary component, although people could copy what Mozilla has done (which is how NPAPI got started). On the other hand, the functionality which must be exposed to the proprietary component is much more constrained and rather than supporting arbitrary unknown plugins chosen by sites, browsers need only support the one of their choice, which should be very much a known thing to them.

It's true that integrating with a software component may require a business relationship with the provider of that component, but there is no evidence that this is especially difficult and if it were that would be an opportunity for a new entrant.

@nitrofurano I believe that at least Chrome and Firefox let you disable the DRM. Perhaps the others major browsers do too, I am not sure.

[doctorow]

Chrome no longer allows one to disable DRM; I believe you can do this with Chromium if you build from source.

[taravancil]

@nitrofurano Brave requires users enable DRM manually, and Beaker doesn't implement it at all

[mwatson2]

Chrome no longer allows one to disable DRM;

I don't believe this is true. Chrome 57 contains a "Allow protected content" option in Content Settings and it is still present in Chrome Canary (Chrome 60).

IIUC, the previous option to disable plugins disappeared and has been replaced with this new option specific to CDMs. [To be clear, I don't claim to know exactly what the new option does, but presume that it does just what it says.]

[mwatson2]

@benbucksch Regarding my comment about not presenting actual arguments. This was directed at @GravisZro and not at you. I apologize for any confusion. Thank you for editing your comment.

[GravisZro]

I argued that standardization of EME at W3C made no difference for this issue (new browsers). It's true that integrating with a software component may require a business relationship with the provider of that component,

1. Why should a "business relationship" be needed to implement a standards complaint browser? It's never been a requirement before, what make the EME so important that such a requirement should be added?
2. There are several browsers that bill themselves as being 100% open source. This makes their browsers fundamentally incompatible with CDMs.

there is no evidence that this is especially difficult and if it were that would be an opportunity for a new entrant.

Will Netflix create a "business relationship" that will allow an open source CDM to access their content? If not, there is your evidence.

EME itself (the technology, rather than the standard) indeed has pros and cons for new browsers, compared to NPAPI.

What are the "pros" for browsers that are made by people rather than corporations?

On the one hand there is as yet no de facto or otherwise standard API for the proprietary component,

This is by design. Proprietary components directly conflict with the mission of the W3C.

"One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability."

[mwatson2]

@graviszro DRM cannot be implemented in Free Software. This is true by definition. We all know this and have known it all along through this process. There's nothing right or wrong about that, it's just a fact arising from the definitions of the two things.

What this Objection, and the other on FLOSS, are asking is that the W3C restrict itself to that part of the web that does not use DRM. That the millions of users who use DRM on the web every day be denied the benefits that arise from developing technology in the W3C. The primary goal you quote can also be interpreted in this light.

[benbucksch]

DRM cannot be implemented in Free Software.

Right. Add the fact that the Internet wouldn't exist without Free Software, you are starting to see the dimensions of the problem.

Last time I checked, Netflix wouldn't exist without Internet and uses lots and lots of Free Software.

[GravisZro]

DRM cannot be implemented in Free Software.

Seems like reason enough to keep it from becoming standardized, don't you think?

What this Objection, and the other on FLOSS, are asking is that the W3C restrict itself to that part of the web that does not use DRM.

Did you forget this part so soon? It's part of the mission to be inclusive, not exclusive.

"One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability."

That the millions of users who use DRM on the web every day be denied the benefits that arise from developing technology in the W3C.

Nobody is looking to deny them the use of DRM. However, it just shouldn't be part of the standard because it goes against one of the primary goals of the W3C. DRM is an exclusive technology that will deny you access to content.

The primary goal you quote can also be interpreted in this light.

It wouldn't be the first time someone has used the words of good men to justify their evil deeds.

[plehegar]

I'd like to remind everyone of our Code of Ethics and Professional Conduct, which are to be followed even when commenting our GitHub repositories: https://www.w3.org/Consortium/cepc/ This includes treating each other with respect, professionalism, fairness, and sensitivity to our many differences and strengths, including in situations of high pressure and urgency.

[GravisZro]

@plehegar Your social justice imperative has been noted. It should also be noted by all people that the purpose of the W3C's standards are supposed to make the internet more accessible to people instead of less accessible. The EME does nothing to further the accessibility of content but does plenty to standardize restricting content.

[pikurasa]

@mwatson2 says < It's true that integrating with a software component may require a business relationship with the provider of that component, but there is no evidence that this is especially difficult and if it were that would be an opportunity for a new entrant.

The assumption here is that everyone developing a browser is doing so for business reasons. Computers--and computing in general--is just a great way to learn more about the world. Many people enjoy developing software tools, such as browsers, because they learn more about the world by doing so.

I disagree with the principle that people must ask others for permission in order to enter development of a particular type of software tool. If someone were developing a new browser and asked me for advice, I would advise them to leave Digital Restrictions Management (DRM) out of it--both for their own freedom and the freedom of anyone using their browser.

Personally, I use IceCat (https://directory.fsf.org/wiki/IceCat) on GNU/Linux because it takes an active role to protect its user's privacy and freedom. Perhaps browsers could go a step further to add verbiage that informs users about the issues surrounding DRM as it blocks the code from being run (similar to how LibreJS blocks non-free java script and informs its users as well).

[benbucksch]

I disagree with the principle that people must ask others for permission in order to enter development of a particular type of software tool.

+1 This in fact is the underpinning of open standards.

[dannyob]

I think it's worth emphasizing a couple of points that @mwatson2 has made in this issue and in #166, and the problems for new browsers regarding EME. Firstly, Mark notes, clearly: "DRM cannot be implemented in Free Software. This is true by definition. We all know this and have known it all along through this process." I appreciate Mark making this distinction, as I've definitely heard others express the hope that a open source CDM might be possible.

In this comment, Mark makes a separate but connected point, that the enforcement mechanism for ensuring that DRMs comply with the desires of content providers involve tying them to contractual IPR agreements (I hope I've expressed the thought correctly here, though readers may want to check Mark's actual language).

Without getting distracted with the discussion as to whether the contours of a CDM are in-scope -- when I was last part of this conversation, 13 months ago, we had reached a compromise position that while EME did not define CDM, it was clear that the hole left in the spec really only fitted a DRM module, and had no other function but to do so -- this means that not only would a fully W3C-compliant browser in the future have to be proprietary, but its creators would also have to come to contractual agreements with content providers in order to depict some URIs.

This is actually worse than the position that the patent covenant sought to avoid. At least patents expire eventually (I notice the last MP3 patent expired this week). Content mediated by the EME spec will always require a permanent, external contractual IPR agreement with a DRM vendor, or be unviewable. So we limit future fully W3C-compliant browsers to part-proprietary hybrids created by an institution legally able, financially rich enough, and with the explicit legal approval of a narrow set of vendors.

[mwatson2]

@dannyob wrote:

I think it's worth emphasizing a couple of points that @mwatson2 has made in this issue and in #166, and the problems for new browsers regarding EME. Firstly, Mark notes, clearly: "DRM cannot be implemented in Free Software. This is true by definition. We all know this and have known it all along through this process." I appreciate Mark making this distinction, as I've definitely heard others express the hope that a open source CDM might be possible.

I think you're referencing to the distinction between Free Software and open source. An open source CDM is certainly possible.

In this comment, Mark makes a separate but connected point, that the enforcement mechanism for ensuring that DRMs comply with the desires of content providers involve tying them to contractual IPR agreements (I hope I've expressed the thought correctly here, though readers may want to check Mark's actual language).

I'm not sure if "them" refers to DRMs or content providers ? Anyway, a content provider wants to verify that they can trust that the DRM client component they are sending content to is compliant to robustness rules and will enforce output protection etc. To do this they need to license the server-side counterpart of that DRM client component. It's not only a patent license although patents are endemic in this space.

not only would a fully W3C-compliant browser in the future have to be proprietary

EME is proposed to be optional, so you could certainly build a fully W3C compliant browser without it, just as you could build a fully W3C compliant browser without NPAPI.

but [the browser's] creators would also have to come to contractual agreements with content providers in order to depict some URIs.

I believe you are referring to agreements browser creators would need in order to include a DRM client component in their product. It's important that these agreements are not with content providers but with the DRM vendors. The agreements are necessary since otherwise a browser could include a modified DRM client component which claimed to respect robustness rules but in fact did not. It probably is, ultimately, intellectual property rights (of various kinds) that would prevent someone from doing that.

we limit future fully W3C-compliant browsers to part-proprietary hybrids created by an institution legally able, financially rich enough, and with the explicit legal approval of a narrow set of vendors.

Again, you could be fully compliant without supporting DRM.

The intent of EME is to move responsibility for DRM to browsers, making it more distant from the content providers that require it. Content providers are expected to support the DRMs that browsers support. This is a real change in responsibility and imposes costs on content providers in return for which they are getting better integration with the web and improved user experience.

But, yes, as a browser creator, it's true that you can no longer just implement NPAPI and punt support for those sites to arbitrary proprietary components over which you have no oversight. But that solution had other problems, as we know. I do think it is a viable and attractive business model for DRM providers to give the client component away for free and make their money on the content provider side. If that is not already the model of an existing DRM provider, I think we could expect a new one to emerge (but I do not have a crystal ball). It's possible for a browser to switch, as Mozilla have demonstrated.

[benbucksch]

An open source CDM is certainly possible.

But my build won't play actual web content, right? Because the secret keys are missing.

I may have lots of cars on the street in front of my door, but I don't have the keys. Not very useful.

you could build a fully W3C compliant browser without NPAPI.

NPAPI, to my knowledge, never was a W3C standard. Neither should EME be.

The intent of EME is to move responsibility for DRM to browsers

Then it fails at that, because as an open-source browser vendor, I don't see myself in a position to offer any CDM that will play any actual real-world EME-protected content.

I don't actually have a choice in what I want to support. I need to support whatever the content providers use. Which is whatever the big browser use. I am forced to make a contract with these companies.

Which means that entire spec is prejudiced towards large browsers and hinders new vendors on the market, and a whole class of vendors, i.e. essentially anti-competitive.

[benbucksch]

Actually, worse yet, if Netflix or YouTube were to use a new DRM, then there just needs to be one browser that supports that DRM, and likely all other browsers would be forced to support that as well, to remain competitive. Based on what you said, they would all need to enter contractual agreements with whatever company offers that DRM, which might theoretically be Netflix itself. Thus, suddenly a website can impose contracts on browser vendors. Wow, that's definitely new.

[GravisZro]

they would all need to enter contractual agreements with whatever company offers that DRM, which might theoretically be Netflix itself.

and @mwatson2 works for Netflix. Seems like a conflict of interest to me!

[mwatson2]

I don't expect content providers to be able to impose a particular DRM on browsers. It's working the other way around at present and that was the intention.

Regarding an open source CDM, this is a sidetrack, but @dannyob noted the distinction between open source and Free Software. I meant that there could be a DRM whose source code is published under some open source license. There would still need to some business structure to ensure robustness and deal with the inevitable patents, but it is possible, although I don't know of any work in that direction.

Regarding contractual arrangements with Netflix. Typically if you want to make/sell a product that supports our service then you do need a contract with us. Browsers are the exception, where instead you need one of the several DRMs we support.

I don't think it is all that difficult to do the same thing that Mozilla have done.

[joeyparrish]

The reality today is as @mwatson2 said: a streaming service choosing to encrypt content must ultimately support the DRM systems of all browsers. Otherwise, they can't reach their full potential audience on the web.

So there are clear market incentives for service providers to ship multi-DRM content, if they use DRM at all. If your browser has users, you, the browser vendor, have a fair amount of influence over the service provider who wants to reach your users.

The same is true in terms of codecs. If a service provider wants to reach an audience whose browser only supports codecs X and Y, they will have to create content with those codecs. YouTube, for example, has historically transcoded into many different formats and codecs to reach the widest possible audience.

[ghost]

@mwatson2 wrote:

@benbucksch wrote:

EME puts a small browser vendor, or one that insists on pure open source, into a very difficult position.

How would your position be improved if W3C did not publish the EME specification ?

Surely in at least the following ways:

• People would be able to create and ship browsers that are entirely free software and that meaningfully implement the entirety of W3C standards, without exposing themselves to new and very serious litigation risks.

• DRM would remain where restrictive (as opposed to inclusive) technologies should remain: beyond the pale (of W3C standards).

[diracdeltas]

@benbucksch wrote:

As a former browser vendor, which was purely open-source, and a developer of browsers for other companies, I agree that EME will create a significant burden for new browser vendors. Because users expect - as a matter of course -, that things that work in older browsers also work in the new browser. If Netflix works in other big browsers, a new browser will be forced to support it as well. But as doctorow said, this is not easy to obtain, because of proprietary implementations and the required signature.

As a current browser vendor (Brave), we agree with this. Brave is free software and cannot ship with DRM plugins like Google Widevine, nor do we want to force our users to agree to Google's terms of use. However, after a lot of users asked why Netflix did not work in Brave, we had to add an option to enable DRM (off by default), which would then download the Widevine binary when switched to on. The process was somewhat lengthy; it required getting permission from Google and then adding a disclaimer so that we did not have to change Brave's own terms-of-use.

Based on my experience with Brave, I strongly believe that EME will make feature parity more difficult for new browser vendors, not less, unless there is a covenant like @doctorow proposes.

[mwatson2]

@diracdeltas

Based on my experience with Brave, I strongly believe that EME will make feature parity more difficult for new browser vendors, not less, unless there is a covenant like @doctorow proposes.

How would it be easier to achieve feature parity if EME were not published ? Wouldn't other browsers would still support Netflix and your users still ask for it ?

[zutje]

On 04/19/2017 04:49 AM, Ben Bucksch wrote:

I disagree with the principle that people must ask others for
permission in order to enter development of a particular type of
software tool.

+1 This in fact is the underpinning of open standards.

ack

[GravisZro]

@mwatson2

I don't expect content providers to be able to impose a particular DRM on browsers.

Except streaming media sites (including Netflix) have already has done this exact thing. 4K content is not accessible through just any DRM scheme, it must be Microsoft's PlayReady 3.0. This is why even if you having a 4K smartTV is no guarantee that it will be able to steam 4K content. Of course, you already know all this.

[zutje]

On 04/17/2017 08:36 PM, mwatson2 wrote:

@graviszro https://github.com/graviszro DRM cannot be implemented in Free Software. This is true /by definition/.

If that is the case, why would anyone want a standard for it? And then certainly W3C should not make a never to be fully standard standard (but wasn't that the argument against EME, I think it was).

What I would then propose is that the pro-DRM people come up with a completely open standard for their use, otherwise W3C should refuse to standardize. If the DRM camp can't, that's their problem, and they should deal with that problem on their own then and not bother W3C with it.

[ghost]

On Apr 20, 2017, @zutje wrote:

On 04/17/2017 08:36 PM, mwatson2 wrote: @graviszro DRM cannot be implemented in Free Software. This is true by definition.

If that is the case, why would anyone want a standard for it?

It is understandable that proprietary technologists would want a standard for some part of their proprietary technologies, e.g. to make them interoperable with each other and reduce costs, or to prevent monopolies. Numerous standards bodies exist for proprietary standards in various fields of human endeavour.

But:

• there should be no pretence that such a standard is an open standard; and
• the W3C should not develop or publish such a standard.

[zutje]

It's possible for a browser to switch, as Mozilla have demonstrated.

Indeed, if a browser has a rather large market share, DRM module providers are sort of likely to work with them, otherwise their customers might miss income. If the developers of sayd browsers have properly done their legal homework they might even want to run the risk of signing an NDA.

I can tell that as a private person, signing NDA's or other contracts with companies (even small money small legal staff ones) is usually out of the average persons financial risk scope.

This means it would not be viable for private developers to include a usefull DRM module when signing things with companies would be required.

[plehegar]

See https://lists.w3.org/Archives/Public/public-html-media/2017Jul/0000.html