Hi,

I've just found these two articles with the announcement:

https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/
https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/

And since I can't find where the discussion about this took place, I
would like to open discussion here.

I'm still shocked and don't understand what's going on:

  * It's not the first time we take decisions because everyone else is
    doing it, and we want to keep being relevant.
      o This worries me the most looking at the future, since we are
        going to be always the only ones with completely different
        values to the rest of the players in the browser ecosystem.
      o Have we lost hope to be enough relevant to avoid these situations?
  * We want to get rid of plugins but we implement something that always
    depends on an external and proprietary module.
      o It won't be impossible to access the full web using open source
        bits, since if we also agree on this, even people not using DRM
        right now are going to switch to it eventually.

Regards.

--
Rubén Martín [Nukeador]
Mozilla Reps Mentor
http://www.mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

On 14/05/2014 19:10, Rub�n Mart�n wrote:
> Hi,
>
> I've just found these two articles with the announcement:
>
> https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/
> https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
>
> And since I can't find where the discussion about this took place, I
> would like to open discussion here.

There was a town hall about this earlier today. Did the invite not reach
you? A lot of this was already discussed.

> I'm still shocked and don't understand what's going on:
>
>    * It's not the first time we take decisions because everyone else is
>      doing it, and we want to keep being relevant.

I wouldn't say "because everyone else is doing it", but I agree with the
need for our being relevant motivating this decision.

>        o This worries me the most looking at the future,  we are

>          going to be always the only ones with completely different
>          values to the rest of the players in the browser ecosystem.

I don't agree with this. Here is why:
- When it comes to the values that dictate the space here, this isn't
about the browser ecosystem, it's about "big content". Very few people
there have our values at all. Very few people understand the technical
details. We're not in that space ourselves. There's a big difference
with some of the other questions we face when it comes to influence.
- My impression has been that many of the other implementers that work
with us on various standards bodies to a certain degree share our view
on the web, even if their employers at large might not. The tiny bits of
the discussions on EME that I did read at the time also reflected this.
- Besides that, I don't think we should say it's "always" us going to be
the "only" ones. :-)

>        o Have we lost hope to be enough relevant to avoid these situations?

No, but this particular ship has sailed in terms of what is implemented
in other browsers. Our choices were (1) implement, or (2) don't
implement. There wasn't a realistic (3) argue about ways and means and
how this isn't right.

>    * We want to get rid of plugins but we implement something that always
>      depends on an external and proprietary module.
>        o It won't be impossible to access the full web using open source

Double negatives? I guess you mean it won't be possible? (I will also
note that as much as possible of this implementation *is* open source -
but the CDM itself never can be, because of the content industry
dictating the requirements there)

>          bits, since if we also agree on this, even people not using DRM
>          right now are going to switch to it eventually.

This assumes a slippery slope which I don't think is fair. We will
continue to push for alternative and better solutions. If those are more
compelling than DRM, I don't think "they" (who, who aren't already using
it?) will necessarily switch to DRM "eventually".

During the town hall it was also noted how we have good hope that
discussions about the other slippery-sloping, namely to DRM-ify more
than video/audio, will be more discussions than "do or die" decisions
like this one, and we will have more of a fighting chance to have our
way there.

Gijs

On Wed, May 14, 2014 at 8:57 PM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> There was a town hall about this earlier today. Did the invite not reach
> you? A lot of this was already discussed.

I only received an email from Brian King ~3h ago, via Reps-General.
IIRC there was no Mozillians-wide email.

Cheers,

Dirkjan

Rub�n, thank you for starting this thread.

As a caveat, what follows are all my personal opinions, not official
Mozilla anything.

First off, I'd like to say that I don't know anyone in the Mozilla
project who is happy that we're ending up in a place where we feel like
we have to do this to stay relevant.  One of the explicit reasons Henri
(who did most of the legwork on this issue) got involved in it was his
opposition to DRM on the web, which you can see in his posts on the W3C
mailing lists.  When he realized that preventing EME from happening was
not viable, he focused on limiting the damage as much as possible.  I do
think, personally, that what we're doing here is the best way we have to
advance our mission, given the circumstances.  And you can see my own
posts to the W3C lists for my personal views on DRM.

Second, there was in fact a good reason for the lack of previous public
discussion on this.  There were a lot of delicate negotiations with
various DRM vendors involved to get to the state where are now (e.g.
being able to sandbox the CDM).  Part of our negotiating leverage in
those discussions was the DRM vendors not knowing whether we were going
to do EME at all, and hence not knowing whether we would simply walk
away if their requirements were too onerous.  I believe that in fact we
would have done that, by the way.  Unfortunately, having a public
discussion on whether we'd be willing to implement EME and under what
circumstances would have removed a lot of that negotiating leverage.

On 5/14/14, 11:10 AM, Rub�n Mart�n wrote:
>        o This worries me the most looking at the future, since we are
>          going to be always the only ones with completely different
>          values to the rest of the players in the browser ecosystem.

Yes, this is a serious worry for all of us, I think.  :(  This also came
up with the H.264 situation, and we can probably expect other such
situations to come up in the future.  We should try to address them
proactively before they get to the point where we feel like we have no
choices.

In both this case and the H.264 case we've tried to do things as much in
line with our values as we can (e.g. by providing ways for downstream
redistributors of Firefox to provide the same functionality the
mozilla.org builds do), but that's small consolation...

>        o Have we lost hope to be enough relevant to avoid these situations?

I don't think we have, but there's a lot of work to be done to make sure
we stay relevant.

Note that we do feel we're relevant enough to do the DRM thing in a way
that is quite different from our competitors in various ways:

   * Not shipping it by default.
   * Requiring explicit user content before downloading the CDM.
   * Insisting on a CDM that is sandboxed so it can't do things that
     we don't allow it to do: no phoning home, no persistent user
     tracking, etc.
   * Working to make it possible for others to support the
     functionality while still compiling their own Firefox.  Builds
     provided by Linux distributions are the obvious target here.

I also think we are relevant enough to keep working on making DRM less
relevant in the future (e.g. by pushing forward watermarking as an
alternative), and will do so.

>    * We want to get rid of plugins but we implement something that always
>      depends on an external and proprietary module.

Indeed.  This module is a bit less user-hostile than current plug-ins,
due to the sandboxing, but is fundamentally not all that different in
terms of things like access to source, say.

That said, I think different people want to get rid of plug-ins for
different reasons, and the sandboxing does address some of those reasons
(stability issues, user privacy issues, etc)...

>        o It won't be impossible to access the full web using open source
>          bits, since if we also agree on this, even people not using DRM
>          right now are going to switch to it eventually.

I'm not sure whether your worry here about 1) users who are not using a
DRM-enabled UA switching to one that does, 2) video providers who are
not using DRM now starting to use it, or 3) non-video content starting
to use DRM.

I think in practice for #1 users are currently using DRM in the form of
Flash pretty much across the board.  For #2 this is a serious worry, but
I suspect that if it happens it would have happened even if we did not
ship EME.  Our response to that should continue to be working on
technical alternatives that make people less likely to feel like they
have to use DRM.

For #3, I think market realities are very different for other sorts of
content than they are for video, and we will continue to oppose DRM for
those situations.  In particular, I think we have more time to develop
alternatives to DRM before DRM becomes entrenched there.

I hope all of that helps your state of mind at least a little.

-Boris

That's not what I expected, sorry for the broken assumptions on my part.
CC'ing Mardi. I would have expected us to invite all mozillians (sadly,
for unrelated reasons, I changed my mozillians email to my moco address,
so it's hard for me to distinguish different types of town halls -
didn't think there were any, really! - and the email didn't make it
explicit who was/wasn't invited).

Mardi: can you (or someone else) explain why the invite was so limited?

~ Gijs

El 14/05/14 20:57, Gijs Kruitbosch escribió:

> There was a town hall about this earlier today. Did the invite not
> reach you? A lot of this was already discussed.

It seems that email didn't reach a lot of people, I'll have to watch the
Town Hall recording.

>>    * We want to get rid of plugins but we implement something that
>> always
>>      depends on an external and proprietary module.

>>        o It won't be impossible to access the full web using open source
>

> Double negatives? I guess you mean it won't be possible? (I will also
> note that as much as possible of this implementation *is* open source
> - but the CDM itself never can be, because of the content industry
> dictating the requirements there)

Yes, my bad, "It won't be possible".

>
>>          bits, since if we also agree on this, even people not using DRM
>>          right now are going to switch to it eventually.
>

> This assumes a slippery slope which I don't think is fair. We will
> continue to push for alternative and better solutions. If those are
> more compelling than DRM, I don't think "they" (who, who aren't
> already using it?) will necessarily switch to DRM "eventually".

My main fear is that now that Mozilla implements a way to work with DRM,
it would be more common for sites to use it since every browser supports
it, instead of exploring other ways as watermarking.

Probably it was me, but the article wording was too complex and didn't
summarize what Boris wrote:
  * Not shipping it by default (the CDM module).

  * Requiring explicit user content before downloading the CDM.
  * Insisting on a CDM that is sandboxed so it can't do things that we
don't allow it to do: no phoning home, no persistent user tracking, etc.
  * Working to make it possible for others to support the functionality
while still compiling their own Firefox. Builds provided by Linux
distributions are the obvious target here.

Press is going to write about "Mozilla implementing DRM" which based of
what I've learnt from your responses is not accurate, since right now we
are allowing DRM via plugins.

On Wed, May 14, 2014 at 10:37 PM, Rubén Martín
<nuke...@mozilla-hispano.org> wrote:
> Probably it was me, but the article wording was too complex and didn't
> summarize what Boris wrote:
>   * Not shipping it by default (the CDM module).
>   * Requiring explicit user content before downloading the CDM.
>   * Insisting on a CDM that is sandboxed so it can't do things that we
> don't allow it to do: no phoning home, no persistent user tracking, etc.

I completely agree that it would have been valuable to highlight these
things in the blog post.

Cheers,

Dirkjan

On Wed, May 14, 2014 at 11:37 PM, Rubén Martín
<nuke...@mozilla-hispano.org> wrote:
> My main fear is that now that Mozilla implements a way to work with DRM,
> it would be more common for sites to use it since every browser supports
> it, instead of exploring other ways as watermarking.

Different browsers support different DRMs with EME. As of today, 4
different EME-compatible DRMs are known: a different one for each
major browser. Paying for the licenses and operation of four different
DRM servers seems like an endeavor that sites would not embark on just
because things are available. Rather, it seems more likely that
deployment will be driven by business requirements from suppliers
(studios or record labels; yes, *subscription* music still comes under
DRM). But still, indeed, it is possible that EME-style DRM ends up
increasing the use of DRM compared to NPAPI-style DRM. We don't know
yet.

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

On 5/14/14, 1:37 PM, Rub�n Mart�n wrote:
> Probably it was me, but the article wording was too complex and didn't
> summarize what Boris wrote:
>    * Not shipping it by default (the CDM module).
>    * Requiring explicit user content before downloading the CDM.
>    * Insisting on a CDM that is sandboxed so it can't do things that we
> don't allow it to do: no phoning home, no persistent user tracking, etc.
>    * Working to make it possible for others to support the functionality
> while still compiling their own Firefox. Builds provided by Linux
> distributions are the obvious target here.

Ah, indeed.  http://andreasgal.com/2014/05/14/eme/ is a lot more clear
on the mechanics here...

-Boris

On my point of view, it's important to stay open.
But Mozilla have right, if you we don't implement this, Firefox part on
web browser will decrease.

Maybe we can find a solution between the current proposal and no drm.
If you propose DRM implementation by a add-ons, a special add-ons open
source with the sandbox.Easy to install, like a message that will show
when a page use DRM.

With that we will keep Firefox open, and DRM implementation, private
part is a chose for users.

dattaz

There are a few interesting articles about this topic:

https://www.eff.org/deeplinks/2014/05/mozilla-and-drm
http://www.theguardian.com/technology/2014/may/14/firefox-closed-source-drm-video-browser-cory-doctorow

Quoting The Guardian article:
> When a charitable nonprofit like Mozilla makes a shift as substantial
> as this one -- installing closed-source software designed to treat
> computer users as untrusted adversaries -- you'd expect there to be a
> data-driven research story behind it, meticulously documenting the
> proposition that without DRM irrelevance is inevitable. The large
> number of bytes being shifted by Netflix is a poor proxy for that
> detailed picture.*
> *

I think this is a very interesting point, have we done this research
(globally, not just the US)?

Hi,

caveat these are my personal opinions and only that.

On Thu, May 15, 2014 at 01:11:39AM +0200, Rubén Martín wrote:
> There are a few interesting articles about this topic:
>
> https://www.eff.org/deeplinks/2014/05/mozilla-and-drm

Personally I think there's a lot to be said for the EFF's position here,
and they put it far better than I ever could.  Personally I'd love to
enlist Mozilla into beeting content providers into dropping DRm
requirements, but I also remember Michel saying on an unrelated subject
that there was some social causes she love to do the same thing with,
but doesn't because its not what Mozilla is for.  I think her argument
has some validity here.

> http://www.theguardian.com/technology/2014/may/14/firefox-closed-source-drm-video-browser-cory-doctorow
>
> Quoting The Guardian article:
> > When a charitable nonprofit like Mozilla makes a shift as substantial
> > as this one -- installing closed-source software designed to treat
> > computer users as untrusted adversaries -- you'd expect there to be a
> > data-driven research story behind it, meticulously documenting the
> > proposition that without DRM irrelevance is inevitable. The large
> > number of bytes being shifted by Netflix is a poor proxy for that
> > detailed picture.*

its really hard to object to there being more data on exactly what
people do.

> I think this is a very interesting point, have we done this research
> (globally, not just the US)?

Even if its just the U.S. I think we'd still have a very serious problem
on our hands.  I personally believe its important to get people to
refuse to use Netflixx or equivelents until they stop requiring DRM, but
I also find that to be a hard discussion to start with people especially
non tech friends.

Trev

>
> Regards.
>
> --
> Rubén Martín [Nukeador]
> Mozilla Reps Mentor
> http://www.mozilla-hispano.org
> http://twitter.com/mozilla_hispano
> http://facebook.com/mozillahispano
>

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance

