New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formal objection: new browsers and EME #379

Closed
doctorow opened this Issue Mar 23, 2017 · 48 comments

Comments

Projects
None yet
@doctorow

doctorow commented Mar 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 8, 2017

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.

benbucksch commented Apr 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gvlx

gvlx Apr 12, 2017

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.

gvlx commented Apr 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 12, 2017

Contributor

@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.

Contributor

mwatson2 commented Apr 12, 2017

@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 comment has been minimized.

Show comment
Hide comment
@doctorow

doctorow Apr 12, 2017

doctorow commented Apr 12, 2017

@benbucksch

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 12, 2017

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 , and I can watch it fine on an open-source system. I want to keep it that way. With EME, they can lock me out, and it would be W3C standards approved and completely legit.

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.

benbucksch commented Apr 12, 2017

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 , and I can watch it fine on an open-source system. I want to keep it that way. With EME, they can lock me out, and it would be W3C standards approved and completely legit.

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

This comment has been minimized.

Show comment
Hide comment
@zutje

zutje Apr 15, 2017

zutje commented Apr 15, 2017

@marado

This comment has been minimized.

Show comment
Hide comment
@marado

marado Apr 15, 2017

marado commented Apr 15, 2017

@mwatson2

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 15, 2017

Contributor

@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.

Contributor

mwatson2 commented Apr 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 16, 2017

@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.

GravisZro commented Apr 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 16, 2017

Contributor

@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 ?

Contributor

mwatson2 commented Apr 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 16, 2017

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.

GravisZro commented Apr 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 16, 2017

Contributor

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

Contributor

mwatson2 commented Apr 16, 2017

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

@GravisZro

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 16, 2017

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.

GravisZro commented Apr 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 16, 2017

Contributor

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.

Contributor

mwatson2 commented Apr 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 16, 2017

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.

benbucksch commented Apr 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 16, 2017

@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.

GravisZro commented Apr 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@doctorow

doctorow Apr 16, 2017

doctorow commented Apr 16, 2017

@GravisZro

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 16, 2017

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?

GravisZro commented Apr 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 16, 2017

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

ghost commented Apr 16, 2017

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

@mwatson2

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 17, 2017

Contributor

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.

Contributor

mwatson2 commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@doctorow

doctorow Apr 17, 2017

doctorow commented Apr 17, 2017

@taravancil

This comment has been minimized.

Show comment
Hide comment
@taravancil

taravancil Apr 17, 2017

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

taravancil commented Apr 17, 2017

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

@mwatson2

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 17, 2017

Contributor

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.]

protectedcontent

Contributor

mwatson2 commented Apr 17, 2017

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.]

protectedcontent

@mwatson2

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 17, 2017

Contributor

@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.

Contributor

mwatson2 commented Apr 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 17, 2017

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."

GravisZro commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 17, 2017

Contributor

@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.

Contributor

mwatson2 commented Apr 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 17, 2017

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.

benbucksch commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 17, 2017

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.

GravisZro commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@plehegar

plehegar Apr 18, 2017

Member

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.

Member

plehegar commented Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 18, 2017

@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.

GravisZro commented Apr 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@pikurasa

pikurasa Apr 19, 2017

@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).

pikurasa commented Apr 19, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 19, 2017

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.

benbucksch commented Apr 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dannyob

dannyob Apr 20, 2017

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.

dannyob commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 20, 2017

Contributor

@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.

Contributor

mwatson2 commented Apr 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 20, 2017

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 commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@benbucksch

benbucksch Apr 20, 2017

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.

benbucksch commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 20, 2017

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!

GravisZro commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 20, 2017

Contributor

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.

Contributor

mwatson2 commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@joeyparrish

joeyparrish Apr 20, 2017

Member

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.

Member

joeyparrish commented Apr 20, 2017

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.

@sampablokuper

This comment has been minimized.

Show comment
Hide comment
@sampablokuper

sampablokuper Apr 20, 2017

@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).

sampablokuper commented Apr 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@diracdeltas

diracdeltas Apr 20, 2017

@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.

screen shot 2017-04-20 at 18 09 27

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.

diracdeltas commented Apr 20, 2017

@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.

screen shot 2017-04-20 at 18 09 27

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

This comment has been minimized.

Show comment
Hide comment
@mwatson2

mwatson2 Apr 20, 2017

Contributor

@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 ?

Contributor

mwatson2 commented Apr 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@zutje

zutje Apr 20, 2017

zutje commented Apr 20, 2017

@GravisZro

This comment has been minimized.

Show comment
Hide comment
@GravisZro

GravisZro Apr 20, 2017

@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.

GravisZro commented Apr 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@zutje

zutje Apr 20, 2017

zutje commented Apr 20, 2017

@sampablokuper

This comment has been minimized.

Show comment
Hide comment
@sampablokuper

sampablokuper Apr 20, 2017

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.

sampablokuper commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zutje

zutje Apr 20, 2017

zutje commented Apr 20, 2017

@plehegar

This comment has been minimized.

Show comment
Hide comment

@plehegar plehegar closed this Sep 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment