W3C declares DRM in scope for HTML

[saura...@gmail.com]

The W3C has declared <http://slashdot.org/story/13/02/12/014257/w3c-declares-drm-in-scope-for-html> that DRM is in scope for HTML. What is Mozilla's official response regarding this? Do you think Mozilla can/will refuse to implement DRM related items in the spec even if the spec with DRM provisions is finally accepted?

- Saurabh

[yajo...@gmail.com]

Hello everyone.

This subject is worrying many users, but it seems it has been discussed in the wrong place [1], so, again, but in the right place: Are there any official Mozilla plans for this?

Thanks.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=923590

[byte...@gmail.com]

On Tuesday, February 12, 2013 2:38:16 PM UTC-5, saura...@gmail.com wrote:
>Do you think Mozilla can/will refuse to implement DRM related items in the spec even if the spec with DRM provisions is finally accepted?

I don't think that Mozilla will be able to. A proprietary blob would be necessary, and from what I've been reading in the buglist for this, the ability to even develop a proprietary blob is rather improbable.

[Gijs Kruitbosch]

Speaking purely possibility-wise here: one could envision having a
proprietary blob being delivered in an add-on, making use of builtin
possibilities to install and use such a blob. Not very different from
plugins, but it would work and not have the
licensing/patent/this-is-closed-and-we-cant-do-that issues that shipping
such a blob would have.

~ Gijs

[Matt Basta]

Would a better solution be to simply propose a low-level JS API for video/audio decoding (something like rAF+webworkers+webgl)? Companies would have to implement their own DRM in client-side JS if they wanted it. It would also mean that the browser would no longer be the broker of video formats; if you want H.264 or WMV or AVCHD or whatever codec you want, you could write the decoder yourself (or use a stock one provided by the codec developer). It would also open the door to folks wishing to build their own experimental codecs.

We know that companies are going to have this: they already do, through Flash and Silverlight. Rather than baking it into the browser and forcing it on the consumer, we should just provide hooks and say "do your own thing, not our business". At least then the user gets the safety of the web and Mozilla (or any other browser vendor) isn't forced into taking sides on EME. It also, in some ways, kills the format wars and makes browsers' codec support irrelevant.

_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

[Brendan Eich]

On Monday, October 14, 2013 10:32:32 AM UTC-7, Matt Basta wrote:

> Would a better solution be to simply propose a low-level JS API for video/audio decoding (something like rAF+webworkers+webgl)? Companies would have to implement their own DRM in client-side JS if they wanted it. It would also mean that the browser would no longer be the broker of video formats; if you want H.264 or WMV or AVCHD or whatever codec you want, you could write the decoder yourself (or use a stock one provided by the codec developer). It would also open the door to folks wishing to build their own experimental codecs.

Henri has posted http://hsivonen.fi/eme/ to explain what EME is.

MSE (Media Source Extensions) is a related standard to EME:

https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

In theory, MSE would be enough to do part of what you suggest, decryption. We are not sure it could do video decoding as well, at least not without some other new APIs, but let's assume "in time" that it could.

One problem is "robustness", meaning how hard it is for someone circumventing to get at the decrypted data. Native/hardware-based solutions can dial this to 11, even if it is not really meaningful (people crack robust schemes quickly and constantly).

Another problem is that even if we could do a JS-only implementation, other browsers equipped with built-in solutions would have lower cost due to lack of an obligatory downloaded JS blob, and that would probably prevail in the market.

This might change if other things favor the JS solution, of course, and we're looking at what it takes to make that future a competitive reality. OTOY has ORBX, as I've blogged about: a video codec implemented in JS and WebGL.

https://brendaneich.com/2013/05/today-i-saw-the-future/

OTOY has demonstrated GPU-cloud-based per-user-per-iframe watermarking, which some in Hollywood see as sufficient in lieu of DRM. Note how watermarking is sufficient for many online music providers.

But let's be realistic: to satisfy market-based availability and performance constraints in the immediate term, we will need H.264 and AAC hardware.

And worse, as Hixie proved:

https://plus.google.com/app/basic/stream/z13qtnxhuojytbjbr04ci3cowrmtehsy324

DRM is not about technical means of preventing copying of copyrighted materials, rather it is about gaining leverage (including legal leverage) over playback "device" makers.

Also, DRM as proposed via EME is really all about Hollywood movies. It is not about copyrighted materials in general, nor should or can it be (see Hixie's post, or just see the Web).

The playback "device" maker category includes vendors of plugins available cross-browser via NPAPI, of course really just Flash and Silverlight these days. It looks likely to include OS/browser vendors who purvey non-standardized CDMs available under cover of EME only to certain select OS/browser combinations -- possibly only each its own OS and browser!

This is a big problem in my view, for all of:

* the W3C (or at least its reputation);
* Linux and other OSes like it;
* Mozilla and other open-source, independent, or small-scale browser makers;
* new hardware platforms (Anne tells of the Wii coming up with downrev Flash);
* last but not least, the Web as an open and interoperable content system.

> We know that companies are going to have this: they already do, through Flash and Silverlight. Rather than baking it into the browser and forcing it on the consumer, we should just provide hooks and say "do your own thing, not our business". At least then the user gets the safety of the web and Mozilla (or any other browser vendor) isn't forced into taking sides on EME. It also, in some ways, kills the format wars and makes browsers' codec support irrelevant.

This is a great long-term goal, and the reason why we are collaborating with OTOY.

However, in the near term, it does not work. The reason EME exists, instead of MSE sufficing, is the Hollywood requirement for "robustness" against circumvention. Not only are CDMs unspecified and "robust" as software black boxes, ARM's TrustZone(tm) memory by design restricts decrypted pixel access in hardware.

When I write "it does not work", I mean no Netflix in Firefox without Silverlight.

This brings up something all Mozillians need to consider carefully. As with H.264, we are not "pure" by delegating to existing plugins, namely Flash and Silverlight. We would not have a competitive browser without them.

This means we should consider new plugins that have smaller APIs, trusted computing bases, and attack surfaces, if we must in order to survive and fight the longer-term battle. We are not obligated by mission to reject such new plugins, and we have not rejected old plugins on the basis of their DRM support.

/be

[and...@ducker.org.uk]

On Thursday, 17 October 2013 00:15:16 UTC+1, Brendan Eich wrote:
> This means we should consider new plugins that have smaller APIs, trusted computing bases, and attack surfaces, if we must in order to survive and fight the longer-term battle.

This is the key argument for me - if Mozilla can have move 95% of the video-playing stack over to HTML, leaving only 5% in a plugin, then that's a win.

Andrew Ducker

[pya...@gmail.com]

On Thursday, October 17, 2013 1:15:16 AM UTC+2, Brendan Eich wrote:
> This means we should consider new plugins that have smaller APIs, trusted computing bases, and attack surfaces, if we must in order to survive and fight the longer-term battle. We are not obligated by mission to reject such new plugins, and we have not rejected old plugins on the basis of their DRM support.

The core problem is this:

If the CDM grants raw pixel access to the browser using the CDM, as is required to have a flexible compositor/renderer (HW or software capable, programmed in the suitable fashion best for the browser) for such things as layering content (advertising, user annotations, playback controls, site branding, closed captions etc.) on top of the video, applying CSS transforms/filters and stuffing it into WebGL, then the browser (or any program like wget or a v8 script) can just dump the content to disk. Since EME can't allow that, the CDM will not be designed to allow raw pixel access.

But that means that the CDM needs to bypass the browser completely to put pixels on screen, and it means that the video cannot be under other elements (no advertising, no closed captions, no user annoations, no site branding, no styled playback controls, no loading spinners, no other informational/navigational content). The video cannot be transformed/filtered by CSS and it cannot be stuffed into WebGL.

If you look at *any* video player in existence, in whatever technology (flash, silverlight, html video) by whatever big redistribution company (netflix, youtube, vimeo, dailymotion, etc.) they *all* apply at least some of these things: advertising, branding, user annoations, custom playback controls, loading spinners, loading bars, branding etc. *on top* of the video.

It can credibly be argued that none of these sites (netflix, youtube, vimeo, dailymotion etc.) will be happy with a CDM that allows no drawing on top, no CSS transform/filtering and maybe in the future, stuffing it into WebGL.

So since it would be useless for Netflix, to support a CDM, that doesn't do what their branding/webdesign team wants to do, it follows that a CDM that netflix will support/use, *will* expose the raw pixels to the browser.

Therefore, it follows that the CDM that Netflix will support/use exclusively, will be the one that is not offered to open source software, because it either means that it won't be as "secure" as EME demands, or it will be completely feature crippled because it can't interact with the browsers compositor.

[David Bruant]

Le 17/10/2013 15:00, pya...@gmail.com a écrit :
> On Thursday, October 17, 2013 1:15:16 AM UTC+2, Brendan Eich wrote:
>> This means we should consider new plugins that have smaller APIs, trusted computing bases, and attack surfaces, if we must in order to survive and fight the longer-term battle. We are not obligated by mission to reject such new plugins, and we have not rejected old plugins on the basis of their DRM support.
> The core problem is this:

"The" problem for whom? End-users? Content providers? Mozilla? The long
term health of the web?

> If the CDM grants raw pixel access to the browser using the CDM, as is required to have a flexible compositor/renderer (HW or software capable, programmed in the suitable fashion best for the browser) for such things as layering content (advertising, user annotations, playback controls, site branding, closed captions etc.) on top of the video, applying CSS transforms/filters and stuffing it into WebGL, then the browser (or any program like wget or a v8 script) can just dump the content to disk. Since EME can't allow that, the CDM will not be designed to allow raw pixel access.
>
> But that means that the CDM needs to bypass the browser completely to put pixels on screen, and it means that the video cannot be under other elements (no advertising, no closed captions, no user annoations, no site branding, no styled playback controls, no loading spinners, no other informational/navigational content). The video cannot be transformed/filtered by CSS and it cannot be stuffed into WebGL.
>
> If you look at *any* video player in existence, in whatever technology (flash, silverlight, html video) by whatever big redistribution company (netflix, youtube, vimeo, dailymotion, etc.) they *all* apply at least some of these things: advertising, branding, user annoations, custom playback controls, loading spinners, loading bars, branding etc. *on top* of the video.

Even with Adobe Access or Microsoft's PlayReady?
...yeah... I guess they can do that in Flash/Silverlight. This can't
happen in EME since the additional content would most likely be in
otherwise "HTML5" technologies...
Why couldn't a CDM be programmed to add ads on the fly? The browser
providing a black box for CDMs doesn't prevent CDMs from making this
blackbox interactive.
And a programming interface to discuss with the surrounding page?
... did I just describe <object>? Damned!

> It can credibly be argued that none of these sites (netflix, youtube, vimeo, dailymotion etc.) will be happy with a CDM that allows no drawing on top, no CSS transform/filtering and maybe in the future, stuffing it into WebGL.

Netflix is pushing for EME and is most certainly working with Microsoft
and Google on a CDM that will satisfy their needs, whatever these needs
exactly are (whether they include adding ads, etc.).

> So since it would be useless for Netflix, to support a CDM, that doesn't do what their branding/webdesign team wants to do, it follows that a CDM that netflix will support/use, *will* expose the raw pixels to the browser.
>
> Therefore, it follows that the CDM that Netflix will support/use exclusively, will be the one that is not offered to open source software, because it either means that it won't be as "secure" as EME demands,

Just to clarify, EME demands nothing and expects nothing in term of
content security as somewhat demonstrated by the ClearKey Key System.

> or it will be completely feature crippled because it can't interact with the browsers compositor.

Not even surprised :-)
If you're right, then EME's limitated by design. Only a problem to those
who want to protect their content. Add this to the pile of reasons why
DRMs are a bad idea?