On 2014-05-14 21:46, Boris Zbarsky wrote:
...

> Second, there was in fact a good reason for the lack of previous
> public discussion on this.  There were a lot of delicate negotiations
> with various DRM vendors involved to get to the state where are now
> (e.g. being able to sandbox the CDM).  Part of our negotiating
> leverage in those discussions was the DRM vendors not knowing whether
> we were going to do EME at all, and hence not knowing whether we would
> simply walk away if their requirements were too onerous.  I believe
> that in fact we would have done that, by the way.  Unfortunately,
> having a public discussion on whether we'd be willing to implement EME
> and under what circumstances would have removed a lot of that
> negotiating leverage.

What exactly has been negotiated?

A sandboxed CDM that delivers the decrypted content back to the web
browser does not sound like strong DRM.

Have Netflix got agreement to support such a weak CDM for HD content?  
What about other distributors? Is Mozilla's EME implementation even
viable?

In what context does the sandbox run, and in what context does the CDM
run?

If the CDM and sandbox run as a user process on the CPU on Linux then
how does this offer any content protection?

Have the content owners and DRM vendors really given up so much?

The EME DRM proponents rejected sandboxing at the W3C discussions. Has
anything changed?

Is the code available yet?

Without knowing such details we can not judge this development.

Jim

On 5/14/14, 8:23 PM, Jim wrote:
> What exactly has been negotiated?

Some obvious bits that jumped out at me:

* The CDM not having unmediated access to the network, the hard drive,
or any other part of the user's computer.

* The CDM being available on Linux.

* The CDM not being able to track users across sites.

> Have Netflix got agreement to support such a weak CDM for HD content?
> What about other distributors? Is Mozilla's EME implementation even viable?

I personally do not know the answers to these questions, nor your
questions about content owners.

> The EME DRM proponents rejected sandboxing at the W3C discussions. Has
> anything changed?

I haven't been following the EME spec very closely, so I'm not sure what
sandboxing was rejected...  The spec _is_ written in a way that
technically allows the CDM to be sandboxed and rely on the browser for
getting the data.

> Is the code available yet?

I haven't seen any code yet.

-Boris

On Wed, May 14, 2014 at 11:10 AM, Rubén Martín
<nuke...@mozilla-hispano.org> wrote:
>   * It's not the first time we take decisions because everyone else is
>     doing it, and we want to keep being relevant.

>       o This worries me the most looking at the future, since we are
>         going to be always the only ones with completely different
>         values to the rest of the players in the browser ecosystem.

>       o Have we lost hope to be enough relevant to avoid these situations?

It's not a question of absolutes. We don't have anywhere near as much
marketshare that we can call all the shots all the time. But that
doesn't mean that we don't have any influence.

But there was a lot of pressure on the various actors here. And sadly
we don't have enough influence to prevent the badness in this
situation. And we didn't receive enough help from the larger internet
community.

Where was the internet outrage when Microsoft and Google implemented
this in their browsers? Where was the outrage towards Hollywood
studios asked for this? The fact that people at large simply let them
get away with this silently is ultimately what is forcing our hand
here.

This is not that different from that we were ultimately forced to ship
h264 due to the very developers that we were trying to protect were
the ones that yelled at us for going our own way.

We can't do everything ourselves. As much as I wish that wasn't the case.

And remember, just like with the video codec issue, just because we
lost in this instance doesn't mean that we've given up. We haven't yet
gotten all browsers to follow standards all the time, and all
developers to write user friendly websites all the time. But we
continue to make improvements.

However as someone working with other browser vendors on a very
regular basis, I can definitely say that we do have enough marketshare
that we have a lot of influence. We are definitely able to make the
web a better place on a very regular basis. As an example, just the
other day we were able to negotiate a more standardized approach to
push notifications where other browser vendors were happy to do
proprietary solutions. This would not have been possible without the
influence that we have, and the hard work we put in.

The decision today is an improvement over the NPAPI-based DRM
solutions that currently exist. We will continue to work on making the
next iteration better yet. Hopefully we will one day manage to rid the
web of DRM completely.

>   * We want to get rid of plugins but we implement something that always
>     depends on an external and proprietary module.
>       o It won't be impossible to access the full web using open source

>         bits, since if we also agree on this, even people not using DRM
>         right now are going to switch to it eventually.

DRM is inherently incompatible with open source unfortunately. Not
just on a philosophical level, but also technically. I'll let others
comment here as I don't know enough details.

/ Jonas

On 2014-05-15 10:07, Boris Zbarsky wrote:
> On 5/14/14, 8:23 PM, Jim wrote:
>> What exactly has been negotiated?
>
> Some obvious bits that jumped out at me:
>
> * The CDM not having unmediated access to the network, the hard drive,
> or any other part of the user's computer.
>
> * The CDM being available on Linux.
>
> * The CDM not being able to track users across sites.

How does it meet the demands by content owners for robust DRM, while
allowing the user to sandbox the CDM, and also not being tivoized which
is not an option on Linux?

>> Have Netflix got agreement to support such a weak CDM for HD content?
>> What about other distributors? Is Mozilla's EME implementation even
>> viable?
>
> I personally do not know the answers to these questions, nor your
> questions about content owners.

The basis for Mozilla's decision, that "Mozilla has little choice but to
implement EME as well so our users can continue to access all content
they want to enjoy." is baseless if Netflix and other popular
distributors do not support the proposed sandboxed Adobe CDM. Can
someone clarify this point?

>> The EME DRM proponents rejected sandboxing at the W3C discussions. Has
>> anything changed?
>
> I haven't been following the EME spec very closely, so I'm not sure
> what sandboxing was rejected...  The spec _is_ written in a way that
> technically allows the CDM to be sandboxed and rely on the browser for
> getting the data.

Sure, the EME keeps the details of the CDM and such sandboxing outside
its scope, an intentional decision by the W3C working group. Sandboxing
was raised.

Jim

On 2014-05-15 11:38, Jonas Sicking wrote:
> On Wed, May 14, 2014 at 11:10 AM, Rubén Martín
> <nuke...@mozilla-hispano.org> wrote:
>>   * It's not the first time we take decisions because everyone else is
>>     doing it, and we want to keep being relevant.
>>       o This worries me the most looking at the future, since we are
>>         going to be always the only ones with completely different
>>         values to the rest of the players in the browser ecosystem.
>>       o Have we lost hope to be enough relevant to avoid these
>> situations?
>
> It's not a question of absolutes. We don't have anywhere near as much
> marketshare that we can call all the shots all the time. But that
> doesn't mean that we don't have any influence.
>
> But there was a lot of pressure on the various actors here. And sadly
> we don't have enough influence to prevent the badness in this
> situation. And we didn't receive enough help from the larger internet
> community.

The community received no support from Mozilla. Mozilla have supported
the W3C and the EME all the way, and are still a member of the W3C. Even
when W3C employees started joking about assassinating EME dissenters
Mozilla was silent. Mozilla have a representative on the W3C TAG and the
TAG produced a draft document on the EME that is a complete joke, just
ask Henri. Mozilla has made no formal objection to the EME at the W3C.

Mozilla sold out for fear of losing market share. You didn't even try to
make a case to users to stick with Firefox if they were forced to use an
alternative browser to view some media content. Windows users already
have IE installed and you could have just deferred to IE for content
requiring EME - users have already chosen to use Firefox over IE so see
value in Firefox. There was a proposal made at the W3C that would have
further mitigated concerns of losing market share but Mozilla was not
interested.

You might all be surprised that the EME is not even about DRM, it's
purpose is to lock users into using proprietary web based media players.
The EME is just a JS API, it is not a media decoder and can not play
content without proprietary JS downloaded from the content distributors
website. Mozilla understood this and insisted on this design.

> Where was the internet outrage when Microsoft and Google implemented
> this in their browsers? Where was the outrage towards Hollywood
> studios asked for this? The fact that people at large simply let them
> get away with this silently is ultimately what is forcing our hand
> here.

The average web user might not understand how evil this decision is.

> This is not that different from that we were ultimately forced to ship
> h264 due to the very developers that we were trying to protect were
> the ones that yelled at us for going our own way.

It's very different. Mozilla has sold out yet again, and this time in a
very big way. Who's going to explain to those children what you have
done?

> We can't do everything ourselves. As much as I wish that wasn't the
> case.

Selling out on users control over their own computer is not the right
decision.

> And remember, just like with the video codec issue, just because we
> lost in this instance doesn't mean that we've given up. We haven't yet
> gotten all browsers to follow standards all the time, and all
> developers to write user friendly websites all the time. But we
> continue to make improvements.

You've sold out on the contemporary operation of the web.  Your evil.

> However as someone working with other browser vendors on a very
> regular basis, I can definitely say that we do have enough marketshare
> that we have a lot of influence. We are definitely able to make the
> web a better place on a very regular basis. As an example, just the
> other day we were able to negotiate a more standardized approach to
> push notifications where other browser vendors were happy to do
> proprietary solutions. This would not have been possible without the
> influence that we have, and the hard work we put in.

I don't see any contribution that you made to the EME discussions?

> The decision today is an improvement over the NPAPI-based DRM
> solutions that currently exist.

Wrong, just ask Henri.

This is the wrong decision. The Mozilla leadership has failed and I
believe is irredeemable. For all those who think Brendan would have done
differently, he was just as spineless on this issue.

The question for the Mozilla community is what to do now. Will the
Mozilla leadership go quietly if they are voted out?  Or do we need to
fork off development to a separate organization?

Jim

On 15/05/14 15:01, Jim wrote:
> Mozilla sold out for fear of losing market share. You didn't even try to
> make a case to users to stick with Firefox if they were forced to use an
> alternative browser to view some media content.

I for one can't even begin to think how we could have made such a case.
In my experience, for users, "Firefox can't play my video" translates
"Firefox is broken", which in turns translates at best to "I'll wait for
a patch" and at worst to "I'll change browser".

> Windows users already
> have IE installed and you could have just deferred to IE for content
> requiring EME - users have already chosen to use Firefox over IE so see
> value in Firefox. There was a proposal made at the W3C that would have
> further mitigated concerns of losing market share but Mozilla was not
> interested.

I may be misunderstanding your suggestion, but this looks like a
lose/lose situation:
1/ using Firefox becomes more complicated and less stable for users who
wish to read videos;
2/ our code becomes harder to write, maintain and test because it now
depends on (presumably) IE and Safari and Chrome for Android;
3/ we abandon Linux users;
4/ Firefox OS users never get to see videos;
5/ our users still end up running proprietary closed box software;
6/ instead of said closed box software running in a sandbox, it runs
with whichever privileges Microsoft/Apple/Google decided to use.

>> Where was the internet outrage when Microsoft and Google implemented
>> this in their browsers? Where was the outrage towards Hollywood
>> studios asked for this? The fact that people at large simply let them
>> get away with this silently is ultimately what is forcing our hand
>> here.
>
> The average web user might not understand how evil this decision is.

Well, yes, that's the core of the problem. Users are not aware of the
perils of DRM. We all need to work on both education and alternatives.
That's the real battlefield. But deciding 1/ to be the only browser on
which movies cannot be played or 2/ to use the approach discussed a
above – neither helps.

> The question for the Mozilla community is what to do now. Will the
> Mozilla leadership go quietly if they are voted out?  Or do we need to
> fork off development to a separate organization?

Well, you can certainly fork Firefox to your heart's content – or simply
deactivate the proprietary components, or use IceWeasel, etc. There are
plenty of options.

Best regards,
 David

--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

On Wed, May 14, 2014 at 8:46 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>   * Not shipping it by default.

>   * Requiring explicit user content before downloading the CDM.

These are potentially misleading statements. What "shipping" means is
ambiguous, and we've not reached a conclusion on where exactly the
user consent should come into play (e.g. before downloading vs. before
using).

I think the things we have committed to are better described as:
* Not distributing CDMs with Firefox (i.e. there will be no CDMs in
the Firefox package downloaded from Mozilla)
* Requiring user consent before CDM code is executed

Additionally:
* some mechanism for users to disable the use of EME/CDMs entirely will exist

Gavin

On Thu, May 15, 2014 at 3:01 PM, Jim <jimt...@openmailbox.org> wrote:

> The community received no support from Mozilla. Mozilla have supported the
> W3C and the EME all the way, and are still a member of the W3C. Even when

> W3C employees started joking about assassinating EME dissenters Mozilla was
> silent. Mozilla have a representative on the W3C TAG and the TAG produced a
> draft document on the EME that is a complete joke, just ask Henri. Mozilla
> has made no formal objection to the EME at the W3C.
>

> Mozilla sold out for fear of losing market share. You didn't even try to

> make a case to users to stick with Firefox if they were forced to use an

> alternative browser to view some media content. Windows users already have

> IE installed and you could have just deferred to IE for content requiring
> EME - users have already chosen to use Firefox over IE so see value in

> Firefox. There was a proposal made at the W3C that would have further

> mitigated concerns of losing market share but Mozilla was not interested.
>

> You might all be surprised that the EME is not even about DRM, it's
> purpose is to lock users into using proprietary web based media players.
> The EME is just a JS API, it is not a media decoder and can not play
> content without proprietary JS downloaded from the content distributors
> website. Mozilla understood this and insisted on this design.
>

> You've sold out on the contemporary operation of the web.  Your evil.
>
>

> This is the wrong decision. The Mozilla leadership has failed and I
> believe is irredeemable. For all those who think Brendan would have done
> differently, he was just as spineless on this issue.
>

> The question for the Mozilla community is what to do now. Will the Mozilla
> leadership go quietly if they are voted out?  Or do we need to fork off
> development to a separate organization?
>
>

Jim,

from these comments and your contributions to other discussions in recent
weeks, it's clear that you're deeply mistrusting of everything Mozilla
(Corporation and Foundation) leadership and employees say. This is your
right, obviously, as much as I wish that you gave us the benefit of the
doubt to a larger extent.

If you want to read an in-depth analysis, that answers many of the
questions you asked, by someone I hope you can trust, Cory Doctorow's piece
for the Guardian is an excellent read:
http://www.theguardian.com/technology/2014/may/14/firefox-closed-source-drm-video-browser-cory-doctorow


