Re: W3C declares DRM in scope for HTML

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

yajo.sk8
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

bytehead
On Tuesday, February 12, 2013 2:38:16 PM UTC-5, [hidden email] 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.  
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Gijs Kruitbosch ("Hannibal")
On 14/10/13 18:55 , [hidden email] wrote:
> On Tuesday, February 12, 2013 2:38:16 PM UTC-5, [hidden email] 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.
>

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

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.

----- Original Message -----
From: "Gijs Kruitbosch" <[hidden email]>
To: [hidden email]
Sent: Monday, October 14, 2013 10:07:10 AM
Subject: Re: W3C declares DRM in scope for HTML

On 14/10/13 18:55 , [hidden email] wrote:
> On Tuesday, February 12, 2013 2:38:16 PM UTC-5, [hidden email] 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.
>

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Brendan Eich-4
In reply to this post by Gijs Kruitbosch ("Hannibal")
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

andrew
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Florian Bösch
In reply to this post by Brendan Eich-4
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

David Bruant-5
Le 17/10/2013 15:00, [hidden email] 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Florian Bösch
In reply to this post by Florian Bösch
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Allen Wirfs-Brock-3

On Oct 17, 2013, at 8:14 AM, [hidden email] 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Florian Bösch
In reply to this post by Florian Bösch
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Allen Wirfs-Brock-3

On Oct 17, 2013, at 8:37 AM, [hidden email] 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


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

David Bruant-5
In reply to this post by Florian Bösch
Le 17/10/2013 17:14, [hidden email] 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Zack Weinberg-2
In reply to this post by Florian Bösch
On 2013-10-17 12:30 PM, David Bruant wrote:

> Le 17/10/2013 17:14, [hidden email] 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

semnanweb
In reply to this post by yajo.sk8
On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30, [hidden email] 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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Melvin Carvalho
On 19 October 2013 00:42, <[hidden email]> wrote:

> On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30, [hidden email]:
> > 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.
>

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.


> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Steve Fink-4
On 10/18/2013 05:54 PM, Melvin Carvalho wrote:

> On 19 October 2013 00:42, <[hidden email]> wrote:
>
>> On Tuesday, February 12, 2013 11:08:16 PM UTC+3:30, [hidden email]:
>>> 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.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Boris Zbarsky
In reply to this post by Melvin Carvalho
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

reuben.morais (Bugzilla)
Say we all agree on the "Netflix is the doom of Firefox" thing, and decide we have to implement EME to remain competitive. What can we do to limit the scope of the technology to the use cases we think are more or less aligned with the Web? During the Summit people mentioned one possibility is specifying the CDM in order to limit what it can do (eg. sandboxing the decryption process so it can't access the disk). Are we talking with the W3C or Netflix about this? 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.

-- reuben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: W3C declares DRM in scope for HTML

Steve Wendt
In reply to this post by Melvin Carvalho
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/

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12