David

[pya...@gmail.com]

On Thursday, October 17, 2013 4:49:39 PM UTC+2, David Bruant wrote:
> "The" problem for whom? End-users? Content providers? Mozilla? The long
> term health of the web?

Mozilla, Firefox, FirefoxOS, Chromium, Ouya, Community Android, SteamBox, Haiku, Plan9, Linux, NetBSD, FreeBSD, OpenBSD and the health of the web.

> Even with Adobe Access or Microsoft's PlayReady?
> ...yeah... I guess they can do that in Flash/Silverlight. This can't
> happen in EME since the additional content would most likely be in
> otherwise "HTML5" technologies...
> Why couldn't a CDM be programmed to add ads on the fly? The browser
> providing a black box for CDMs doesn't prevent CDMs from making this
> blackbox interactive.
> And a programming interface to discuss with the surrounding page?
>
> ... did I just describe <object>? Damned!

Well there's multiple "options" to address this, at least from a browser perspective.

1) You can ignore the issue, and EME/CDMs that can't interact with the compositor are extremely unlikely to be used by anybody in posession of a big web property.

2) In don't know if this is feasible, or even a good idea, but in theory the browser could hand EME a transformation matrix (ala CSS transform) and a buffer with pixels that should be pasted on top of the rendered content. When compositing the page, it'd grab the pixels covering the video and hand them to EME to be pasted on top of the content by the CDM (alpha masked to respect the distorted rectangle of the video. Far as I know, no such mechanism is forseen by EME, maybe it could be proposed?

3) Every web property ships their own CDM and installs a custom binary blob on a users computer. I'm pretty sure that's an idiotic idea. It's even worse than flash/silverlight, you're now installing N different binary blobs containing anything from viruses, malware, backdoors or rootkits on a users computer.

4) You could make the CDM interact with the compositor, in which case it's effectiveness is zero, so that's not gonna happen.

> Netflix is pushing for EME and is most certainly working with Microsoft
> and Google on a CDM that will satisfy their needs, whatever these needs
> exactly are (whether they include adding ads, etc.).

If Netflix/Google/Microsoft hash out a proprietary piece of software that can't be used as a "plug-in" to any other program (because not effective DRM), then that's the huge problem for anybody but Netflix/Google/Microsoft, i.e. Firefox.

> Just to clarify, EME demands nothing and expects nothing in term of
> content security as somewhat demonstrated by the ClearKey Key System.

That's not how the content industry sees it. They demand that any DRM satisfies their paranoia metric of being difficult to circumvent, or they yank the distribution rights out from under any company that distributes content in that fashion.

> Not even surprised :-)
> If you're right, then EME's limitated by design. Only a problem to those
> who want to protect their content. Add this to the pile of reasons why
> DRMs are a bad idea?

Of course DRM is stupid, I don't even know why the DRM-tards try to come up with some sort of technically difficult system to hassle end-users with. The time it takes to overcome a DRM: who knows. The time it takes to go to the piratebay and simply find whatever you've been forbidden from seeing or saving to disk for later: roughly 20 seconds.

But somehow the content industry thinks that slapping DRM on everything will make the piratebay go away.

[Allen Wirfs-Brock]

On Oct 17, 2013, at 8:14 AM, pya...@gmail.com wrote:
>
> ...

> Well there's multiple "options" to address this, at least from a browser perspective.
>
> 1) You can ignore the issue, and EME/CDMs that can't interact with the compositor are extremely unlikely to be used by anybody in posession of a big web property.
>
> 2) In don't know if this is feasible, or even a good idea, but in theory the browser could hand EME a transformation matrix (ala CSS transform) and a buffer with pixels that should be pasted on top of the rendered content. When compositing the page, it'd grab the pixels covering the video and hand them to EME to be pasted on top of the content by the CDM (alpha masked to respect the distorted rectangle of the video. Far as I know, no such mechanism is forseen by EME, maybe it could be proposed?
>
> 3) Every web property ships their own CDM and installs a custom binary blob on a users computer. I'm pretty sure that's an idiotic idea. It's even worse than flash/silverlight, you're now installing N different binary blobs containing anything from viruses, malware, backdoors or rootkits on a users computer.
>
> 4) You could make the CDM interact with the compositor, in which case it's effectiveness is zero, so that's not gonna happen.

Wouldn't another solution be to drive the compositor deeper into the platform stack. Perhaps all the way into the GPU hardware? It would be a longer term solution but a "hard wired" (ie closed) compositor would seem like something we and most other open systems could live with.