thanks,
till

On 5/15/14, 5:08 AM, Jim wrote:
> How does it meet the demands by content owners for robust DRM, while
> allowing the user to sandbox the CDM, and also not being tivoized which
> is not an option on Linux?

I personally do not know.  But I am told by people I trust (e.g. Henri),
that this issue was considered.  Because it turns out that the people
working on this were not dumb.

> Sure, the EME keeps the details of the CDM and such sandboxing outside
> its scope, an intentional decision by the W3C working group. Sandboxing
> was raised.

There is a difference between rejecting the possibility of sandboxing
and rejecting the requirement for sandboxing.  Which one of those two
(or neither?) are you talking about?

-Boris

On 5/15/14, 6:01 AM, Jim wrote:
> Mozilla have supported
> the W3C and the EME all the way

Uh... are you serious?  The Mozilla people who are on the record
speaking about this issue before today (me, Robert, Henri) come across
that way to you?

> and are still a member of the W3C

Yes, we were even a member when they did things like XHTML2....

> Even when W3C employees started joking about assassinating EME dissenters

I was not aware that this had happened.  That's clearly not acceptable
in a professional setting.

> Mozilla have a representative on the W3C TAG and the
> TAG produced a draft document on the EME that is a complete joke

We have _a_ representative on the TAG.  The tag does not require
unanimous consensus for documents it produces, so can produce documents
over the objections of some of its members.

> just ask Henri.

I'll turn this around.  Have _you_ talked to Henri about this?

> Mozilla has made no formal objection to the EME at the W3C.

That's true, but there is actually little point to doing that: others
have already raised formal objections, we know how TBL will decide on
such formal objections, and we've already made our feelings on the
matter known so there is nothing to be gained from a formal objection
that way.

On the other hand, given that all of our competitors _are_ shipping DRM
no matter what we, or the W3C for that matter, do, the least bad option
is for them all to ship it behind the same API, at least.

> Mozilla sold out for fear of losing market share.

That's a perfectly valid point of view.

> You didn't even try to make a case to users to stick with Firefox if they were forced to use an
> alternative browser to view some media content. Windows users already
> have IE installed and you could have just deferred to IE for content
> requiring EME - users have already chosen to use Firefox over IE so see
> value in Firefox.

I suspect this would have been non-viable, and you overestimate how much
value users see in any browser and how much the annoyance of this
behavior would just drive them to IE completely.  But it's possible I'm
wrong, of course.

> There was a proposal made at the W3C that would have
> further mitigated concerns of losing market share but Mozilla was not
> interested.

Can you link to this proposal please?  I'm not aware of it...

> Mozilla understood this and insisted on this design.

Citation, please?

-Boris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/15/2014 05:38 AM, Jonas Sicking wrote:

> It's not a question of absolutes. We don't have anywhere near as much
> marketshare that we can call all the shots all the time. But that
> doesn't mean that we don't have any influence.
>
> But there was a lot of pressure on the various actors here. And sadly
> we don't have enough influence to prevent the badness in this
> situation. And we didn't receive enough help from the larger internet
> community.
>
> Where was the internet outrage when Microsoft and Google implemented
> this in their browsers? Where was the outrage towards Hollywood
> studios asked for this? The fact that people at large simply let them
> get away with this silently is ultimately what is forcing our hand
> here.

For my part, I wasn't aware that this had been implemented by anyone
yet, nor that it was yet anything more than a proposal for a standard
that had not yet been finalized (and which was seeing opposition from
some parties, and might not be finalized at all). I suspect that other
people might be in the same position, and this might help explain the
lack of previous outcry.

I agree that the outrage here should be directed at - and the blame here
truly lies with - the people insisting on DRM, and demanding that other
people support their efforts to implement DRM. (And secondarily with the
people at the W3C who acceded to those demands.)

However, I note that with the Hollywood studios, and to some extent the
companies behind the other browsers, a lack of outrage is less
surprising, because - little though we like it - that sort of thing is
what we *expect* them to do, based on their previous behavior; it's
"business as usual" from that end of things, so when they do it, our
expectations of them are not violated.

- From Mozilla, however, we expect a more open, more strongly principled
stand. There may be good reasons for not taking it in this particular
case, but that violation of expectations is much more likely to spark
outrage than is the same action from the other companies, simply because
those other companies have already established that we cannot expect
them to do anything different.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTdN/pAAoJEASpNY00KDJrvNkP+wX71ixOTSpldPRjRKTtxCLk
AXlA69uC01be35ZS6k3yRwamr1f8DI0/TpE3I/CIOasAE1DQw7Kwl9YrUC/in4Wr
ZmDGgek16IB8vr1OhGm4nQvr9Kd5jiVmk1OSfbnjjX6gKjmmkPrUVMD5Yfc1knv0
EmewrJHN9+HYAfGn910y0bOXfu4rRjbSbBqau+RsK+XhrX+9jripax2GaAuJvs3I
L+uyHsJTnAnStLXlnanvWjEp264r5UCMEjEF7707tF7DSBJRqarJKpnJ1o8zP2r+
1wSjrHZ0bxSiAs3/D357UYHIiEfPi8Nd1S+oo5m171mpU+kVp7NwjrfL6LlDfrH2
rvqcG52Y0IqZsYgsd2ahrH09Jdagm8MaIj0bzKLtKmIkmhJHRmMfKPnGIVrAK51t
KZyRO25ehcb6ingH/Yb8Cyqo1AzUtSSbXc7TZWbLtXPyjUncp745Ng3DhptJbHdU
f6W0EANd7blOpA+uXL648ngNOpp7LLvwjHRF+rYvjCki00SxpgY/k9txqITCeLS1
miaUmx7ah7IZ9AKzFGO4IMJbjVmdVda87cASGnsvSfcBlGJ7+tI9Q7sp+cy221w2
bYO6h4yYa2qwy4vXq5uqpbjXzYwb4R1vOfb6YlLrFjioc92yoyZ3DSkP/1fM48di
gikBL4lTzMfrPYL+oa1T
=cOdR
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/15/2014 09:33 AM, Gijs Kruitbosch wrote:

> On 15/05/2014 14:01, Jim wrote:
>
>> On 2014-05-15 11:38, Jonas Sicking wrote:

>> Mozilla sold out for fear of losing market share.
>
> Sorry, where does "sold out" come from? We receive no financial
> compensation in any way for this decision, so I strenuously object to
> you suggesting we had any motivation except "our users will want
> this content" and "we need our users to be able to use Firefox to
> browse /all/ of the web, in order to be able to fight another day
> against DRM and other anti-openness proposals for the web".

I think the idea is that you're being compensated for including this not
in money ("financial compensation"), but in market share.

It looks to me more like caving to blackmail than like accepting a
bribe, and looking at it in that light changes where the fault appears
to lie, but the idea is at least not internally inconsistent.

DRM-hostile though I am, and much though I've disliked many things
Mozilla has done (and the ways Mozilla has done them) over the last
several years, this really does look to me like the least of several
evils.

The true blame here does not lie with Mozilla, but with the people
pushing for DRM, and the middlemen who act as their enablers. (Although
some people may now not unreasonably consider Mozilla to fall in that
latter category, I would at least say that they are less so than the
people at the W3C who accepted the idea of building this into HTML.)

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTdOHvAAoJEASpNY00KDJrBwEP/19CEenyX6k/9bMDoC1hfCKv
u1Ou7tCsF1iZXoiwHCwXxjusK5ihyJkMkF28FMOswAzkcqSb5TJcUjQy/e8jOsMG
hjgR8oCZAkP2m3kovNIwdR1Bg1/RodZYzKvFXr6YaKvLlStAb5xUeAZAAJxL3/mT
+BGVtRxzOo5JhKJfLWyQVmLlzz6NaIqa2fbqsV2BHFyVHcJq501jBXWVipKj8Kfd
1+5o+VaZghlWSlr5FT9ek+cYvS/akxlwKkzpGSO9ZCr0IYDuUuEiB5FYogVq/eMp
hXkTtP9xmskrho6cK5oWuv5dy+Wf5SkFTSEXVprvXIqvnqJnBPLwg1wW0/9jnxQD
VXh7KVt7KlMYywIFGcLGzy95093ppQYZdfdsn2uw2VhBJM9pKYXr1J3wb094mZJ7
U1xGNxnRa5zEvWm/Plr8WLLvv3DMr2rZrCidwe2WkITY3OZdQCa3CkkjH/2+nn16
RuQy4OvehUuEtzVBxjbcOoRningtBJPi0Bk7lLbSJUXsTnGTSmDk3fEGO07frG5k
qlphXI3+DC8hV5laU7+XxNyfuvSomf+OJIJPVWGzhfLygDCabynlwztG0mcsocjs
EonGXoeqDaarGW+2x+8qn+Up84FcnE4d0HBLqFRm3gtshgaipsHlE0xFodcZ+8oR
RIPc+0qpdNmRetDJaIhM
=lDGc
-----END PGP SIGNATURE-----

A bit aside to the discussion of DRM itself -

This is the kind of topic that Reps will be asked about. I'll be helping
man our booth at OSCON for example. Of course Reps were invited to the town
hall, but I'd like to see something a bit more like training than just
information. A guide similar to the CEO FAQ would be great, as well as
having people reach out on the Reps-General list to discuss how to talk
about this and answer questions (not just about information on the topic)
would be really helpful.

Speaking for myself, I am aware of some of these top issues, but I'm not
always following them. Part of my role as a Rep is to spread Mozilla's
mission. I don't always feel prepared to engage with people on topics like
this, though I feel like being able to is part of my job as a Rep and a way
I can provide a lot of value to Mozilla. However, I don't have the time to
make sure I know all this on my own (in large part due to my involvement in
many Mozilla teams already). I need Mozilla to say to me "as a Rep, we want
you to be able to engage on this issue, here is what you'll need to do so."


On Thu, May 15, 2014 at 11:49 AM, The Wanderer <wand...@fastmail.fm> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 05/15/2014 09:33 AM, Gijs Kruitbosch wrote:
>
> > On 15/05/2014 14:01, Jim wrote:
> >
> >> On 2014-05-15 11:38, Jonas Sicking wrote:
>
> >> Mozilla sold out for fear of losing market share.
> >
> > Sorry, where does "sold out" come from? We receive no financial
> > compensation in any way for this decision, so I strenuously object to
> > you suggesting we had any motivation except "our users will want
> > this content" and "we need our users to be able to use Firefox to
> > browse /all/ of the web, in order to be able to fight another day
> > against DRM and other anti-openness proposals for the web".
>
> I think the idea is that you're being compensated for including this not
> in money ("financial compensation"), but in market share.
>
> It looks to me more like caving to blackmail than like accepting a
> bribe, and looking at it in that light changes where the fault appears
> to lie, but the idea is at least not internally inconsistent.
>
> DRM-hostile though I am, and much though I've disliked many things
> Mozilla has done (and the ways Mozilla has done them) over the last
> several years, this really does look to me like the least of several
> evils.
>
> The true blame here does not lie with Mozilla, but with the people
> pushing for DRM, and the middlemen who act as their enablers. (Although
> some people may now not unreasonably consider Mozilla to fall in that
> latter category, I would at least say that they are less so than the
> people at the W3C who accepted the idea of building this into HTML.)
>
> - --
>    The Wanderer
>
> Secrecy is the beginning of tyranny.
>
> A government exists to serve its citizens, not to control them.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCgAGBQJTdOHvAAoJEASpNY00KDJrBwEP/19CEenyX6k/9bMDoC1hfCKv
> u1Ou7tCsF1iZXoiwHCwXxjusK5ihyJkMkF28FMOswAzkcqSb5TJcUjQy/e8jOsMG
> hjgR8oCZAkP2m3kovNIwdR1Bg1/RodZYzKvFXr6YaKvLlStAb5xUeAZAAJxL3/mT
> +BGVtRxzOo5JhKJfLWyQVmLlzz6NaIqa2fbqsV2BHFyVHcJq501jBXWVipKj8Kfd
> 1+5o+VaZghlWSlr5FT9ek+cYvS/akxlwKkzpGSO9ZCr0IYDuUuEiB5FYogVq/eMp
> hXkTtP9xmskrho6cK5oWuv5dy+Wf5SkFTSEXVprvXIqvnqJnBPLwg1wW0/9jnxQD
> VXh7KVt7KlMYywIFGcLGzy95093ppQYZdfdsn2uw2VhBJM9pKYXr1J3wb094mZJ7
> U1xGNxnRa5zEvWm/Plr8WLLvv3DMr2rZrCidwe2WkITY3OZdQCa3CkkjH/2+nn16
> RuQy4OvehUuEtzVBxjbcOoRningtBJPi0Bk7lLbSJUXsTnGTSmDk3fEGO07frG5k
> qlphXI3+DC8hV5laU7+XxNyfuvSomf+OJIJPVWGzhfLygDCabynlwztG0mcsocjs
> EonGXoeqDaarGW+2x+8qn+Up84FcnE4d0HBLqFRm3gtshgaipsHlE0xFodcZ+8oR
> RIPc+0qpdNmRetDJaIhM
> =lDGc
> -----END PGP SIGNATURE-----
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

On Thu, May 15, 2014 at 8:40 AM, The Wanderer <wand...@fastmail.fm> wrote:
> However, I note that with the Hollywood studios, and to some extent the
> companies behind the other browsers, a lack of outrage is less
> surprising, because - little though we like it - that sort of thing is
> what we *expect* them to do, based on their previous behavior; it's
> "business as usual" from that end of things, so when they do it, our
> expectations of them are not violated.

I can understand this reaction. And I think it is shared by a lot of
people. However sadly it's not a useful one.

This is essentially asking mozilla to fight both the content industry,
the content distribution industry and the other browser vendors for
you, and then not helping out.

It does little good to ask mozilla to fight harder and complain when
we're loosing.

/ Jonas

On 5/15/14, 1:07 AM, Boris Zbarsky wrote:
>
> Some obvious bits that jumped out at me:
>
> * The CDM not having unmediated access to the network, the hard drive,
> or any other part of the user's computer.
>
> * The CDM being available on Linux.