Allen

[pya...@gmail.com]

On Thursday, October 17, 2013 5:24:20 PM UTC+2, Allen Wirfs-Brock wrote:
> Wouldn't another solution be to drive the compositor deeper into the platform stack. Perhaps all the way into the GPU hardware? It would be a longer term solution but a "hard wired" (ie closed) compositor would seem like something we and most other open systems could live with.

I don't think that's realistic. First of all, you'll want the ability to software composit, just because you might not have a GPU to do the job for you (bad drivers/hardware etc.).

The ability to interact with the GPU, to push data and shaders to it, to have it perform dependent lookups, to read data back and to partially assemble bits&pieces in software is where you get performance. If you defer everything, then there's no way to improve rendering/compositing from a browsers perspective, and you're locked into whatever that particular compositing API semantic supports. For instance:

You couldn't do:

- sparse virtual texturing
- perfect hash textures
- distance field fonts
- vector shape evaluation in shaders
- Take control of mipmapping/anisotropic filtering
- Substitute in summed area tables for mipmaps
- tessellation/geometry/compute shader generated text/vector shapes

Doesn't sound like a fun place to go from a rendering perspective, zero room for improvements via locked down compositor.

[Allen Wirfs-Brock]

On Oct 17, 2013, at 8:37 AM, pya...@gmail.com wrote:

> On Thursday, October 17, 2013 5:24:20 PM UTC+2, Allen Wirfs-Brock wrote:
>> Wouldn't another solution be to drive the compositor deeper into the platform stack. Perhaps all the way into the GPU hardware? It would be a longer term solution but a "hard wired" (ie closed) compositor would seem like something we and most other open systems could live with.
>
> I don't think that's realistic. First of all, you'll want the ability to software composit, just because you might not have a GPU to do the job for you (bad drivers/hardware etc.).

You could still do software compositing, just not compositing that involves "protected content".

>
> The ability to interact with the GPU, to push data and shaders to it, to have it perform dependent lookups, to read data back and to partially assemble bits&pieces in software is where you get performance. If you defer everything, then there's no way to improve rendering/compositing from a browsers perspective, and you're locked into whatever that particular compositing API semantic supports. For instance:
>
> You couldn't do:
>
> - sparse virtual texturing
> - perfect hash textures
> - distance field fonts
> - vector shape evaluation in shaders
> - Take control of mipmapping/anisotropic filtering
> - Substitute in summed area tables for mipmaps
> - tessellation/geometry/compute shader generated text/vector shapes
>
> Doesn't sound like a fun place to go from a rendering perspective, zero room for improvements via locked down compositor.

No reason all of these capabilities couldn't still be support as long as protected content has not been composited in. We might prefer that there was no such beast as protected content, but if it will exist (and it doesn't sound like we can prevent its existence) then this seems like a minimally intrusive way for a system to enable it.

Allen

[David Bruant]

Le 17/10/2013 17:14, pya...@gmail.com a écrit :
> On Thursday, October 17, 2013 4:49:39 PM UTC+2, David Bruant wrote:
>> "The" problem for whom? End-users? Content providers? Mozilla? The long
>> term health of the web?
> Mozilla, Firefox, FirefoxOS, Chromium, Ouya, Community Android, SteamBox, Haiku, Plan9, Linux, NetBSD, FreeBSD, OpenBSD and the health of the web.

You spent 5 paragraphs explaining that EME+CDMs are insufficient to
implement ads on top of content or are sufficient but by making content
copyable on disk. I'm not sure why this is a problem for any of the
entities cited above...

>> Even with Adobe Access or Microsoft's PlayReady?
>> ...yeah... I guess they can do that in Flash/Silverlight. This can't
>> happen in EME since the additional content would most likely be in
>> otherwise "HTML5" technologies...
>> Why couldn't a CDM be programmed to add ads on the fly? The browser
>> providing a black box for CDMs doesn't prevent CDMs from making this
>> blackbox interactive.
>> And a programming interface to discuss with the surrounding page?
>>
>> ... did I just describe <object>? Damned!
> Well there's multiple "options" to address this, at least from a browser perspective.
>
> 1) You can ignore the issue, and EME/CDMs that can't interact with the compositor are extremely unlikely to be used by anybody in posession of a big web property.
>
> 2) In don't know if this is feasible, or even a good idea, but in theory the browser could hand EME a transformation matrix (ala CSS transform) and a buffer with pixels that should be pasted on top of the rendered content. When compositing the page, it'd grab the pixels covering the video and hand them to EME to be pasted on top of the content by the CDM (alpha masked to respect the distorted rectangle of the video. Far as I know, no such mechanism is forseen by EME, maybe it could be proposed?

What is the purpose of this? Improving EME? Making EME cover more use cases?
I don't think this mailing-list is the appropriate place to discuss EME
improvements. If you have improvements to suggest, go to those who
already implement it?

> 3) Every web property ships their own CDM and installs a custom binary blob on a users computer. I'm pretty sure that's an idiotic idea. It's even worse than flash/silverlight, you're now installing N different binary blobs containing anything from viruses, malware, backdoors or rootkits on a users computer.
>
> 4) You could make the CDM interact with the compositor, in which case it's effectiveness is zero, so that's not gonna happen.
>
>> Netflix is pushing for EME and is most certainly working with Microsoft
>> and Google on a CDM that will satisfy their needs, whatever these needs
>> exactly are (whether they include adding ads, etc.).
> If Netflix/Google/Microsoft hash out a proprietary piece of software that can't be used as a "plug-in" to any other program (because not effective DRM), then that's the huge problem for anybody but Netflix/Google/Microsoft, i.e. Firefox.

My answer was in the context of you saying that Netflix might be
unsatisfied with EME as it is. I'm not sure I understand your answer.
Please keep context of a discussion.

>> Just to clarify, EME demands nothing and expects nothing in term of
>> content security as somewhat demonstrated by the ClearKey Key System.
> That's not how the content industry sees it. They demand that any DRM satisfies their paranoia metric of being difficult to circumvent, or they yank the distribution rights out from under any company that distributes content in that fashion.

In the EME/DRM discussions, lots of inaccurate if not wrong things are
being said, I just clarified the fact that the EME spec in itself
doesn't carry the security requirements you suggested. Of course, those
pushing EME have different requirements than what is written in the EME
spec.
EME is not to be confused with those pushing for it; let's be accurate
in this debate, people read about it.

David

[Zack Weinberg]

On 2013-10-17 12:30 PM, David Bruant wrote:
> Le 17/10/2013 17:14, pya...@gmail.com a écrit :
>> On Thursday, October 17, 2013 4:49:39 PM UTC+2, David Bruant wrote:
>>> "The" problem for whom? End-users? Content providers? Mozilla? The long
>>> term health of the web?
>> Mozilla, Firefox, FirefoxOS, Chromium, Ouya, Community Android,
>> SteamBox, Haiku, Plan9, Linux, NetBSD, FreeBSD, OpenBSD and the health
>> of the web.
> You spent 5 paragraphs explaining that EME+CDMs are insufficient to
> implement ads on top of content or are sufficient but by making content
> copyable on disk. I'm not sure why this is a problem for any of the
> entities cited above...

I believe this is aiming at the assertion that *even if* Mozilla (for
instance) implements the EME API and the CDM plugin API, the vendors of
the actual CDMs may refuse to make their CDMs work with an open-source
browser.

zw

[semn...@gmail.com]

On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30, saura...@gmail.com wrote:
> The W3C has declared <http://slashdot.org/story/13/02/12/014257/w3c-declares-drm-in-scope-for-html> that DRM is in scope for HTML. What is Mozilla's official response regarding this? Do you think Mozilla can/will refuse to implement DRM related items in the spec even if the spec with DRM provisions is finally accepted?
>
>
>
> - Saurabh

I dont even want to use black box in my browser. if W3C want to use this for money talkers like google or media companies, let it be, mozilla is community and must be followed by people no companies like google, microsoft or apple.
We love mozilla cause it's defense the privacy, dont sell user data to NSA or etc ...
Google, Apple, Microsoft push on W3C to implement DRM or any future of web. It is time to decision to be with people or against them.
viva Mozilla.
W3c is still alive during being reference for developers.