If the CDM can run while completely sandboxed from network and file
access, then it could be implemented in asm.js so the CDM.js would be
portable across all browser platforms and architectures. :)

I realize that obfuscation of closed-source code is probably easier with
binary blobs than textual asm.js code, but maybe not much. That sounds
like an interesting area of research.


chris

On Thu, May 15, 2014 at 02:38:52AM -0700, Jonas Sicking wrote:
> On Wed, May 14, 2014 at 11:10 AM, Rubén Martín
> <nuke...@mozilla-hispano.org> wrote:
> >   * It's not the first time we take decisions because everyone else is
> >     doing it, and we want to keep being relevant.
> >       o This worries me the most looking at the future, since we are
> >         going to be always the only ones with completely different
> >         values to the rest of the players in the browser ecosystem.
> >       o Have we lost hope to be enough relevant to avoid these situations?
>
> It's not a question of absolutes. We don't have anywhere near as much
> marketshare that we can call all the shots all the time. But that
> doesn't mean that we don't have any influence.

Well, we should probably have some absolutes somewhere.  Where I
personally draw that line in the sand and where Mozilla does are a bit
different, but that seems ok if we're all up front about it.

> But there was a lot of pressure on the various actors here. And sadly
> we don't have enough influence to prevent the badness in this
> situation. And we didn't receive enough help from the larger internet
> community.

yeah, though I wonder if we could have helped make more people aware of
the issue.  On the other hand I'm not sure how much it helps to tell the
public giving content providers and owners money when they require DRM
is useful given the only other options are pretty bad.

> Where was the internet outrage when Microsoft and Google implemented
> this in their browsers? Where was the outrage towards Hollywood
> studios asked for this? The fact that people at large simply let them
> get away with this silently is ultimately what is forcing our hand
> here.
>
> This is not that different from that we were ultimately forced to ship

So, I actually feel more or less the oposite way about h264 mostly
because it meets the DFSG requirements, demonstrated by Debian shipping
it in the main part of there archive not the non free one.  Sure it
would be nice if people didn't need to worry about patents, but given
that I believe they shouldn't exist in the first place its pretty hard
to care about some abiguity in if something is patented or not.

> h264 due to the very developers that we were trying to protect were
> the ones that yelled at us for going our own way.

What are you trying to say here? its not clear to me.

> We can't do everything ourselves. As much as I wish that wasn't the case.
>
> And remember, just like with the video codec issue, just because we
> lost in this instance doesn't mean that we've given up. We haven't yet
> gotten all browsers to follow standards all the time, and all
> developers to write user friendly websites all the time. But we
> continue to make improvements.
>
> However as someone working with other browser vendors on a very
> regular basis, I can definitely say that we do have enough marketshare
> that we have a lot of influence. We are definitely able to make the
> web a better place on a very regular basis. As an example, just the
> other day we were able to negotiate a more standardized approach to
> push notifications where other browser vendors were happy to do
> proprietary solutions. This would not have been possible without the
> influence that we have, and the hard work we put in.
>
> The decision today is an improvement over the NPAPI-based DRM
> solutions that currently exist. We will continue to work on making the
> next iteration better yet. Hopefully we will one day manage to rid the
> web of DRM completely.

it seems to me it's not all better and we shouldn't pretend it is, but
it certainly has some benefits, and some of those are truely perverse
e.g. now if you want to use DRM on the web not only do you have to pay
off Microsoft and Adoby to get there DRM servers you need to pay Google
and Apple, and you need to do that exactly because some bits aren't
standardized.

> >   * We want to get rid of plugins but we implement something that always
> >     depends on an external and proprietary module.
> >       o It won't be impossible to access the full web using open source
> >         bits, since if we also agree on this, even people not using DRM
> >         right now are going to switch to it eventually.

If you mean new content owners will require DRM I  suspect your wrong
because EME has managed to fragment  the DRM provider space, and so make
it more expensive.

That said I'm kind of worried about providing a solution on linux,
because I'm not sure if that means people who wouldn't have used Netflix
or its ilk now will, or if it just means people would use Chrome if we
don't do this.  The answer to that game theory question seems clear for
!desktop linux, but given the different views of the users of that
platform and there overall greater technical ability I'm not entirely
sure.

Trev

>
> DRM is inherently incompatible with open source unfortunately. Not
> just on a philosophical level, but also technically. I'll let others
> comment here as I don't know enough details.
>
> / Jonas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/15/2014 05:26 PM, Jonas Sicking wrote:

> On Thu, May 15, 2014 at 8:40 AM, The Wanderer <wand...@fastmail.fm>
> wrote:
>
>> However, I note that with the Hollywood studios, and to some extent
>> the companies behind the other browsers, a lack of outrage is less
>> surprising, because - little though we like it - that sort of thing
>> is what we *expect* them to do, based on their previous behavior;
>> it's "business as usual" from that end of things, so when they do
>> it, our expectations of them are not violated.
>
> I can understand this reaction. And I think it is shared by a lot of
> people. However sadly it's not a useful one.

Oh, I agree. I wasn't attempting to justify the reaction, I was simply
attempting to explain it.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTdXsRAAoJEASpNY00KDJr2hgQAK6vGOJOJyYsTw3E7n06vRQA
XHjNTf8008bFKGddx+ucC0Q/119xMQdtimtaNZWl3bJq1ZRCwVkeosb1BAfhTUnH
sxBSe0+WRyYwnkHAgk6oLbYFowf9+WTJv7u2kJnv30+xv1g1Gy5eaVma6LNP+vVt
jPiCD6cpfx6TX1YqOLTc4x5S21laRgqbpEkufb1864yWaluOGrJrmXBCNiF7Gt8Y
ICNWWvXG9bKOhB6iqp55FvNKiInQ0QUZXz9H8L3bGlsZX8rV+aoySmiuYSx0q2qU
OCGKDlokqKr64zhOH4w8J1AkK4s5PCBqG/M356XvkuXumk2mdIGP4Hzk3QDYVgnu
u3fMS62xjzIlOU0jzNFkUiPQ6XilZftky3cADgvpjfbqgN7Y77zrfiDx2cAEqxqM
xnB7Yga5i+88pwtmWpq37Qcaxo+hSUuShLw7DtWk4pQ4rCP4DbQRuU8VGwROURLV
BxOTEzXqez0hHSYla85RTuKTZsTNLKYQWYHspzfUjlJEwSbGzSvyly6iaeFsEWhW
sIflFAjYFw/V/F2cgU/BBS+kErieB6GW9XmZWga6dNmeusnoo0UY+CMDBoqdRAjz
VCiYezIt1YPITj2p+/X4DWB9JP8HJW9eKipDqnyAf+fPh9k1GfhjExFATVLjx94d
+/772OYPvqaxzHjmN0kV
=tBdn
-----END PGP SIGNATURE-----

On 2014-05-15 17:20, Boris Zbarsky wrote:
> On 5/15/14, 6:01 AM, Jim wrote:
>> Mozilla have supported
>> the W3C and the EME all the way
>
> Uh... are you serious?  The Mozilla people who are on the record
> speaking about this issue before today (me, Robert, Henri) come across
> that way to you?

Henri seems rather hard to understand, but he seems to have promoted the
EME in the end. Did you ever make a statement on the EME?

Mozilla management are now promoting their pro-EME decision, some good
propaganda there.

>> Mozilla have a representative on the W3C TAG and the
>> TAG produced a draft document on the EME that is a complete joke
>
> We have _a_ representative on the TAG.  The tag does not require
> unanimous consensus for documents it produces, so can produce
> documents over the objections of some of its members.

The point is that Mozilla's representative has done nothing! Only Henri
spoke out.

>> Mozilla has made no formal objection to the EME at the W3C.
>
> That's true, but there is actually little point to doing that: others
> have already raised formal objections, we know how TBL will decide on
> such formal objections, and we've already made our feelings on the
> matter known so there is nothing to be gained from a formal objection
> that way.

The public might not know 'how TBL will decide on such formal
objections', and Mozilla could have at least called him out. Part of the
reason for not objecting was that TBL might do even worse, but not
standing up to him is just spineless. Mozilla should not be a member of
the W3C.

> On the other hand, given that all of our competitors _are_ shipping
> DRM no matter what we, or the W3C for that matter, do, the least bad
> option is for them all to ship it behind the same API, at least.

I disagree that following them is 'the least bad option', and it is
certainly not the only option Mozilla had.

>> You didn't even try to make a case to users to stick with Firefox if
>> they were forced to use an
>> alternative browser to view some media content. Windows users already
>> have IE installed and you could have just deferred to IE for content
>> requiring EME - users have already chosen to use Firefox over IE so
>> see
>> value in Firefox.
>
> I suspect this would have been non-viable, and you overestimate how
> much value users see in any browser and how much the annoyance of this
> behavior would just drive them to IE completely.  But it's possible
> I'm wrong, of course.

Mozilla could have mitigated the annoyance, and been in a better place
with users, without supporting the addition of DRM to the web.

>> There was a proposal made at the W3C that would have
>> further mitigated concerns of losing market share but Mozilla was not
>> interested.
>
> Can you link to this proposal please?  I'm not aware of it...

As soon as you release the source code I will use it to build an
external media player and define declarative HTML mechanisms for tagging
videos that need to use this player that allow the launching of this
with as little annoyance as possible. An EME/JS version will also be
written that works in EME capable web browsers. Web developers will be
able to target this simpler standard and know it works across browsers,
that is work with JS disabled, that they do not need to use potentially
patent encumbered JS to complete the media player, and that it works in
compliant no-web media players. The media player will be open source and
support a healthy ecosystem that can compete to protect user privacy and
security. The difference between this solution and Mozilla's position is
the real reason behind Mozilla management's decision and it is not
pretty. I will support a Firefox derivative that excludes the EME and
offers such an alternative, lanching one myself if really necessary.

Jim

On 2014-05-15 15:20, Boris Zbarsky wrote:
> On 5/15/14, 6:01 AM, Jim wrote:
>> Mozilla have supported
>> the W3C and the EME all the way
>
> Uh... are you serious?  The Mozilla people who are on the record
> speaking about this issue before today (me, Robert, Henri) come across
> that way to you?

Would add that Henri stands out a mile as having some real heart and
fight. Brendan followed, but he is gone, and he had no heart or fight
for this issue just some no-viable watermarking alternatives. I find it
hard to believe Henri promotes the EME, and I would like to see what he
could do in charge. We need someone who can stand up to TBL, and
Netflix/Google/Microsoft.

Jim

On 5/16/14, 9:41 PM, Jim wrote:
> Henri seems rather hard to understand, but he seems to have promoted the
> EME in the end.

There's a difference between "accepting" and "promoting".

> Did you ever make a statement on the EME?

http://www.w3.org/Search/Mail/Public/advanced_search?keywords=drm&hdr-1-name=subject&hdr-1-query=&hdr-2-name=from&hdr-2-query=bzbarsky%40mit.edu&hdr-3-name=message-id&hdr-3-query=&period_month=&period_year=&index-grp=Public__FULL&index-type=t&type-index=public-html&resultsperpage=20&sortby=date
are the public things I said.

> The point is that Mozilla's representative has done nothing!

Are you sure?  TAG proceedings are not public last I checked.

> The public might not know 'how TBL will decide on such formal
> objections'

The public doesn't care about W3C process at all.

> and Mozilla could have at least called him out.

I believe we have.  The "public" didn't care, even the restricted public
that follows W3C goings on.

> I disagree that following them is 'the least bad option', and it is
> certainly not the only option Mozilla had.

What is your counterproposal?

> Mozilla could have mitigated the annoyance, and been in a better place
> with users, without supporting the addition of DRM to the web.

Again, how would you do that, specifically?

-Boris

On 2014-05-17 05:33, Boris Zbarsky wrote:
> On 5/16/14, 9:41 PM, Jim wrote:
>> Henri seems rather hard to understand, but he seems to have promoted
>> the
>> EME in the end.
>
> There's a difference between "accepting" and "promoting".

Mozilla did not even put up a fight so it seems very fair to judge
Mozilla as promoting the EME. Mozilla had other choices and had the
choice to do nothing, but they chose to add DRM to the web using the
EME.

Look at the yourself. All I see is resistance from Mozilla to getting a
better outcome for user security and privacy. The management statements
are deceptive propaganda - how is this helping the mission?

>> Did you ever make a statement on the EME?
>
> http://www.w3.org/Search/Mail/Public/advanced_search?keywords=drm&hdr-1-name=subject&hdr-1-query=&hdr-2-name=from&hdr-2-query=bzbarsky%40mit.edu&hdr-3-name=message-id&hdr-3-query=&period_month=&period_year=&index-grp=Public__FULL&index-type=t&type-index=public-html&resultsperpage=20&sortby=date
> are the public things I said.

Three passing comments does not demonstrate any heart or fight. You have
made more posts defending Mozilla's decision to implement the EME!

>> The point is that Mozilla's representative has done nothing!
>
> Are you sure?  TAG proceedings are not public last I checked.

Check again, the TAG document on the EME is on github and discussion is
on a public mailing list. I do not see any input from Mozilla's
representative David.

>> The public might not know 'how TBL will decide on such formal
>> objections'
>
> The public doesn't care about W3C process at all.

I disagree, and this is not a reason for Mozilla to support the EME at
the W3C.

>> and Mozilla could have at least called him out.
>
> I believe we have.  The "public" didn't care, even the restricted
> public that follows W3C goings on.

You should know that only a formal objection has any standing.

>> I disagree that following them is 'the least bad option', and it is
>> certainly not the only option Mozilla had.
>
> What is your counterproposal?

I summarized my understanding of the proposal in my last email to you.
Check the W3C mailing list archives to see the discussion there. My
point is that Mozilla did not even try.

>> Mozilla could have mitigated the annoyance, and been in a better place
>> with users, without supporting the addition of DRM to the web.
>
> Again, how would you do that, specifically?

Firefox could recognize media needing DRM decoding and launch a separate
media player.  This could be made as convenient as possible and could
support features that would not work with the EME such as a giving users
a choice of the target device and these features could be used promote
an alternative. This would keep DRM out of the web which would be
aligned with Mozilla's mission and be something that Mozilla could
honestly be proud of. Netflix might refuse to support an alternative web
standard, but it need not be a conflict with content owners and market
forces would work to correct this.

Jim

Well, you're right, it is beyond me, but that does not mean it is beyond
everyone, and it is an alternative proposal that at least demonstrates
how disingenuous Mozilla's propaganda is. It will be very hard to fight
this now that Mozilla support the EME. It is so disappointing that
Mozilla have betrayed the open web and used their market share to
promote adding DRM to the web.

I am still waiting for Mozilla to clarify that users will be able to
watch Netflix in all its glory using their EME/CDM? This was the
justification for their decision and it's a matter of credibility.

I am still waiting for Mozilla to make the sandbox source code available
so that the claims regarding the enforcement of user security and
privacy can be verified?

Jim

On 5/17/14, 7:30 PM, Jim wrote:
> Mozilla did not even put up a fight

You're entitled to your opinion, of course, but I respectfully disagree.

> Three passing comments does not demonstrate any heart or fight. You have
> made more posts defending Mozilla's decision to implement the EME!

I care a lot more about what people here think than what people in the
HTML WG, most of whom had their minds pre-made-up, think, honestly.  I
also care about making sure we're not missing obvious alternative paths
that are actually viable.

> You should know that only a formal objection has any standing.

You can't "call out" TBL in a formal objection...

> I summarized my understanding of the proposal in my last email to you.

I'm afraid I'm missing a crucial part of your proposal: how do you plan
to get the CDM to play along with it?

> My point is that Mozilla did not even try.

I think that's a disservice to the people who have spent at least a year
now working full-time on dealing with this (including Henri).

> Firefox could recognize media needing DRM decoding and launch a separate
> media player.

How is that fundamentally different from launching a plug-in?

> This would keep DRM out of the web

How so, if the user experience is still seamless?

-Boris

On 5/17/14, 8:37 PM, Jim wrote:
> I am still waiting for Mozilla to make the sandbox source code available

There is no source code to make available yet, as far as I know; the
announcement was made once the agreements were reached, and there hasn't
been time to actually start implementing the sandbox.

Once the sandbox implementation starts, it'll be out in the open like
all the other code we do.

> so that the claims regarding the enforcement of user security and
> privacy can be verified?

That's the idea, yes.

-Boris

On 2014-05-18 04:01, Boris Zbarsky wrote:
> On 5/17/14, 7:30 PM, Jim wrote:
..
>> I summarized my understanding of the proposal in my last email to you.
>
> I'm afraid I'm missing a crucial part of your proposal: how do you
> plan to get the CDM to play along with it?

If the player is defined in a JS/EME web browser then the CDM would play
along. It does require that the JS component communicating with the CDM
via the EME is a standard. Netflix might refuse to support this
standard, but you could try.

If you are sandboxing the CDM, and if the CDM only verifies that it is
running in this sandbox, then it should make no difference if it is part
of a web browser or part of a dedicated media player, so it could be
re-purposed for use in such a media player.

This would allow the DRM media player to be kept out of the web. A
general declarative HTML extension could be used to invoke the player.

> How is that fundamentally different from launching a plug-in?
>
>> This would keep DRM out of the web
>
> How so, if the user experience is still seamless?

The web browser and DRM player are separate. The DRM player could
operate alone given a URL, and the player could be remote from the
browser for even more secure sandboxing. No DRM extensions would be
added to web standards.

The content distributors want the EME rather than such a solution so
they can lock the user into using their web base media player, adding
their own proprietary JS to complete player, and to be able to provide a
rich[sic] experience. This is what Mozilla have decided to support, not
the viewing of DRM movies. You don't need to take my word for it,
Netflix communicated this in the W3C mailing lists, but when pressured
to articulate their use cases they clammed up.

Jim

On 5/18/14, 12:51 AM, Jim wrote:
> It does require that the JS component communicating with the CDM
> via the EME is a standard. Netflix might refuse to support this
> standard, but you could try.

We've tried to get that part standardized, and failed.

> If you are sandboxing the CDM, and if the CDM only verifies that it is
> running in this sandbox, then it should make no difference if it is part
> of a web browser or part of a dedicated media player, so it could be
> re-purposed for use in such a media player.

That's correct, as long as you use the same sandbox.

> This would allow the DRM media player to be kept out of the web.

This seems like a pretty arbitrary distinction: using a browser plug-in
vs launching a helper app that does the same thing.  The end result is
still DRM media on the web relying on the user having the DRM-enabled
player.

> The web browser and DRM player are separate.

Why is this particular bit important?  I genuinely don't understand why
having web browser and an always-present DRM player is any different
than just having the web browser include the player.

> No DRM extensions would be added to web standards.

That's happening no matter what we do...

-Boris

On Wed, May 14, 2014 at 9:10 PM, Rubén Martín

<nuke...@mozilla-hispano.org> wrote:
>   * It's not the first time we take decisions because everyone else is
>     doing it, and we want to keep being relevant.
>       o This worries me the most looking at the future, since we are
>         going to be always the only ones with completely different
>         values to the rest of the players in the browser ecosystem.
>       o Have we lost hope to be enough relevant to avoid these situations?

Chrome being available and doing H.264 on one hand and EME-style DRM
on the other sure makes the overall situation different from what the
situation was like at the time of IE6 and Firefox 1.0.

>   * We want to get rid of plugins but we implement something that always
>     depends on an external and proprietary module.

Making Adobe Access available to Firefox without the Flash platform in
between is not inconsistent with a desire to address problems with
NPAPI plug-ins.

>       o It won't be impossible to access the full web using open source
>         bits, since if we also agree on this, even people not using DRM
>         right now are going to switch to it eventually.

We simply can't know for sure how the market dynamics play out.
However, as noted in my earlier message, EME doesn't make DRM free of
cost to streaming services or fully cross-browser-compatible.

Jonas Sicking wrote:
> And remember, just like with the video codec issue, just because we
> lost in this instance doesn't mean that we've given up.

Moreover, the EME situation might have gone differently if the H.264
situation had gone differently. The H.264 situation showed that when
stuff works in <video> in Chrome, IE and Safari and works in
<object>/<embed> in Firefox, we can't turn the tide by keeping it not
working in <video> in Firefox.

Jim wrote:
> Mozilla has made no formal objection to the EME at the W3C.

We didn't do so, because the likely outcomes were:

 1) No change in what the W3C was doing. Effecting no change would not
have been a meaningful win. It might have scored us some positive
political points in some quarters. It might have also made it harder
to ensure that Firefox users will be able to continue to view the
content that they currently can and that users of other browsers are
and will be able to view.

 2) EME getting kicked out of the HTML WG into a new DRM WG. This
would have been worse than having it in the HTML WG, because once
you've created a working group whose purpose is to work in DRM, the
group might seek to sustain its existence even after the deliverable
it was created to deliver has been delivered. In other words, this
outcome would have made more probable that the W3C would work on other
DRM-related things after EME was done.

 3) EME getting kicked out of the W3C and getting picked up by another
standardization forum. This would have been worse than having it at
the W3C, because another forum would probably have been more
IPTV-oriented and less Web-oriented. The Microsoft PlayReady-informed
key acquisition architecture that EME embodies is a better fit for the
Web than the alternative key acquisition architecture that is popular
among the IPTV constituency. (See
http://lists.w3.org/Archives/Public/public-html-media/2013May/0016.html
on an elaboration on the Webbiness merits of the EME architecture.)

The pressure to enable Firefox to integrate with EME-style DRM doesn't
come from EME being on the Recommendation track at the W3C. It comes
from the combination of
 1) Users want to see Hollywood movies.
 2) Major studios require movie streaming services to use DRM.
 3) Our existing DRM solution, NPAPI, not being sustainable with e.g.
Silverlight getting end-of-lifed.
 4) Chrome, IE and Safari taking the path of enabling EME-style DRM.

> You didn't even try to make a case to users to stick with Firefox if they were forced to use an alternative browser to view some media content.

Some users might use another browser for DRM and still come back to
Firefox for other needs. However, I think the notion that Mozilla's
position should be "use another browser" is fundamentally naive. It
doesn't result in users not having DRM on their computers. It doesn't
result in Mozilla getting to sandbox the DRM. It doesn't result in
users not engaging with services that use DRM. It doesn't address what
Firefox OS users should do. (Though, granted, we haven't announced
anything for Firefox OS, either.) It would likely result in people
(not everyone but many) to consider it easier to only use the other
browser.

> Selling out on users control over their own computer is not the right decision.

How are we selling *that* out when we
 1) Are going to give the user the option to decline Adobe Access DRM
(at the cost of not being able to use some services)
 2) Are going to sandbox the DRM component
 3) Are not currently sandboxing Flash Player or Silverlight?
?

>> The decision today is an improvement over the NPAPI-based DRM
>> solutions that currently exist.
>

> Wrong, just ask Henri.

EME-style DRM is technically an improvement over NPAPI-based DRM, in
my opinion. If EME had been here first, no one would argue that
Firefox's Adobe Access integration would improve by adding the Flash
platform in between and removing the Mozilla-controlled sandbox.

The market dynamics of EME CDMs are different from the market dynamics
of NPAPI plug-ins, which has the potential of making the impact
EME-style DRM worse than NPAPI DRM for Mozilla. We can't know what
ends up happening exactly. However, due to having systematically
worked to erode the business case for non-DRM uses of NPAPI, we don't
really get to choose to e.g. reverse the end-of-life decision
Microsoft made with Silverlight and stick to NPAPI as the solution.

Boris Zbarsky wrote:
>> Even when W3C employees started joking about assassinating EME dissenters
>
> I was not aware that this had happened.  That's clearly not acceptable in a professional setting.

I believe this is a reference to
http://lists.w3.org/Archives/Public/public-html-admin/2014Feb/0062.html
, which I agree was inappropriate.

The Wanderer wrote:
> For my part, I wasn't aware that this had been implemented by anyone
> yet, nor that it was yet anything more than a proposal for a standard
> that had not yet been finalized (and which was seeing opposition from
> some parties, and might not be finalized at all). I suspect that other
> people might be in the same position, and this might help explain the
> lack of previous outcry.

Netflix first announced their EME deployment in the context of Chrome OS:
http://techblog.netflix.com/2013/04/html5-video-at-netflix.html
Google's part is in the bowels of Google+:
https://plus.google.com/100132233764003563318/posts/6QW8TLtV6q3