[Melvin Carvalho]

The web and also the w3c have been under attack consistently since
inception, there's nothing really new here. I strongly believe that the
scope is consistent with the principles.

This is nothing at all to do with the w3c who are open to ideas.

This simply a question of whether mozilla wants to back this new
technology, and as a consequence wants to open or close their source.

Of course mozilla are highly influenced by google. but I'd be be extremely
happy if it remained open source.

[Steve Fink]

On 10/18/2013 05:54 PM, Melvin Carvalho wrote:
> On 19 October 2013 00:42, <semn...@gmail.com> wrote:
>

>> On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30, saura...@gmail.comwrote:
>>> The W3C has declared <
>> http://slashdot.org/story/13/02/12/014257/w3c-declares-drm-in-scope-for-html>
>> that DRM is in scope for HTML. What is Mozilla's official response
>> regarding this? Do you think Mozilla can/will refuse to implement DRM
>> related items in the spec even if the spec with DRM provisions is finally
>> accepted?
>>>
>>>
>>> - Saurabh
>> I dont even want to use black box in my browser. if W3C want to use this
>> for money talkers like google or media companies, let it be, mozilla is
>> community and must be followed by people no companies like google,
>> microsoft or apple.

The decision here would not change anything related to this. If you buy
a Hollywood video and wish to view it using your browser, you will have
to use some sort of black boxed plugin to view it. If you refuse to use
any sort of black boxing, you will not view the video. If you choose to
pirate the video instead, you will be breaking a law, and you will be
able to view the video without using any sort of black box.

>> We love mozilla cause it's defense the privacy, dont sell user data to NSA
>> or etc ...

Mozilla does not and can not protect you from the NSA, except indirectly
by lobbying for laws to be changed and/or enforced.

As far as I am aware, nobody has been accused of selling user data to
the NSA. If the NSA wants the data, they coerce whoever has it to give
it to them.

>> Google, Apple, Microsoft push on W3C to implement DRM or any future of
>> web. It is time to decision to be with people or against them.
>> viva Mozilla.

The EME decision standardizes the interface for using DRM. In practical
terms, it does not enable anything that was previously impossible.
Whether or not it will end up making DRM more or less prevalent is a
question of game theory, and can be legitimately argued. But it is an
oversimplification to assert that Mozilla implementing EME is equivalent
to Mozilla accepting or promoting DRM.

If you look at the branches of the game theory tree where Mozilla
refuses EME, one possible branch leads to Firefox's market share
collapsing and DRM becoming more widespread. This would seriously damage
Mozilla's mission of improving the Web. It is not the only possible
outcome of refusing EME, and other possibilities have a better outcome.
But it is one we need to avoid, and simply saying that we will have
nothing to do with EME is dangerous.

>> W3c is still alive during being reference for developer-

>>
> The web and also the w3c have been under attack consistently since
> inception, there's nothing really new here. I strongly believe that the
> scope is consistent with the principles.
>
> This is nothing at all to do with the w3c who are open to ideas.
>
> This simply a question of whether mozilla wants to back this new
> technology, and as a consequence wants to open or close their source.

Implementing EME would not close Mozilla's source. It would provide an
open source extension framework that would allow third parties to inject
DRM and black boxes and cryptography keys and ugly-looking cats and
dogs. All at the same time. Living together.

Some number of end users would then choose to install closed-source
black boxes for decoding DRM'd movies via EME. If Firefox does not
implement EME, then some number of end users will switch browsers, some
number will use an alternative closed-source black box browser plugin
such as what exists today (Flash, Silverlight), and some number will
play the movies via separate closed-source black box applications that
having nothing to do with a browser. Again, it's a matter of game theory
to figure out what the end result is.

> Of course mozilla are highly influenced by google.

Mozilla has been foolish enough to pay me to work for them for a few
years now. The only way in which I have ever noticed Google influencing
us is by being faster/better at something or other and forcing us via
market pressure to catch up. If they were able to push us around, they
never would have implemented Chrome. Paying that many developers to
implement their own private browser is not cheap. It may seem odd that
Google has so little influence given the amount of money they feed us,
but (1) the traffic we send to them is enormously valuable in its own
right, and (2) they're also paying us to NOT send that traffic to
somebody else. (To me, Google's Chrome strategy feels more like risk
mitigation than profit-seeking.)

> but I'd be be extremely happy if it remained open source.
>

Mozilla's mission does not absolutely require the browser to be open
source. Its current culture pretty much does. There are few if any
factors motivating us to close the source. There are large factors
keeping us with open source (like, say, the whole Mozilla volunteer
community!)

In other words, it ain't gonna happen.

Footnote 1: Despite my air of assurance above, I haven't been following
any of this EME stuff very closely. Somebody please correct whatever I
got wrong.

Footnote 2: Another bad outcome (or branch in the game tree, if you
prefer) is if personal videos and tutorials and other non-Hollywood
videos were to start using a DRM-encrusted delivery mechanism commonly
or by default. This would be far worse than just having DRM used for
Hollywood material. The health of the Open Web does not depend on
Hollywood movies being watchable and remixable without DRM. (It would be
great for the Web if they were, since it's a rich source of raw
material, but it's no great loss to not have that.) Not being able to
watch Hollywood movies at all on an open base platform (Linux, Firefox,
etc.) *is* serious, if it leads to a dramatic loss of market share for
those platforms.

[Boris Zbarsky]

On 10/18/13 10:39 PM, Steve Fink wrote:
> The EME decision standardizes the interface for using DRM.

Sort of. I suggest reading http://hsivonen.fi/eme/ if you haven't been
following exactly what EME does and doesn't do.

-Boris

[Steve Wendt]

On 10/18/2013 7:39 PM, Steve Fink wrote:

> As far as I am aware, nobody has been accused of selling user data to
> the NSA. If the NSA wants the data, they coerce whoever has it to give
> it to them.

Sometimes that coercion includes monetary compensation; not quite the
same as selling the data, but there is an exchange of data for money.
http://www.usatoday.com/story/news/nation/2013/08/23/nsa-paid-internet-firms-surveillance-prism/2693701/

[Melvin Carvalho]

On 19 October 2013 04:39, Steve Fink <sf...@mozilla.com> wrote:

> On 10/18/2013 05:54 PM, Melvin Carvalho wrote:
> > On 19 October 2013 00:42, <semn...@gmail.com> wrote:
> >

> >> On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30,
> saura...@gmail.comwrote:
> >>> The W3C has declared <
> >>
> http://slashdot.org/story/13/02/12/014257/w3c-declares-drm-in-scope-for-html
> >
> >> that DRM is in scope for HTML. What is Mozilla's official response
> >> regarding this? Do you think Mozilla can/will refuse to implement DRM
> >> related items in the spec even if the spec with DRM provisions is
> finally
> >> accepted?
> >>>
> >>>
> >>> - Saurabh
> >> I dont even want to use black box in my browser. if W3C want to use this
> >> for money talkers like google or media companies, let it be, mozilla is
> >> community and must be followed by people no companies like google,
> >> microsoft or apple.
>

> The decision here would not change anything related to this. If you buy
> a Hollywood video and wish to view it using your browser, you will have
> to use some sort of black boxed plugin to view it. If you refuse to use
> any sort of black boxing, you will not view the video. If you choose to
> pirate the video instead, you will be breaking a law, and you will be
> able to view the video without using any sort of black box.
>

> >> We love mozilla cause it's defense the privacy, dont sell user data to
> NSA
> >> or etc ...
>

> Mozilla does not and can not protect you from the NSA, except indirectly
> by lobbying for laws to be changed and/or enforced.
>

> As far as I am aware, nobody has been accused of selling user data to
> the NSA. If the NSA wants the data, they coerce whoever has it to give
> it to them.
>

> >> Google, Apple, Microsoft push on W3C to implement DRM or any future of
> >> web. It is time to decision to be with people or against them.
> >> viva Mozilla.
>

If Mozilla's mission does not guarantee the browser to be open source, how
does that square with the Mozilla Foundation's pledge:

[[
Mozilla Foundation Pledge

The Mozilla Foundation pledges to support the Mozilla Manifesto in its
activities. Specifically, we will:

build and enable open-source technologies and communities that support the
Manifesto’s principles;

]]

Does the mission trump the manifesto and pledge, or have I misunderstood?

http://www.mozilla.org/en-US/about/manifesto/

> There are few if any
> factors motivating us to close the source. There are large factors
> keeping us with open source (like, say, the whole Mozilla volunteer
> community!)
>
> In other words, it ain't gonna happen.
>
> Footnote 1: Despite my air of assurance above, I haven't been following
> any of this EME stuff very closely. Somebody please correct whatever I
> got wrong.
>
> Footnote 2: Another bad outcome (or branch in the game tree, if you
> prefer) is if personal videos and tutorials and other non-Hollywood
> videos were to start using a DRM-encrusted delivery mechanism commonly
> or by default. This would be far worse than just having DRM used for
> Hollywood material. The health of the Open Web does not depend on
> Hollywood movies being watchable and remixable without DRM. (It would be
> great for the Web if they were, since it's a rich source of raw
> material, but it's no great loss to not have that.) Not being able to
> watch Hollywood movies at all on an open base platform (Linux, Firefox,
> etc.) *is* serious, if it leads to a dramatic loss of market share for
> those platforms.
>

[Adam Roach]

On 10/18/13 19:54, Melvin Carvalho wrote:
> This simply a question of whether mozilla wants to back this new
> technology, and as a consequence wants to open or close their source.

Out of curiosity, do you consider the fact that Firefox can run things
like Silverlight to be closing Firefox's source code?

If so, this ship sailed on day one of Mozilla's existence, and you're
about 15 years too late to be having this conversation.

If not, I'd be interested to hear you expand on your theory that a
no-holds-barred plugin architecture is compatible with some notion of
open source, while a smaller API that protects the browser and user from
certain types of malfeasance on the part of the external code does not.

/a

[Gavin Sharp]

This tangent about open source isn't really productive. Mozilla is not
making any changes to its stance on the value of open source software
development or our commitment to keeping Firefox open source. Support
for EME is fundamentally no different than support for NPAPI in that
regard. There are many aspects of EME that would be useful to debate
and discuss. Its impact on "open source-ness" of Firefox is not one of
them.

Gavin

On Sun, Oct 20, 2013 at 8:22 AM, Melvin Carvalho
<melvinc...@gmail.com> wrote:
> On 19 October 2013 04:39, Steve Fink <sf...@mozilla.com> wrote:
>
>> On 10/18/2013 05:54 PM, Melvin Carvalho wrote:
>> > On 19 October 2013 00:42, <semn...@gmail.com> wrote:
>> >

>> >> On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30,
>> saura...@gmail.comwrote:
>> >>> The W3C has declared <
>> >>
>> http://slashdot.org/story/13/02/12/014257/w3c-declares-drm-in-scope-for-html
>> >
>> >> that DRM is in scope for HTML. What is Mozilla's official response
>> >> regarding this? Do you think Mozilla can/will refuse to implement DRM
>> >> related items in the spec even if the spec with DRM provisions is
>> finally
>> >> accepted?
>> >>>
>> >>>
>> >>> - Saurabh
>> >> I dont even want to use black box in my browser. if W3C want to use this
>> >> for money talkers like google or media companies, let it be, mozilla is
>> >> community and must be followed by people no companies like google,
>> >> microsoft or apple.
>>

>> The decision here would not change anything related to this. If you buy
>> a Hollywood video and wish to view it using your browser, you will have
>> to use some sort of black boxed plugin to view it. If you refuse to use
>> any sort of black boxing, you will not view the video. If you choose to
>> pirate the video instead, you will be breaking a law, and you will be
>> able to view the video without using any sort of black box.
>>

>> >> We love mozilla cause it's defense the privacy, dont sell user data to
>> NSA
>> >> or etc ...
>>

>> Mozilla does not and can not protect you from the NSA, except indirectly
>> by lobbying for laws to be changed and/or enforced.
>>
>> As far as I am aware, nobody has been accused of selling user data to
>> the NSA. If the NSA wants the data, they coerce whoever has it to give
>> it to them.
>>

>> >> Google, Apple, Microsoft push on W3C to implement DRM or any future of
>> >> web. It is time to decision to be with people or against them.
>> >> viva Mozilla.
>>

>> The EME decision standardizes the interface for using DRM. In practical
>> terms, it does not enable anything that was previously impossible.
>> Whether or not it will end up making DRM more or less prevalent is a
>> question of game theory, and can be legitimately argued. But it is an
>> oversimplification to assert that Mozilla implementing EME is equivalent
>> to Mozilla accepting or promoting DRM.
>>
>> If you look at the branches of the game theory tree where Mozilla
>> refuses EME, one possible branch leads to Firefox's market share
>> collapsing and DRM becoming more widespread. This would seriously damage
>> Mozilla's mission of improving the Web. It is not the only possible
>> outcome of refusing EME, and other possibilities have a better outcome.
>> But it is one we need to avoid, and simply saying that we will have
>> nothing to do with EME is dangerous.
>>
>> >> W3c is still alive during being reference for developer-
>> >>
>> > The web and also the w3c have been under attack consistently since
>> > inception, there's nothing really new here. I strongly believe that the
>> > scope is consistent with the principles.
>> >
>> > This is nothing at all to do with the w3c who are open to ideas.
>> >

>> > This simply a question of whether mozilla wants to back this new
>> > technology, and as a consequence wants to open or close their source.
>>

[Gian-Carlo Pascutto]

On 20/10/2013 17:22, Melvin Carvalho wrote:

>> Mozilla's mission does not absolutely require the browser to be open
>> source. Its current culture pretty much does.
>
> If Mozilla's mission does not guarantee the browser to be open source, how
> does that square with the Mozilla Foundation's pledge:
>
> [[
> Mozilla Foundation Pledge
>
> The Mozilla Foundation pledges to support the Mozilla Manifesto in its
> activities. Specifically, we will:
>
> build and enable open-source technologies and communities that support the
> Manifesto’s principles;
>
> ]]
>
> Does the mission trump the manifesto and pledge, or have I misunderstood?

The Manifesto and Pledge explain how Mozilla wants to accomplish that
mission and what we think the best way to do it is.

This does not imply it is the only possible way it could be done.

You could have a closed source browser and push the open web and web
standards. You can also have an open source browser and work against the
open web and in favor of walled gardens.

There exist or have existed competitors of Mozilla that fit either of
those examples.

--
GCP

[Henri Sivonen]

On Sat, Oct 19, 2013 at 9:34 PM, Reuben Morais <reuben...@gmail.com> wrote:
> During the Summit people mentioned one possibility is specifying the CDM

"The CDM" is not going to be specificied, at least not at the W3C in
the foreseeable future. One of the editors of EME recently said (and
has made the same point earlier, too): "A valid criticism is that EME
doesn't specify the whole system. I wish we could do that, but right
now I don't know how."
(http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0156.html)

More explicitly, the above means that there doesn't exist a DRM scheme
that's believed to both satisfy the requirements of major Hollywood
studios and be specifiable under the rules that W3C specifications are
subject to. So the result is multiple CDMs (IE on Windows 8.1 has one,
Chrome on Chrome OS has another) that have mutually incompatible key
acquisition message formats and that don't have specs that'd conform
to the W3C rules.

> in order to limit what it can do (eg. sandboxing the decryption process so it can't access the disk).

It is generally hard to get W3C specifications to require things that
are not testable from Web-exposed behavior. You can't tell from
JavaScript written to the EME API if the API is backed by a CDM that
is sandboxed or by a CDM that isn't. I mean tell from
functionality--not telling from cryptographic evidence plus
out-of-band info. You can't figure out tamper-resistance from
Web-exposed functionality, either, so that's handled by showing
cryptographic evidence of possession of key material and then the
server having out-of-band information about the tamper-resistance
characteristics of CDMs in possession of that key material. But that
part is out of the scope of what's being specced at the W3C, so that
part wouldn't appear in a W3C test suite anyway.

(There is precedent to W3C specs requiring things that aren't testable
Web-exposed behavior, though. An example is the SVG 1.1 spec saying:
"Graphics editing applications or file translation tools must not
attempt to convert SVG fonts into system fonts.")

However, access to persistent storage is semi-testable as Web-exposed
behavior. You can write a test that involves doing something, quitting
the browser and doing something again. If the later run of the test
can discover some piece of state that was left by the first run of the
test, then you have shown that the implementation has access to
persistent storage. There is a spec bug open about this, but I expect
it to be resolved to allow CDMs to have access to persistent storage,
since there exists a DRM vendor that appears to want to have that
capability.

In theory, at least, it would still be possible for access to
persistent storage to be browser-mediated. That is, a CDM could ask
the browser to remember encrypted blobs on its behalf instead of
having unlimited direct file system access. Theoretical possibility
does not necessarily lead to practice, though.

The EME spec doesn't even prohibit CDMs from doing networking even
though the whole point of the architecture implied by EME is that the
CDMs don't do networking towards the key server. CDMs might do
networking towards their vendor, though. From existing plug-in DRM
it's known that the version of Microsoft PlayReady inside Silverlight
downloads an individualization black box from Microsoft and the Adobe
Access DRM component inside Flash Player does likewise (from Adobe, of
course). See http://msdn.microsoft.com/en-us/library/cc838192%28v=vs.95%29.aspx#conceptual_overview
and page 3 of http://www.adobe.com/products/flashmediaserver/pdfs/flashaccess2_0_wp.pdf
. EME CDMs might do likewise without violating the EME architecture.
Again, theoretically this could be browser-mediated, but theory
doesn't necessarily lead to practice.

> My understanding is that Google is already shipping EME, and Microsoft is about to, so it sounds to me like time is running short for us to try and do something in this regard.

Google shipped way back in March though not on all platforms:
https://plus.google.com/+chrome/posts/GNsoSDLRRY6

Microsoft shipped last week. IE11 Test Drive links to
http://movies.netflix.com/ie11testdrive that pushes the message that
the demo works "without plug-ins" and is enabled by two extension
specs being developed at the W3C but doesn't say a word about the
involvement of the Microsoft-proprietary PlayReady component.

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

[Melvin Carvalho]

Thank you for the clarification. In truth few platforms are either 100%
open or 100% closed, but each system finds its own balance.

There was an interesting article that was #1 on HN yesterday, about how
openness can sometimes shift over time, as the market changes:

http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

I think a few observers, are interested to understand better the effects
that DRM may have on this balance, particularly with respect to firefox,
which is a tool I think we all use

Thanks again for the explanation.


>
> --
> GCP

[Trevor Saunders]

On Mon, Oct 21, 2013 at 11:37:52AM +0300, Henri Sivonen wrote:
> On Sat, Oct 19, 2013 at 9:34 PM, Reuben Morais <reuben...@gmail.com> wrote:
> > During the Summit people mentioned one possibility is specifying the CDM
>
> "The CDM" is not going to be specificied, at least not at the W3C in
> the foreseeable future. One of the editors of EME recently said (and
> has made the same point earlier, too): "A valid criticism is that EME
> doesn't specify the whole system. I wish we could do that, but right
> now I don't know how."
> (http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0156.html)

it would obviously be really nice if how the CDM worked was spec'd, but
to be no less bad than <object> it just has to be spec'd *somewhere*
(not the w3c would be just fine).

> More explicitly, the above means that there doesn't exist a DRM scheme
> that's believed to both satisfy the requirements of major Hollywood
> studios and be specifiable under the rules that W3C specifications are
> subject to. So the result is multiple CDMs (IE on Windows 8.1 has one,
> Chrome on Chrome OS has another) that have mutually incompatible key
> acquisition message formats and that don't have specs that'd conform
> to the W3C rules.

istr people argueing against pepper on the grounds it wasn't a specable
plugin API, so we'd look a bit hipocritical there if we decided to
implement a proprietery mozilla plugin API to implement EME.

So, if we replace NPAPI with an API to implement EME that allows access
to graphix networking and storage have we really much better than just
keeping NPAPI around with the only real world users being DRM?

It seems to me that implement a new plugin API just for EME would more
or less mean we'd be supporting the DRM system instead of just allowing
it to exist.

> > My understanding is that Google is already shipping EME, and Microsoft is about to, so it sounds to me like time is running short for us to try and do something in this regard.
>
> Google shipped way back in March though not on all platforms:
> https://plus.google.com/+chrome/posts/GNsoSDLRRY6

So, do we understand why Google is only shipping it on chrome OS? FOr
that matter what is Apple doing?

> Microsoft shipped last week. IE11 Test Drive links to
> http://movies.netflix.com/ie11testdrive that pushes the message that
> the demo works "without plug-ins" and is enabled by two extension
> specs being developed at the W3C but doesn't say a word about the
> involvement of the Microsoft-proprietary PlayReady component.

We should absolutely call BS on them only using open web technologies
then.

Trev

>
> --
> Henri Sivonen
> hsiv...@hsivonen.fi
> http://hsivonen.fi/

[Adam Roach]

On 10/21/13 09:58, Trevor Saunders wrote:
> For that matter what is Apple doing?

Apple is very tight-lipped in general. You might be able to draw some of
your own conclusions from the publicly available information on
webkit.org; e.g.:

https://bugs.webkit.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=&content=[eme]


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[Brendan Eich]

On Monday, October 21, 2013 7:58:52 AM UTC-7, Trevor Saunders wrote:
> it would obviously be really nice if how the CDM worked was spec'd, but
> to be no less bad than <object> it just has to be spec'd *somewhere*
> (not the w3c would be just fine).

roc called for an even lighter "spec": a registry of per-CDM doc-links:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944

Judge for yourself how well that went, and where it's likely to end up.

> > More explicitly, the above means that there doesn't exist a DRM scheme
> > that's believed to both satisfy the requirements of major Hollywood
> > studios and be specifiable under the rules that W3C specifications are
> > subject to. So the result is multiple CDMs (IE on Windows 8.1 has one,
> > Chrome on Chrome OS has another) that have mutually incompatible key
> > acquisition message formats and that don't have specs that'd conform
> > to the W3C rules.
>
> istr people argueing against pepper on the grounds it wasn't a specable
> plugin API, so we'd look a bit hipocritical there if we decided to
> implement a proprietery mozilla plugin API to implement EME.

There is no hypocrisy if we are forced to do something that we oppose -- but which is no different from today's plugins -- under market-power duress, where the alternative is likely fatal or debilitating enough that we will fail down the road.

You are right that given enough market pressure (say if Chrome took over enough share), we could be forced to reverse-engineer Pepper, just as once upon a time Netscape did NPAPI and briefly had enough market share that browsers after it faced a de-facto standard and had to reverse-engineer that API.

(One could say the same thing about JavaScript, BTW -- but I've paid my dues.)

Fortunately, that kind of imposed folly looks unlikely right now. See

http://trypepperjs.appspot.com/

Now compare to EME, which is ostensibly like the NPAPI if you ignore the CDM inside (think of Flash having a licensed codec blob that plugs in using a Flash-internal API). Some people still think EME is no worse than NPAPI on this basis (see e.g., http://chris.improbable.org/2013/10/4/dear-eff/ including dbaron's comment).

Only Chrome has Pepper, but IE, Chrome, and probably Safari (see Adam's link) are likely to have some kind of EME support, and Microsoft, Google, Netflix, and Google are prime movers of the EME effort. That is real market power.

So talking about hypocrisy is off target. Market-power moves that impose underspecified or closed subsystems on the Web, and which therefore go against open source browsers, new browsers, up-and-coming hardware vendors, have arisen and will continue to arise. We at Mozilla oppose such moves. Will we always win? No. See H.264, where Chrome never did as promised and dropped support in favor of VP8, and we threw in the towel rather than fail to compete on mobile.

Hypocrisy is practicing other than one preaches, and in a big way. In contrast, fighting the good fight, helping blaze good trails and ushing against bad paths in Web evolution, yet failing to win every time -- this is not hypocrisy.

Mozilla falling on our sword at the first failure does no good for our mission. Could the mission be corrupted over time? You bet, which is why we continue to fight, both for better ways and against worse ones including EME -- and Pepper. On the current conflict, we need to move the goal posts. I'm working on this still, see my blog post about watermarking not DRM:

https://brendaneich.com/2013/05/today-i-saw-the-future/

I will blog again, as soon as I can say more, with an update.

/be

[Brendan Eich]

On Monday, October 21, 2013 1:35:16 PM UTC-7, Brendan Eich wrote:
> Only Chrome has Pepper, but IE, Chrome, and probably Safari (see Adam's link) are likely to have some kind of EME support, and Microsoft, Google, Netflix, and Google

"and Hollywood", I meant to write.

> ...

>
> Hypocrisy is practicing other than one preaches, and in a big way. In contrast, fighting the good fight, helping blaze good trails and ushing

("pushing", of course.)

> against bad paths in Web evolution, yet failing to win every time -- this is not hypocrisy.

/be

[Aleksej]

On 2013-10-22 00:35, Brendan Eich wrote:
> H.264, where Chrome never did as promised and dropped support in
> favor of VP8, and we threw in the towel rather than fail to compete
> on mobile.

https://bugzilla.mozilla.org/show_bug.cgi?id=858163
Firefox Flicks and Vimeo…

[Karl Dubost]

Le 21 oct. 2013 à 16:35, Brendan Eich a écrit :
> Only Chrome has Pepper, but IE, Chrome, and probably Safari (see Adam's link) are likely to have some kind of EME support, and Microsoft, Google, Netflix, and Google are prime movers of the EME effort. That is real market power.

Yes and markets are regulated by… political powers. Technology can help carve new visions, new business models. But for limiting abuse, a society has to rely on political actions.

Unfortunately for now there is not that much will of getting rid of DRM, because most people just don't care (enough) and we all go see movies in theaters, on DVDs, on TVs, which are regulated and driven by the same kind of rules. Because we are just fine watching a movie once for most of us (in us I don't mean Mozilla community but people as large).

I dislike DRMs, quite a lot, but this is the technological tree hiding the society forest about copyright. I often drummed it: New business models will make DRMs vanish, new ways of making profit from content. In that I'm pretty sure Mozilla with partners can envisioned new avenues. But it will not be easy, nor necessary effective. And it is a very long term fight. EME is based on the short term of very specific industries.

btw Creative Commons, which stayed away for a while of talking about copyright reform has started.
http://creativecommons.org/weblog/entry/39639

Robin Berjon at W3C has also started a group for discussing ideas.
http://www.w3.org/community/web-copyright/
(but still no activity or discussions
http://lists.w3.org/Archives/Public/public-web-copyright/ )






--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Henri Sivonen]

On Mon, Oct 21, 2013 at 5:58 PM, Trevor Saunders
<trev.s...@gmail.com> wrote:
> On Mon, Oct 21, 2013 at 11:37:52AM +0300, Henri Sivonen wrote:
>> On Sat, Oct 19, 2013 at 9:34 PM, Reuben Morais <reuben...@gmail.com> wrote:
>> > During the Summit people mentioned one possibility is specifying the CDM
>>
>> "The CDM" is not going to be specificied, at least not at the W3C in
>> the foreseeable future. One of the editors of EME recently said (and
>> has made the same point earlier, too): "A valid criticism is that EME
>> doesn't specify the whole system. I wish we could do that, but right
>> now I don't know how."
>> (http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0156.html)
>

> it would obviously be really nice if how the CDM worked was spec'd, but
> to be no less bad than <object> it just has to be spec'd *somewhere*
> (not the w3c would be just fine).

If you consider the already shipped EME back ends, chances are that a
specification for PlayReady exists, but you are not allowed to read
it. It's possible to pay money to be able to read the source code
under NDA. I don't know if you also get to read a spec if you become
eligible to read the source code. Part of the PlayReady specs is
public, though: the Compliance Rules and the Robustness Rules
(https://www.microsoft.com/playready/licensing/compliance/). These are
fascinating. For example, the Robustness Rules have requirements that
chain to the concept of personal injury. ("Robustness" is DRM lingo
for the capacity of an implementation to resist attempts by the end
user to gain read or write access to data inside the DRM box.)

As for comparisons with <object>, technically EME CDMs don't need to
be worse than NPAPI plug-ins, but as noted in dbaron's comment that
Brendan pointed to, it is not a given that EME CDMs will have the same
licensing and distribution model as NPAPI plug-ins.

> So, if we replace NPAPI with an API to implement EME that allows access
> to graphix networking and storage have we really much better than just
> keeping NPAPI around with the only real world users being DRM?

EME CDMs are first and foremost replacements for the PlayReady
component inside Silverlight. Silverlight EOL has been announced and
there's about zero chance of NPAPI Silverlight becoming available to
operating systems other than Windows and OS X. Even if we decided to
keep NPAPI around for the long term, chances are that Silverlight
won't be available to plug into that API for the long term.

As for access to graphics, networking and storage, I think it would
make sense for browsers to sandbox CDMs and not give them unlimited
access to graphics, networking and storage. When I said that practice
doesn't necessarily follow theory, I wanted to avoid the appearance of
saying that everything is fine and there's nothing to worry about.

Specifically, the browser might not be in a position where it's
technically possible for the browser to be in charge of restricting
the CDM. For example, on ARM when the user is told that the kernel
that the device boots is Linux, what actually boots on the hardware
might be a hypervisor and Linux runs under the hypervisor. The
hypervisor then also runs another kernel that users don't hear about
and the non-Linux kernel runs a substantial part of the CDM and the
CDM visible to the browser is just an RPC stub that communicates with
the real CDM trough some kind of hypervisor wormhole. So there are
scenarios where the browser might not be in a position to restrict the
CDM because even the kernel that the browser sees isn't in that
position. In that sort of arrangement, *I* think it would make a lot
of sense for the hypervisor to deny the second operating system access
to the network and access to persistent storage, but if you aren't the
one controlling the hypervisor, you don't get to make the rules.

> It seems to me that implement a new plugin API just for EME would more
> or less mean we'd be supporting the DRM system instead of just allowing
> it to exist.

This line of thinking is similar to the line of thinking that SCOTUS
adopted in the Betamax case: a special-purpose thing that has only
infringing uses is less acceptable than a general-purpose thing that
has those infringing uses but also substantial non-infringing uses. An
API for EME CDMs only has DRM uses and at the time the NPAPI was
introduced, the NPAPI have substantial non-DRM uses, so the NPAPI
seems more acceptable than a CDM-specific API. However, when in
practice the non-DRM uses of the NPAPI fade away, I don't see why it
would be substantially better in practice to support the NPAPI than to
support CDM-oriented API surface.

>> > My understanding is that Google is already shipping EME, and Microsoft is about to, so it sounds to me like time is running short for us to try and do something in this regard.
>>
>> Google shipped way back in March though not on all platforms:
>> https://plus.google.com/+chrome/posts/GNsoSDLRRY6
>
> So, do we understand why Google is only shipping it on chrome OS? FOr

> that matter what is Apple doing?

I think it's best not to speculate about competitors in public.

[David Bruant]

Le 22/10/2013 12:08, Karl Dubost a écrit :
> Le 21 oct. 2013 à 16:35, Brendan Eich a écrit :

>> Only Chrome has Pepper, but IE, Chrome, and probably Safari (see Adam's link) are likely to have some kind of EME support, and Microsoft, Google, Netflix, and Google are prime movers of the EME effort. That is real market power.

> Yes and markets are regulated by… political powers.

Agreed, but this is on a different time scale.
Do you know of a way for political power to operate within the next,
say, 2 years on this topic?
Something that would, for instance, legally force either Netflix to
deliver its content without DRM or Microsoft and Google to ship a
browser without CDMs? (again in the near term)
I haven't heard of any yet unfortunately.

Based on what I've read on this list so far, I feel Mozilla is focused
on positioning themselves in the near term (and the near term is a
moving target too). Encouraging content providers to use alternatives
like watermarking is one encouraging option.

I imagine we all roughly agree on what needs to happen in the long term.

David

[Karl Dubost]

David,

Le 22 oct. 2013 à 08:08, David Bruant a écrit :
> Le 22/10/2013 12:08, Karl Dubost a écrit :
>> Yes and markets are regulated by… political powers.
> Agreed, but this is on a different time scale.

yes. what I said in ;)

>> And it is a very long term fight. EME is based on the short term of very specific industries.

[…]

> I imagine we all roughly agree on what needs to happen in the long term.

It depends on who you put in the « we »
If you are talking about Mozilla core community, I guess it is a safe bet. If you are talking about Mozilla users, it's becoming already less true.
And if you are talking about the society, it's far off. :)

Mozilla products are not anymore products only used by a tight community of people who wants to achieve something different. It is just used by people without specific goals for the Web. And it's fine.

When Mozilla made a pledge to create a good browser for giving a different choice to users. It was

1. helping the users
2. increasing the needs for an interoperable Web (so being open)
3. maybe threatening others market shares

Here it is a more difficult case, if the stance is about not supporting EME and/or some form of DRMed content—let say by principles, convictions, etc—Mozilla is basically not really helping users, maybe fragmenting an interoperable Web, and threatening its own market share. I'm not happy about that. That's really a cornelian choice, and not an easy one.

Posts like https://brendaneich.com/2013/05/today-i-saw-the-future/ are a good step in moving forward.

[Trevor Saunders]

On Tue, Oct 22, 2013 at 01:23:16PM +0300, Henri Sivonen wrote:
> On Mon, Oct 21, 2013 at 5:58 PM, Trevor Saunders
> <trev.s...@gmail.com> wrote:
> > On Mon, Oct 21, 2013 at 11:37:52AM +0300, Henri Sivonen wrote:
> >> On Sat, Oct 19, 2013 at 9:34 PM, Reuben Morais <reuben...@gmail.com> wrote:
> >> > During the Summit people mentioned one possibility is specifying the CDM
> >>
> >> "The CDM" is not going to be specificied, at least not at the W3C in
> >> the foreseeable future. One of the editors of EME recently said (and
> >> has made the same point earlier, too): "A valid criticism is that EME
> >> doesn't specify the whole system. I wish we could do that, but right
> >> now I don't know how."
> >> (http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0156.html)
> >
> > it would obviously be really nice if how the CDM worked was spec'd, but
> > to be no less bad than <object> it just has to be spec'd *somewhere*
> > (not the w3c would be just fine).
>
> If you consider the already shipped EME back ends, chances are that a
> specification for PlayReady exists, but you are not allowed to read
> it. It's possible to pay money to be able to read the source code
> under NDA. I don't know if you also get to read a spec if you become
> eligible to read the source code. Part of the PlayReady specs is
> public, though: the Compliance Rules and the Robustness Rules
> (https://www.microsoft.com/playready/licensing/compliance/). These are
> fascinating. For example, the Robustness Rules have requirements that

rage enducing (what part of this isn't? ;) but yes

> As for comparisons with <object>, technically EME CDMs don't need to
> be worse than NPAPI plug-ins, but as noted in dbaron's comment that
> Brendan pointed to, it is not a given that EME CDMs will have the same
> licensing and distribution model as NPAPI plug-ins.

Since I'm pretty sure you could implement EME with a js wrapper around
<object> that would seem to be trivially true.

> > So, if we replace NPAPI with an API to implement EME that allows access
> > to graphix networking and storage have we really much better than just
> > keeping NPAPI around with the only real world users being DRM?
>
> EME CDMs are first and foremost replacements for the PlayReady
> component inside Silverlight. Silverlight EOL has been announced and
> there's about zero chance of NPAPI Silverlight becoming available to
> operating systems other than Windows and OS X. Even if we decided to

Sure, though we seem to have survived so far with that being the case.
This ignores people running Silverlight in wine (although I have no
clue why you'd go that far out of your way to deal with DRM).

> keep NPAPI around for the long term, chances are that Silverlight
> won't be available to plug into that API for the long term.

sure, but if you assume we can find someone willing to write a CDM for a
new plugin API we come up with then you'd think we could get them to
make the plugin wrapper around that CDM be NPAPI.

> As for access to graphics, networking and storage, I think it would
> make sense for browsers to sandbox CDMs and not give them unlimited
> access to graphics, networking and storage. When I said that practice

In the sense its better to break someones arm once than twice I'd
expect we all agree.

> doesn't necessarily follow theory, I wanted to avoid the appearance of
> saying that everything is fine and there's nothing to worry about.

I was really hoping killing plugins would give us enough leverage to kill
DRM, but being clear about what the risks are exactly is good.

> Specifically, the browser might not be in a position where it's
> technically possible for the browser to be in charge of restricting
> the CDM. For example, on ARM when the user is told that the kernel
> that the device boots is Linux, what actually boots on the hardware
> might be a hypervisor and Linux runs under the hypervisor. The
> hypervisor then also runs another kernel that users don't hear about
> and the non-Linux kernel runs a substantial part of the CDM and the
> CDM visible to the browser is just an RPC stub that communicates with
> the real CDM trough some kind of hypervisor wormhole. So there are
> scenarios where the browser might not be in a position to restrict the
> CDM because even the kernel that the browser sees isn't in that

sure, if the user shouldn't trust the stack under the browser we're
pretty screwed in all sorts of ways and that's just one.

> > It seems to me that implement a new plugin API just for EME would more
> > or less mean we'd be supporting the DRM system instead of just allowing
> > it to exist.
>
> This line of thinking is similar to the line of thinking that SCOTUS
> adopted in the Betamax case: a special-purpose thing that has only
> infringing uses is less acceptable than a general-purpose thing that
> has those infringing uses but also substantial non-infringing uses. An
> API for EME CDMs only has DRM uses and at the time the NPAPI was
> introduced, the NPAPI have substantial non-DRM uses, so the NPAPI
> seems more acceptable than a CDM-specific API. However, when in

in fact I'd say its exactly that where DRM is infringing users rights.

> practice the non-DRM uses of the NPAPI fade away, I don't see why it
> would be substantially better in practice to support the NPAPI than to
> support CDM-oriented API surface.

can we really be confident nobody will come up with good uses for
generic plugins in the future?

I admit its not a technical argument, but I'd atleast feel better about
what I'm doing if we leave the door to useful things open.

> >> > My understanding is that Google is already shipping EME, and Microsoft is about to, so it sounds to me like time is running short for us to try and do something in this regard.
> >>
> >> Google shipped way back in March though not on all platforms:
> >> https://plus.google.com/+chrome/posts/GNsoSDLRRY6
> >
> > So, do we understand why Google is only shipping it on chrome OS? FOr
> > that matter what is Apple doing?
>
> I think it's best not to speculate about competitors in public.

Well, it at least should be done when being very clear we're only
discussing public information as our selves with no relation to
employers etc. So right now I'm not going to say more than the list of
webkit bugs that was linked was interesting and kind of confusing.

Trev

[Brendan Eich]

On Tuesday, October 22, 2013 3:08:15 AM UTC-7, Karl Dubost wrote:
> Le 21 oct. 2013 à 16:35, Brendan Eich a écrit :
>

> > Only Chrome has Pepper, but IE, Chrome, and probably Safari (see Adam's link) are likely to have some kind of EME support, and Microsoft, Google, Netflix, and [Hollywood] are prime movers of the EME effort. That is real market power.

>
>
> Yes and markets are regulated by… political powers. Technology can help carve new visions, new business models. But for limiting abuse, a society has to rely on political actions.

Lotsa luck to us. Too many people do not care. On top of that, money buys politicians at million-x leverage (ex-Cong. Jefferson case, $90K bribe in freezer). Regulators get captured all the time. Hollywood has the money, and who has the money has the power ("The Lookout", neat little Indie-US neo-noir).

None of this is an excuse for the W3C selling its soul, of course.

/be

[Brendan Eich]

This dev.planning thread has much more detail (appreciated, thanks to all), but I finally blogged:

https://brendaneich.com/2013/10/the-bridge-of-khazad-drm/

Hope it helps.

/be