Microsoft and Netflix have co-marketed Microsoft's implementation:
http://www2.netflix.com/ie11testdrive linked from
http://ie.microsoft.com/testdrive/
(Yes, it's deployed in production, too.)

That Google and Microsoft have been doing this isn't exactly a secret.
Their names are even on the EME spec! Apple has stayed quiet, though.
You have to go look in the WebKit codebase and the WebKit Bugzilla to
see what's happening.

I agree that the difference in the level of outcry is likely mainly
due to EME being a better fit for the expectations that people have of
Microsoft, Google and Apple than the expectations that people have of
Mozilla.

Trevor Saunders wrote:
> So, I actually feel more or less the oposite way about h264 mostly
> because it meets the DFSG requirements, demonstrated by Debian shipping
> it in the main part of there archive not the non free one.

FWIW, I view Debian putting H.264 in main and the FSF listing ffmpeg
in the Free Software Directory (https://directory.fsf.org/wiki/Ffmpeg)
while explicitly excluding Firefox because Firefox suggests non-Free
software despite being itself Free
(https://directory.fsf.org/wiki/Firefox redicerts to
https://directory.fsf.org/wiki/GNU_IceCat) are the most blatant
examples of even the core of the Free Software movement not standing
with us on the H.264 issue. (As noted above, I think we might have
reacted to EME differently had things gone differently for our
opposition to H.264.)

Also, FSF's PlayOgg campaign is supposed to be against certain formats
but the campaign promotes VLC *which plays those formats*! Pretty
serious collateral enablement in my view.

Jim wrote:
> Henri seems rather hard to understand, but he seems to have promoted the EME in the end.

I think I've never promoted EME over publishing without DRM. I do
consider the EME architecture superior to the most likely alternative
architecture for integrating DRM with <video>, though. (See the link
earlier in this email.) I also think that relying on NPAPI for
compatibility with services that require DRM is not sustainable.

> Only Henri spoke out.

I think others spoke less at the W3C mainly to avoid contradicting
what I said when others had spent less time to study the details of
the issue. That is, I don't think others should be considered to be at
fault for having spoken less.

> Part of the reason for not objecting was that TBL might do even worse, but not standing up to him is just spineless.

I have called TimBL on his bad arguments, in public:
http://lists.w3.org/Archives/Public/www-tag/2013Oct/0058.html . Jeff
Jaffe, too: http://www.w3.org/blog/2013/05/perspectives-on-encrypted-medi/#comment-13387
. A Formal Objection is something different, though. See earlier in
this email about that.

> Firefox could recognize media needing DRM decoding and launch a separate media player.

That wouldn't mean that users would be running a system free of DRM.
What's the win?

Also, such a system would not solve the problems that the proponents
of EME are seeking to solve. For example, a streaming service couldn't
write its own adaptive streaming logic in JavaScript and couldn't
write its own branded player controls in JavaScript.

A solution that doesn't satisfy those opposed to DRM (your proposal
still involves DRM!) and wouldn't satisfy the proponents of EME is no
solution at all.

On Fri, May 16, 2014 at 12:26 AM, Chris Peterson <cpet...@mozilla.com> wrote:
> If the CDM can run while completely sandboxed from network and file access,
> then it could be implemented in asm.js so the CDM.js would be portable
> across all browser platforms and architectures. :)
>
> I realize that obfuscation of closed-source code is probably easier with
> binary blobs than textual asm.js code, but maybe not much. That sounds like
> an interesting area of research.

I'd like to emphasize "research" as opposed to "viable solution for
movies in the near term".

This (non-exhaustive) list reasons why that wouldn't work should be
enough to explain why:

 * A Hollywood-approvable CDM needs to be resistant against
decompilers. asm.js does not have arbitrary jumps. To achieve proper
performance, emscripten uses decompilation techniques to rediscover
natural loops. You'd have to find a way to make asm.js code unnatural
and still performant.

 * You need to be able to solve node locking. An asm.js program has
less of an opportunity to examine the sandbox it is in than the Adobe
Access CDM will have to convince itself this is in the genuine
Mozilla-provided sandbox. (The Adobe CDM will Tivoize the
Mozilla-provided sandbox from the inside. I'm not aware of how to do
that convincingly with asm.js.)

 * The CDM needs to include an H.264 decoder. If the CDM is a JS
program provided by the site, shipping an H.264 decoder becomes the
site's problem. It's more convenient for streaming services to let
Someone Else to be the one who deals with shipping an H.264 decoder to
end users.

If someone wants to pursue this, I suggest pursuing streaming music
subscription with Opus or Vorbis instead of trying to tackle H.264
movies as the first item.

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

Thanks for the precise and comprehensive reply, Henri.

Nick

On Thu, May 15, 2014 at 8:39 PM, Majken Connor <maj...@gmail.com> wrote:
> A guide similar to the CEO FAQ would be great, as well as
> having people reach out on the Reps-General list to discuss how to talk

> about this and answer questions (not just about information on the topic)
> would be really helpful.

The FAQ is out now, appended to the Hacks post:
https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/20/2014 04:03 AM, Henri Sivonen wrote:

> On Thu, May 15, 2014 at 8:39 PM, Majken Connor <maj...@gmail.com>
> wrote:
>
>> A guide similar to the CEO FAQ would be great, as well as having
>> people reach out on the Reps-General list to discuss how to talk
>> about this and answer questions (not just about information on the
>> topic) would be really helpful.
>
> The FAQ is out now, appended to the Hacks post:
> https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme/

One part of this FAQ states:

> Mozilla will develop the CDM host and is planning on making its code
> open source as is the norm for Mozilla-developed code. However, the
> CDM will refuse to work if it finds itself in a host that isn’t
> identical to the Mozilla-shipped CDM host executable.

How will the CDM be able to tell?

If it is properly sandboxed, it should not be able to find out anything
about the sandbox (== the host executable) except what the sandbox
itself tells it, unless there are channels for it to access the host
system which bypass the sandbox.

If the CDM's only source for information about the sandbox is what the
sandbox tells it, then it should be possible to modify the sandbox to
always report what the CDM would expect to find from a "valid" sandbox,
regardless of what other changes may in fact have been made.

If the CDM has other sources for information about the sandbox, then the
CDM is not properly contained within the sandbox.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTe26qAAoJEASpNY00KDJr7j0QAKUs4GDC0HT0z3YlB9zrTFRR
qp0SWsHfDB3GckQyrdXkXtP7sPQKHR1ERBNw2BNczj0+gEGxtQB+QDqbRzcDonjt
XRhQjlTsJfP797eQ66Zafb4z3aV8H2NXGIVQXavMDg6PBF9zic81+75kDTwKn3jd
xcB1oAvWbrMfEMnzHxANqlkfDlfhV6+/+NSzfp4E6zQr9VjQ0mP7K4g7QHQuDWgp
btM5oJ5gDMGyqIn6IzFKKayjxtr2workTLObzPRnYiLEPEe+FRJ78nhcU+pRCHTl
x45uq8aozxU0+MLm8wC8NPtZWMJFKmZexQWU2kuyt0ScDC/MOZvBEc2UljqUk9dp
MzLKoiNda+TOGHGwJpqw1oEyxYyQ3sa4mq8Jr1Fjtv7rZzIOqdzdzX7pyLRKsrkY
rd0aWrziDn0ISwHOn+dnXsIMIvsSq8N0ywX8opn6xnDs90OfCrgORlTgz9ngV89i
Tx1eDOU7wwEdQf2PH9NH93wY4o0Ss/+rxXG2Wgoi15Abpcl3PlYoz2isIRr9Qztg
FWn+kalsQ/e51XcAS6M5IB1ytYzsEqhamPQopzs6IgMixt2Y+hFF0u9TChvl6NyK
CyKFcbv9xaVf8y2PEipt34obm/lKySTcJyTkZh8VxCWd7+u9KtIRP4Z4bnWOdCaI
nsu6q6B1a8m3ijzyHMZX
=YTI/
-----END PGP SIGNATURE-----

On 5/20/14, 11:03 AM, The Wanderer wrote:
> If it is properly sandboxed, it should not be able to find out anything
> about the sandbox (== the host executable) except what the sandbox
> itself tells it

A sandboxed process still have full access to its own address space, no?
  It may be restricted in terms of what system calls it can make, but
within itself it can do whatever it wants.

So if the CDM is running directly in the sandbox process address space
(as opposed to running in some sort of VM) then it can interrogate
things like the address space layout and compare it to the layout it
expects.

> unless there are channels for it to access the host
> system which bypass the sandbox.

Inspecting your own address space doesn't require access to the system.

-Boris

On 2014-05-20 18:51, Boris Zbarsky wrote:
> On 5/20/14, 11:03 AM, The Wanderer wrote:
>> If it is properly sandboxed, it should not be able to find out
>> anything
>> about the sandbox (== the host executable) except what the sandbox
>> itself tells it
>
> A sandboxed process still have full access to its own address space,
> no?  It may be restricted in terms of what system calls it can make,
> but within itself it can do whatever it wants.

No, if the CDM process has less privilege than the container then it
will not control the sandbox address space. The container can use memory
protection to return different values when reading versus executing the
sandbox code and can trap calls to the sandbox code to handle them
outside the sandbox.

You have still not proven your claim that the CDM will be robust, and
the FAQ states the fact that no streaming services currently accept it.
There is no basis to believe that services streaming big budget movies
will accept this as robust DRM. Mozilla will be able to use the lack of
acceptance of the CDM to justify a decision support other CDM's that
have privilege control of users computers, for all the same excuses.

Keep in mind that the contemporary web does not include DRM technology
and that the open web community reserves the right to add all and any
features to the open web, including to the EME. The open web community
does not recognize or accept the restrictions on their freedom to
innovate that the EME suggests and does not recognize the W3C or Mozilla
as being part of the open web community. All the deceptive propaganda
from the EME proponents and now Mozilla do not change this fact. People
should understand that there is a strong legal precedent for this
position and it will help if open web developers are persecuted. People
need to see that Mozilla are promoting the contrary view that, the web
has always included DRM, and that the EME/CDM is the same as a
proprietary plugin using a generic API, and understand that this
propaganda will damage this defense. Once this defense has been defeated
the gates will be open to add more DRM to the web, it is not a one-off
compromise as Mozilla management deceptively claim, it is a one-off
defeat of the contemporary web.  We need to stand up for the open web
now, and call out the Mozilla management for what they are doing, they
have no place in the open web community.

> So if the CDM is running directly in the sandbox process address space
> (as opposed to running in some sort of VM) then it can interrogate
> things like the address space layout and compare it to the layout it
> expects.
>
>> unless there are channels for it to access the host
>> system which bypass the sandbox.
>
> Inspecting your own address space doesn't require access to the system.

It certainly does require privilege over the system. Obfuscated code
could go some way to frustrating a container and to detect tampering,
but the sandbox is described as open source code and what defense does
it have?

Jim

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/20/2014 12:51 PM, Boris Zbarsky wrote:

> On 5/20/14, 11:03 AM, The Wanderer wrote:

>> If it is properly sandboxed, it should not be able to find out
>> anything about the sandbox (== the host executable) except what the
>> sandbox itself tells it
>
> A sandboxed process still have full access to its own address space,
> no? It may be restricted in terms of what system calls it can make,
> but within itself it can do whatever it wants.
>
> So if the CDM is running directly in the sandbox process address
> space (as opposed to running in some sort of VM) then it can
> interrogate things like the address space layout and compare it to
> the layout it expects.

Is it running that way?

I would have expected that each module involved - Firefox, the sandbox,
and the CDM - would be running as a separate process, with at least the
last one nested inside the previous. Although I'm not an expert on the
topic, I wouldn't have expected effective sandboxing of black-box code
to be practically possible any other way. (If there are resources on the
topic which I could use to educate myself on relevant principles, beyond
the glaringly obvious, I'd be glad to learn of them.)

>> unless there are channels for it to access the host system which
>> bypass the sandbox.
>
> Inspecting your own address space doesn't require access to the
> system.

Will that be enough? That is, is that (for practical purposes)
impossible to effectively fake?

I wouldn't intuitively expect it to be, but then, I wouldn't have
expected this to be predictable enough to base validation on in the
first place (assuming I understand what you mean by "address space
layout" - the same as is used in the term ASLR, address-space layout
randomization). It's possible I underestimate the difficulty of
intentionally producing the same inner-process address-space layout in
two different ways.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTfBZ2AAoJEASpNY00KDJrm5kP/0Ib4d39hOyi6NVXIbgKqDIV
yPOlJLzZ3Ip5yoxEKT4sDEca9c4bsedydcJn2BI6HLH9QwpMUXRq4sSm9h1IaudY
q7G9jOZJBTLPAVOuoMwN0PrG71ZKTdQ9jWWSFNs2XdxzyiWaXviZ1vjkTPUWkxNR
R/QcdZwNldx+5wum68juLgh6GI7wBKWb9nUS/IQGW5uc8Tp9OurZDJZAf2JvDkgM
8SCPplfNAw/BTJl/d6FLv0msuha1iGjdah6js0HICjQgulYMtXlbejd4gSiEAS5w
VX5LjwA5Ye7bgH0jwM/gs/uSvj8L+g5jbdNQuNXQ2FgeFBGlfG97g4yW/EkFMTwY
47cjylvWCCxjt5liUTGNcGqfIUemtpxYS13Q5yFgrxlHUcOwK2szZjLp38UpLy+Q
CxrSsPidurl8rRJwHPcPgj/IGmFS6iLoD4Z1WsviAKueuxaL4WqKQwhj51tlpAB0
PkYPBc7HEqRakw+Gj5wLknGjXJgeagA84zNuiY5x7s5rUcb/Gow6Zsrso0JU4A2t
yPXBLQgTM09HZbkHgJh7Cd6Dj6YxyFVcSuFCnX2/K3VhuPGej4claa1QyRKwUS9o
EzkNK7idcMUjEr+SXqNrUFSPkFv/DDg/axHfyX/9emSxblFbkIo5Pfpe2ZftVdcG
p8MlJehzHCiCBDobye+6
=8gIK
-----END PGP SIGNATURE-----

On 2014-05-18 07:49, Boris Zbarsky wrote:
> On 5/18/14, 12:51 AM, Jim wrote:
>> It does require that the JS component communicating with the CDM
>> via the EME is a standard. Netflix might refuse to support this
>> standard, but you could try.
>
> We've tried to get that part standardized, and failed.

Prove this claim.

Where is this claimed specification?

In which version of Firefox was this standard distributed to test the
market?

>> If you are sandboxing the CDM, and if the CDM only verifies that it is
>> running in this sandbox, then it should make no difference if it is
>> part
>> of a web browser or part of a dedicated media player, so it could be
>> re-purposed for use in such a media player.
>
> That's correct, as long as you use the same sandbox.
>
>> This would allow the DRM media player to be kept out of the web.
>
> This seems like a pretty arbitrary distinction: using a browser
> plug-in vs launching a helper app that does the same thing.  The end
> result is still DRM media on the web relying on the user having the
> DRM-enabled player.

It keeps DRM out of the open web standards by definition. The Internet
is not the web.

>> The web browser and DRM player are separate.
>
> Why is this particular bit important?  I genuinely don't understand
> why having web browser and an always-present DRM player is any
> different than just having the web browser include the player.

It keeps DRM out of the open web standards, a very significant point,
and a matter to be defended.

There are very real technical differences in the ability to sandbox a
separate DRM player versus an integrated web based media player. The
user would have more choice. There would be a healthy market for media
players that could meet the varying needs of users.

>> No DRM extensions would be added to web standards.
>
> That's happening no matter what we do...

There is an attempt to pass off the EME an open web standard, and
Mozilla have joined the propaganda war, but this does not make it so.

Jim

On 5/20/14, 10:59 PM, The Wanderer wrote:
> I would have expected that each module involved - Firefox, the sandbox,
> and the CDM - would be running as a separate process, with at least the
> last one nested inside the previous.

I'm not sure what you mean by nesting one process inside the other.

What's possible to do is to have a process start, drop privileges as
needed, then load a shared library (the CDM).  This is how typical
sandbox processes work.  But at that point the CDM is in fact running in
the (now low-privilege) process.

> I wouldn't have expected effective sandboxing of black-box code
> to be practically possible any other way. (If there are resources on the
> topic which I could use to educate myself on relevant principles, beyond
> the glaringly obvious, I'd be glad to learn of them.)

http://dev.chromium.org/developers/design-documents/sandbox#TOC-The-target-process
and
http://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design
are some resources for a commonly used sandbox.
http://en.wikipedia.org/wiki/Seccomp is another commonly used thing.

> Will that be enough? That is, is that (for practical purposes)
> impossible to effectively fake?

If it turns out that it's not, I expect the address space could contain
a digital signature of the expected address space with a key that the
CDM trusts.  The drawback is then that whoever is building the sandbox
binary needs to have one of the corresponding private keys (the CDM
would obviously contain the public keys).

-Boris

On 5/20/14, 11:19 PM, Jim wrote:
>> We've tried to get that part standardized, and failed.
>
> Prove this claim.

We explicitly requested the HTML working group to agree to take it on as
a deliverable.  They, and more importantly the other browser vendors
involved, refused.

> Where is this claimed specification?

There is no point writing a specification if you've already been told by
everyone involved that they have no plans to follow it.

> It keeps DRM out of the open web standards by definition.

This sounds to me like sweeping the problem under the rug more than
anything else, honestly.

There are good reasons to keep DRM out of web standards, but those
reasons are what's important, not the keeping out per se.

> It keeps DRM out of the open web standards, a very significant point,
> and a matter to be defended.

We agree on that, but that battle is long since lost no matter what we do.

> There are very real technical differences in the ability to sandbox a
> separate DRM player versus an integrated web based media player.

I'm not sure there are.

> The user would have more choice. There would be a healthy market for media
> players that could meet the varying needs of users.

This is very possible, yes.

-Boris

On 2014-05-21 05:35, Boris Zbarsky wrote:
> On 5/20/14, 11:19 PM, Jim wrote:
>>> We've tried to get that part standardized, and failed.
>>
>> Prove this claim.
>
> We explicitly requested the HTML working group to agree to take it on
> as a deliverable.  They, and more importantly the other browser
> vendors involved, refused.
>
>> Where is this claimed specification?
>
> There is no point writing a specification if you've already been told
> by everyone involved that they have no plans to follow it.

The parts of an EME based media player not specified are implemented in
JS/HTML making it an obvious target for a polyfill. Mozilla could have
promoted a standard that has a polyfill that will work on EME enabled
web browsers and could have refused to implement the EME on Firefox, and
this would have made this alternative standard the best option for
developers. There was a clear winning strategy here, yet Mozilla chose
not to fight, and by supporting the EME have destroyed this strategic
option and aided the opponents by covering their weakness. Malice or
incompetence?

>> It keeps DRM out of the open web standards by definition.
>
> This sounds to me like sweeping the problem under the rug more than
> anything else, honestly.
>
> There are good reasons to keep DRM out of web standards, but those
> reasons are what's important, not the keeping out per se.

I disagree. There are legal precedents in which the contemporary
environment wins cases. This is a weakness for the DRM proponents and
why give it up?

>> It keeps DRM out of the open web standards, a very significant point,
>> and a matter to be defended.
>
> We agree on that, but that battle is long since lost no matter what we
> do.

Mozilla could still win this battle, but needs to be much more
strategic, and needs to refuse to implement the EME.

>> There are very real technical differences in the ability to sandbox a
>> separate DRM player versus an integrated web based media player.
>
> I'm not sure there are.

It is trivially obvious. It is much easier for people to sandbox a
separate computing device, they can just disconnect it! Granted people
could use a separate computer to run a web based media player too, but
it needs to be more capable than a dedicated media decoder, and this
increases the barrier.

With a standard that supports a separate media player the user can
choose the tradeoffs between using an integrated player versus a
separate device. With the EME the user has less choice and thus less
control over their security and privacy.

Jim

On 2014-05-21, 1:30 AM, Jim wrote:
>>> There are very real technical differences in the ability to sandbox a
>>> separate DRM player versus an integrated web based media player.
>>
>> I'm not sure there are.
>
> It is trivially obvious. It is much easier for people to sandbox a
> separate computing device, they can just disconnect it!

Which separate device are you talking about?  As far as I understand,
before this email you were arguing that the DRMed content should run in
a different program on the user's machine that is separate from their
web browser, but integrated with the web page in a seamless way.

 > Granted people
> could use a separate computer to run a web based media player too, but
> it needs to be more capable than a dedicated media decoder, and this
> increases the barrier.

If the user indeed wants to run the DRM code on a separate computer for
some reason, they can already do so with what we're planning to
implement: they can refuse to run the CDM on their main machine the
first time we prompt them, and they can open up the page which triggered
the prompt on their other machine.

But do you really think people are going to want to run such code on a
different machine?  Please note that our users are already running DRM
code inside the Firefox process through the Flash and Silverlight
plugins, and I haven't heard of a large number of them moving away to
run the DRM in those plugins (which is not sandboxed today, so it's much
more dangerous than the sandboxed CDM) on a separate machine.

> With a standard that supports a separate media player the user can
> choose the tradeoffs between using an integrated player versus a
> separate device. With the EME the user has less choice and thus less
> control over their security and privacy.

Like I described above, this choice is given to the user through our
prompt before we run the CDM for the first time.  Please note that what
other browser engines have implemented thus far doesn't give their users
this choice because they do not show a similar prompt.  The EME spec in
itself doesn't specify anything to make it impossible to implement this
prompt and give the choice of running the CDM code to the user.

Cheers,
Ehsan

On Wed, May 21, 2014 at 8:30 AM, Jim <jimt...@openmailbox.org> wrote:
> The parts of an EME based media player not specified are implemented in
> JS/HTML making it an obvious target for a polyfill. Mozilla could have
> promoted a standard that has a polyfill that will work on EME enabled web
> browsers and could have refused to implement the EME on Firefox, and this
> would have made this alternative standard the best option for developers.
> There was a clear winning strategy here, yet Mozilla chose not to fight, and
> by supporting the EME have destroyed this strategic option and aided the
> opponents by covering their weakness. Malice or incompetence?

...

> I disagree. There are legal precedents in which the contemporary environment
> wins cases. This is a weakness for the DRM proponents and why give it up?

...

> It is trivially obvious. It is much easier for people to sandbox a separate
> computing device, they can just disconnect it!

"Use Chromecast" is not a position that makes sense for Mozilla to
adopt as the DRM solution--like "use another browser" isn't. Suppose
you want to watch a movie on a laptop while away from home. Where's
your TV and Chromecast then?

If I didn't look at the From field of the message I'm replying to, I'd
think I'm replying to Fred Andrews regarding his "IEME" on
public-restrictedmedia. A position *identical* with yours has been
discussed before.

Majken Connor schrieb:
> This is the kind of topic that Reps will be asked about.

Yes, I have already been strongly asked about this by the local FSFE
group, I expect more questions from more people to follow. And other
Reps will get that as well. If you are a Rep, please watch the townhall
carefully, it has a lot of good info.

KaiRo

Jim schrieb:

> You have still not proven your claim that the CDM will be robust

I think that can only be proven once the code exists, and it still to be
written. Once it's there, I'm sure everyone will be happy if you inspect
it for that robustness.

KaiRo

On 2014-05-21 16:03, Ehsan Akhgari wrote:
> On 2014-05-21, 1:30 AM, Jim wrote:
>>>> There are very real technical differences in the ability to sandbox
>>>> a
>>>> separate DRM player versus an integrated web based media player.
>>>
>>> I'm not sure there are.
>>

>> It is trivially obvious. It is much easier for people to sandbox a
>> separate computing device, they can just disconnect it!
>

> Which separate device are you talking about?  As far as I understand,
> before this email you were arguing that the DRMed content should run
> in a different program on the user's machine that is separate from
> their web browser, but integrated with the web page in a seamless way.

No, just that it could run on a separate device, a choice that the user
could make. If the user does not care for their security or privacy or
control over their computer then they can accept the use of an
integrated player. If the user wants an air-gap then they can use a
separate device. The proposal gives the user choice. There are a range
of options between these extremes and it creates a market for innovators
to meets the range of user needs.

In contrast the EME demands the use of a web browser and demands the use
of the distributors proprietary web base media player.

>> Granted people
>> could use a separate computer to run a web based media player too, but
>> it needs to be more capable than a dedicated media decoder, and this
>> increases the barrier.
>
> If the user indeed wants to run the DRM code on a separate computer
> for some reason, they can already do so with what we're planning to
> implement: they can refuse to run the CDM on their main machine the
> first time we prompt them, and they can open up the page which
> triggered the prompt on their other machine.

Sure, and I noted and accept this as one option. But the separate
computer needs to be much more capable, needs to support a web browser,
and the user must use the distributors proprietary web based media
player. It would be much harder to firewall such a flexible device,
whereas if the device had a very narrow definition then it could be
firewalled much more effectively. The EME is not good for the health of
the open web.

> But do you really think people are going to want to run such code on a
> different machine?  Please note that our users are already running DRM
> code inside the Firefox process through the Flash and Silverlight
> plugins, and I haven't heard of a large number of them moving away to
> run the DRM in those plugins (which is not sandboxed today, so it's
> much more dangerous than the sandboxed CDM) on a separate machine.

Yes, I can see manufacturers developing computers to meet such needs and
marketing their security and convenience. For example a computer with an
integrated DRM player that is isolated from the main computer, can be
switched of, or even removed. For example, cheap dongles for Linux
users. There would be a market, and innovation would meet user's needs.

>> With a standard that supports a separate media player the user can
>> choose the tradeoffs between using an integrated player versus a
>> separate device. With the EME the user has less choice and thus less
>> control over their security and privacy.
>
> Like I described above, this choice is given to the user through our
> prompt before we run the CDM for the first time.  Please note that
> what other browser engines have implemented thus far doesn't give
> their users this choice because they do not show a similar prompt.
> The EME spec in itself doesn't specify anything to make it impossible
> to implement this prompt and give the choice of running the CDM code
> to the user.

It does not give the user the choice to view the content on a device
without a web browser, or in a web browser with JS disabled.

It requires accepting DRM as a part of the open web.

At present the content owners have not accepted the Mozilla EME/CDM as
robust so it is not even viable.

Jim

On 2014-05-21 19:24, Henri Sivonen wrote:
> On Wed, May 21, 2014 at 8:30 AM, Jim <jimt...@openmailbox.org> wrote:
>> The parts of an EME based media player not specified are implemented
>> in
>> JS/HTML making it an obvious target for a polyfill. Mozilla could have
>> promoted a standard that has a polyfill that will work on EME enabled
>> web
>> browsers and could have refused to implement the EME on Firefox, and
>> this
>> would have made this alternative standard the best option for
>> developers.
>> There was a clear winning strategy here, yet Mozilla chose not to
>> fight, and
>> by supporting the EME have destroyed this strategic option and aided
>> the
>> opponents by covering their weakness. Malice or incompetence?
> ...
>> I disagree. There are legal precedents in which the contemporary
>> environment
>> wins cases. This is a weakness for the DRM proponents and why give it
>> up?
> ...

>> It is trivially obvious. It is much easier for people to sandbox a
>> separate
>> computing device, they can just disconnect it!
>

> "Use Chromecast" is not a position that makes sense for Mozilla to
> adopt as the DRM solution--like "use another browser" isn't. Suppose
> you want to watch a movie on a laptop while away from home. Where's
> your TV and Chromecast then?

If you value the security of your laptop and the content owner demands
robust DRM then you will not be able to watch a movie anyway.

If you do not value the security of your laptop then you can accept the
use of an integrated DRM media player.

The user has choices.

A healthy market for devices, including 'chromecast' like devices, could
be options. These devices could be integrated into laptops.

> If I didn't look at the From field of the message I'm replying to, I'd
> think I'm replying to Fred Andrews regarding his "IEME" on
> public-restrictedmedia. A position *identical* with yours has been
> discussed before.

This was the only counter proposal at the W3C. Glad someone was prepared
to put in an effort, Mozilla didn't. Was Fred a bad person? His last
message at the W3C was a complaint about assignation threats.

Jim

On 2014-05-21, 11:41 PM, Jim wrote:
> On 2014-05-21 16:03, Ehsan Akhgari wrote:
>> On 2014-05-21, 1:30 AM, Jim wrote:
>>>>> There are very real technical differences in the ability to sandbox a
>>>>> separate DRM player versus an integrated web based media player.
>>>>
>>>> I'm not sure there are.
>>>

>>> It is trivially obvious. It is much easier for people to sandbox a
>>> separate computing device, they can just disconnect it!
>>

>> Which separate device are you talking about?  As far as I understand,
>> before this email you were arguing that the DRMed content should run
>> in a different program on the user's machine that is separate from
>> their web browser, but integrated with the web page in a seamless way.
>
> No, just that it could run on a separate device, a choice that the user
> could make. If the user does not care for their security or privacy or
> control over their computer then they can accept the use of an
> integrated player. If the user wants an air-gap then they can use a
> separate device. The proposal gives the user choice. There are a range
> of options between these extremes and it creates a market for innovators
> to meets the range of user needs.
>
> In contrast the EME demands the use of a web browser and demands the use
> of the distributors proprietary web base media player.

I don't think anything in the EME spec technically mandates the video
being rendered inside the web browser process.  And I don't really
understand why mandating that would be any better or worse than the
current situation either.

>>> Granted people
>>> could use a separate computer to run a web based media player too, but
>>> it needs to be more capable than a dedicated media decoder, and this
>>> increases the barrier.
>>
>> If the user indeed wants to run the DRM code on a separate computer
>> for some reason, they can already do so with what we're planning to
>> implement: they can refuse to run the CDM on their main machine the
>> first time we prompt them, and they can open up the page which
>> triggered the prompt on their other machine.
>
> Sure, and I noted and accept this as one option. But the separate
> computer needs to be much more capable, needs to support a web browser,
> and the user must use the distributors proprietary web based media
> player. It would be much harder to firewall such a flexible device,
> whereas if the device had a very narrow definition then it could be
> firewalled much more effectively. The EME is not good for the health of
> the open web.

I don't really understand your line of reasoning here, sorry.  What are
you trying to protect against here?  If you're trying to protect the CDM
against violating the user's privacy at least in terms of contacting the
outside network or their security in terms of having access to the
system, the physical disk, etc., then it seems like sandboxing the CDM
which is what we're doing is a great step towards what you care about.
And please do note that the same CDM does currently run in Firefox
inside the Flash player plugin without the protection of a sandbox.  So
all of the risks you're worrying about is exactly what currently exists
on the web with or without EME.

>> But do you really think people are going to want to run such code on a
>> different machine?  Please note that our users are already running DRM
>> code inside the Firefox process through the Flash and Silverlight
>> plugins, and I haven't heard of a large number of them moving away to
>> run the DRM in those plugins (which is not sandboxed today, so it's
>> much more dangerous than the sandboxed CDM) on a separate machine.
>
> Yes, I can see manufacturers developing computers to meet such needs and
> marketing their security and convenience. For example a computer with an
> integrated DRM player that is isolated from the main computer, can be
> switched of, or even removed. For example, cheap dongles for Linux
> users. There would be a market, and innovation would meet user's needs.

I wish that we lived in the world you're describing here.  Sadly, I
disagree with you.  Most people don't care about running DRM software on
their machines right now, evidenced by the fact that most users are fine
with running Flash and Silverlight plugins both of which include DRM
software.

>>> With a standard that supports a separate media player the user can
>>> choose the tradeoffs between using an integrated player versus a
>>> separate device. With the EME the user has less choice and thus less
>>> control over their security and privacy.
>>
>> Like I described above, this choice is given to the user through our
>> prompt before we run the CDM for the first time.  Please note that
>> what other browser engines have implemented thus far doesn't give
>> their users this choice because they do not show a similar prompt.
>> The EME spec in itself doesn't specify anything to make it impossible
>> to implement this prompt and give the choice of running the CDM code
>> to the user.
>
> It does not give the user the choice to view the content on a device
> without a web browser, or in a web browser with JS disabled.

That comes by definition, EME being a Javascript Web spec.  :-)

> It requires accepting DRM as a part of the open web.

Yes, I agree that it does.  And I feel that situation sucks.

> At present the content owners have not accepted the Mozilla EME/CDM as
> robust so it is not even viable.

I don't know what the content owners think about our plans here, and to
the best of my knowledge nothing has been announced on that front yet,
so until that happens, I find this assertion premature.

Cheers,
Ehsan

> Jim schrieb:
>
>> You have still not proven your claim that the CDM will be robust

There's nothing to be gained from debating robustness here. Us
convincing you about robustness is entirely beside the point. What
matters is Adobe convincing streaming service operators that Adobe's
solution meets the robustness rules imposed on each streaming service
by the studios that supply the content.

It's fair for you to be skeptical about the viability of Firefox's
upcoming integration with Adobe Access when you haven't seen any
streaming provider say they'd use it yet. Mozilla disclosing the
integration makes it easier for Adobe to start convincing streaming
providers.

On Thu, May 22, 2014 at 3:44 AM, Robert Kaiser <ka...@kairo.at> wrote:
> I think that can only be proven once the code exists, and it still to be
> written. Once it's there, I'm sure everyone will be happy if you inspect it
> for that robustness.

It seems that you are probably unfamiliar with the word "robustness"
as a term-of-the-art in the DRM context. Robustness means the capacity
of the DRM implementation to resist attempts by the end-user to
examine or modify the state of the DRM black box.

On Thu, May 22, 2014 at 7:04 AM, Jim <jimt...@openmailbox.org> wrote:
> On 2014-05-21 19:24, Henri Sivonen wrote:
>>
>> On Wed, May 21, 2014 at 8:30 AM, Jim <jimt...@openmailbox.org> wrote:
>>>
>>> The parts of an EME based media player not specified are implemented in
>>> JS/HTML making it an obvious target for a polyfill. Mozilla could have
>>> promoted a standard that has a polyfill that will work on EME enabled web
>>> browsers and could have refused to implement the EME on Firefox, and this
>>> would have made this alternative standard the best option for developers.
>>> There was a clear winning strategy here, yet Mozilla chose not to fight,
>>> and
>>> by supporting the EME have destroyed this strategic option and aided the
>>> opponents by covering their weakness. Malice or incompetence?
>>
>> ...
>>>
>>> I disagree. There are legal precedents in which the contemporary
>>> environment
>>> wins cases. This is a weakness for the DRM proponents and why give it up?
>>
>> ...
>>>

>>> It is trivially obvious. It is much easier for people to sandbox a
>>> separate
>>> computing device, they can just disconnect it!
>>
>>

>> "Use Chromecast" is not a position that makes sense for Mozilla to
>> adopt as the DRM solution--like "use another browser" isn't. Suppose
>> you want to watch a movie on a laptop while away from home. Where's
>> your TV and Chromecast then?
>
>
> If you value the security of your laptop and the content owner demands
> robust DRM then you will not be able to watch a movie anyway.
>
> If you do not value the security of your laptop then you can accept the use
> of an integrated DRM media player.
>
> The user has choices.
>
> A healthy market for devices, including 'chromecast' like devices, could be
> options. These devices could be integrated into laptops.

I find it interesting that someone opposed to DRM would propose a
capitulation in the "war against general-purpose computing", which
integrating your DRM device to laptops would amount to. What Mozilla
announced isn't a capitulation in the "war against general-purpose
computing", though it would be fair to consider it as a very slippery
slope towards it.

>> If I didn't look at the From field of the message I'm replying to, I'd
>> think I'm replying to Fred Andrews regarding his "IEME" on
>> public-restrictedmedia. A position *identical* with yours has been
>> discussed before.
>
>
> This was the only counter proposal at the W3C. Glad someone was prepared to
> put in an effort, Mozilla didn't.

It was a remarkably bad proposal, since it failed to satisfy either
the opponents of DRM (the proposal still involved DRM!) or the
proponents of EME (the proposal failed to reuse the JS-programmable
HTML5 media facilities).

> Was Fred a bad person?

I don't have reason to believe so.

> His last message at
> the W3C was a complaint about assignation threats.

What Robin said was very inappropriate, but I think it didn't
constitute an actual assassination threat.

On 2014-05-22 02:44, Robert Kaiser wrote:
> Jim schrieb:
>> You have still not proven your claim that the CDM will be robust
>

> I think that can only be proven once the code exists, and it still to
> be written. Once it's there, I'm sure everyone will be happy if you
> inspect it for that robustness.

Enough details have been supplied to make it clear that the CDM has no
chance of being confident in the state that the sandbox supplies to it
when the sandbox passes control the the CDM.

The only protection offered to the CDM is that it can look over the
memory of the process it runs in. However the sandbox can change the
process memory after it is initialized and before the CDM is loaded and
run, so the CDM has no guarantee of the provenance of the state passed
to it from the sandbox when it starts. The idea that the CDM can check
that the sandbox code matches it's expectation to guarantee provenance
of the device identifier is flawed. If Mozilla can not even get this
right then I have no confidence that the CDM would be robust.

What is Mozilla going to do when Adobe are unable to convince content
owners and distributors that this is robust? Will Mozilla use the same
propaganda to justify supporting platform CDMs? Nothing Mozilla has said
suggests otherwise. Mozilla do not know where to draw the line.

What will Mozilla do if in future the content owners and distributors
withdraw support for the CDM, after the EME API has been well
established and after DRM APIs have been convincingly added to the open
web? Mozilla will have caused great damage and will be in an even weaker
position to fight.

All Mozilla will have done is nurture and promote the EME API, and in
doing so will have set back alternatives and damaged the open web.

Given that the CDM has no control there will be Firefox derivatives
offering control over device identifiers and able to save the content.
Are Mozilla going to support content owners and distributors if they
prosecute open web developers and distributors adding innovative
features to the open web, such as EME content saving functions? The
notion that Mozilla management would act as expert witnesses for the
prosecution, claiming that the open web supports DRM restrictions, is
just absurd given the mission. If this is what Mozilla management claim
then they do not represent the open web, they do not get to claim they
are part of the open web, and they do not get to claim they champion
user security and privacy.

What are Mozilla going to do when some CDM innovations allows HTTP
requests to be passed to the CDM and received and presented in the web
browser? This will effectively add DRM to any web content. The EME
solution requires JS to complete the player and this along with the DOM
gives all the flexibility to implement this. Add a JS engine to the CDM
and there goes even more of the web. Add HTML rendering support to the
CDM and it's game over, and Mozilla are making it happen.

Jim

On Sun, May 25, 2014 at 8:43 PM, Jim <jimt...@openmailbox.org> wrote:
> What are Mozilla going to do when some CDM innovations allows HTTP requests
> to be passed to the CDM and received and presented in the web browser? This
> will effectively add DRM to any web content. The EME solution requires JS to
> complete the player and this along with the DOM gives all the flexibility to
> implement this. Add a JS engine to the CDM and there goes even more of the
> web. Add HTML rendering support to the CDM and it's game over, and Mozilla
> are making it happen.

Statements like this makes it quite clear that you aren't trying to
have a constructive conversation. By now you should know that EME is
not mozilla's design, nor are we "making it happen".

If you want to suggest changes to EME, please make concrete proposals.
We definitely share your goal of not wanting DRM to spread to other
parts of the web stack, so any proposals towards that goal will
definitely be listened to. Whining will, however, not be.

/ Jonas

On 2014-05-27 08:34, Jonas Sicking wrote:
> On Sun, May 25, 2014 at 8:43 PM, Jim <jimt...@openmailbox.org> wrote:
>> What are Mozilla going to do when some CDM innovations allows HTTP
>> requests
>> to be passed to the CDM and received and presented in the web browser?
>> This
>> will effectively add DRM to any web content. The EME solution requires
>> JS to
>> complete the player and this along with the DOM gives all the
>> flexibility to
>> implement this. Add a JS engine to the CDM and there goes even more of
>> the
>> web. Add HTML rendering support to the CDM and it's game over, and
>> Mozilla
>> are making it happen.
>
> Statements like this makes it quite clear that you aren't trying to
> have a constructive conversation. By now you should know that EME is
> not mozilla's design, nor are we "making it happen".

Great, ignore all the technical challenges, accuse your opposition of
not engaging in a 'constructive conversation', and deny the facts.

The facts are:

* Mozilla is a paying member of the W3C publishing the EME
specification.

* Mozilla has a representative on the working group developing the EME.

* Mozilla has a representative on the high level W3C Technical
Architecture Group who considered the EME.

* Mozilla have formally supported EME all the way in formal W3C
decisions.

* Mozilla have made no objections with any standing to the EME at the
W3C.

* Mozilla did not speak out when the W3C started joking about
assassinating EME dissenters.

* The W3C is controlled by MIT. Only MIT members can be appointed as the
W3C directors and the W3C director has the final say. The current W3C
director's statements are very supportive of the EME and DRM, yet he
claims to champion the web-web-want[sic].

* Mozilla has recently appointed a new director with close ties to MIT
who also claims to be supportive of the open web.

* Mozilla have pre-announced their implementation of the EME.

* Mozilla have partnered with Adobe to promote Adobe's EME-CDM.

* The Adobe's-CDM-in-Mozilla's-sandbox solution has not been defended as
robust, and is not supported by any content owners or distributors.
There is good reason to believe it will not be widely accepted by
content owners.

* Mozilla have refused to address questions about what they will do if
their sandbox/CDM is not widely accepted?  It's a slippery slope and
Mozilla have not drawn a line and we see where this is going.

> If you want to suggest changes to EME, please make concrete proposals.
> We definitely share your goal of not wanting DRM to spread to other
> parts of the web stack, so any proposals towards that goal will
> definitely be listened to. Whining will, however, not be.

* Mozilla have refused to engage in constructive discussion of EME
alternatives!

Jim

Jim schrieb:

> Great, ignore all the technical challenges, accuse your opposition of
> not engaging in a 'constructive conversation', and deny the facts.

You will be happier once you give others the benefit of the doubt and
assume they think about what they are doing themselves as well. Relax
and give others a chance to prove they can do what they say. Don't
assume the negative in everyone else, just let them the room to try and
make it actually positive. They will be happier, and so will you.

KaiRo

On Wed, May 28, 2014 at 02:03:17AM +0200, Jim wrote:
> On 2014-05-27 08:34, Jonas Sicking wrote:
> >On Sun, May 25, 2014 at 8:43 PM, Jim <jimt...@openmailbox.org> wrote:
> >>What are Mozilla going to do when some CDM innovations allows HTTP
> >>requests
> >>to be passed to the CDM and received and presented in the web browser?
> >>This
> >>will effectively add DRM to any web content. The EME solution requires
> >>JS to
> >>complete the player and this along with the DOM gives all the
> >>flexibility to
> >>implement this. Add a JS engine to the CDM and there goes even more of
> >>the
> >>web. Add HTML rendering support to the CDM and it's game over, and
> >>Mozilla
> >>are making it happen.
> >
> >Statements like this makes it quite clear that you aren't trying to
> >have a constructive conversation. By now you should know that EME is
> >not mozilla's design, nor are we "making it happen".
>

> Great, ignore all the technical challenges, accuse your opposition of not
> engaging in a 'constructive conversation', and deny the facts.
>

> The facts are:
>
> * Mozilla is a paying member of the W3C publishing the EME specification.
>
> * Mozilla has a representative on the working group developing the EME.
>
> * Mozilla has a representative on the high level W3C Technical Architecture
> Group who considered the EME.
>
> * Mozilla have formally supported EME all the way in formal W3C decisions.
>
> * Mozilla have made no objections with any standing to the EME at the W3C.

its already been explained a number of times why the W3C is the wrong
place to fight, but here it is again.  IE / Chrome / Safari are clearly
going to ship EME implementations whatever happens at the W3C.

> * Mozilla did not speak out when the W3C started joking about assassinating
> EME dissenters.
>
> * The W3C is controlled by MIT. Only MIT members can be appointed as the W3C
> directors and the W3C director has the final say. The current W3C director's
> statements are very supportive of the EME and DRM, yet he claims to champion
> the web-web-want[sic].
>
> * Mozilla has recently appointed a new director with close ties to MIT who
> also claims to be supportive of the open web.
>
> * Mozilla have pre-announced their implementation of the EME.
>
> * Mozilla have partnered with Adobe to promote Adobe's EME-CDM.
>
> * The Adobe's-CDM-in-Mozilla's-sandbox solution has not been defended as
> robust, and is not supported by any content owners or distributors. There is
> good reason to believe it will not be widely accepted by content owners.

So you think Adobe is in this because they want to be charitable by
giving out DRM software nobody will use?  If you believe that I have
some very high quality bridges I think you might be interested in.

> * Mozilla have refused to address questions about what they will do if their
> sandbox/CDM is not widely accepted?  It's a slippery slope and Mozilla have
> not drawn a line and we see where this is going.
>
> >If you want to suggest changes to EME, please make concrete proposals.
> >We definitely share your goal of not wanting DRM to spread to other
> >parts of the web stack, so any proposals towards that goal will
> >definitely be listened to. Whining will, however, not be.
>
> * Mozilla have refused to engage in constructive discussion of EME
> alternatives!

 No, people have explained why those alternatives are no better.  It
 seems to me if you decide that you are going to keep Netflix working
 without Silverlight then you have to add something to the web that
 allows DRM.  Whatever you add to the web to support DRM will
 practically only be useful for DRM because everything else people want
 in a media API is already available.  So if you want Netflix to keep
 working you can either accept EME or you can try to put more lipstick
 on the pig, but it'll still be a pig.

 Trev

>
> Jim

On 27/05/14 17:03, Jim wrote:
> * Mozilla is a paying member of the W3C publishing the EME specification.

<snip lots of other comments about Mozilla and the W3C>

The position Mozilla has been put in with respect to DRM and EME has
very, very little to do with the fact that EME is in the W3C process.

Gerv