Closed Bug 1024763 Opened 10 years ago Closed 10 years ago

RFE: mozconfig option to build application without any HTML5 DRM support

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1038031

People

(Reporter: kevink9876543, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30a1
Build ID: 20140612151704

Please add a (non-default) mozconfig option such that if set, the application being built will not contain any support for HTML5 DRM at all.
As Gecko's DRM support does not look like it is going to be implemented as a default-installed extension or NPAPI plugin, it seems right now that it won't be possible to completely remove DRM support without somewhat aimlessly gutting large chunks of the source code and hoping the result works at all.

I would like this feature because as discussed in bug 923590, DRM necessarily means rootkits, and I am not comfortable with a browser, which will necessarily download and run/display stuff from untrusted sources, having the possibility of such direct access to that level of control over my system.

If it is not possible or reasonable to add this feature, could someone please provide documentation on exactly what source files to delete and what (if any) source files would need to be changed in order to completely remove HTML5 DRM support?  (As indicated by the above User-Agent string, I would be working with SeaMonkey source code.)
I'm not sure which bug will be adding EME to the build system. Certainly not this one. This request belongs there.

That being said, it is standard procedure for us to introduce configure flags for new features like EME. Furthermore, given the controversy over EME and the desire of some to exclude it, I'm pretty sure the feature will be behind a build-time flag without you needing to ask. If the review lands on my plate and I don't see a configure flag, I will definitely try to get it added.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
> As Gecko's DRM support does not look like it is going to be implemented as a
> default-installed extension or NPAPI plugin

It's going to be a plugin using a new plugin API.  And it will not run any DRM anything without explicit permission from the user...
(In reply to Boris Zbarsky [:bz] from comment #2)
> > As Gecko's DRM support does not look like it is going to be implemented as a
> > default-installed extension or NPAPI plugin
> 
> It's going to be a plugin using a new plugin API.  And it will not run any
> DRM anything without explicit permission from the user...

And that is an improvement over the status quo with NPAPI support.
Thanks for the explanations.  That sounds better than I thought, but I still don't quite see my request as unnecessary.
Are you saying that in packaged application builds, this plugin will be a single file, which if I were to delete I would thereby be completely and permanently removing HTML5 DRM support and the rootkit capabilities it comes with, without breaking other things?
I'm not sure whether I would mind the stub of the APIs being left behind, so long as there is no additional opportunity for rootkits that wasn't there before DRM support.  And anyway, at that point isn't it possible to effectively zap the API stubs using Object.defineProperty() from an addon?

(Per gps' response I re-filed this request on bug 1016162.)
Kevin, please note that Firefox has supported DRM through NPAPI plugins such as Flash and Silverlight for years.  But because those plugins are also used for other purposes we could not restrict their usage without the user consent as it would break a lot of websites.  With the new system being implemented in bug 1016162, we now have the opportunity to prompt the user before any DRM code gets executed, which is a great improvement over the existing system, so if you're worried about running code that you don't trust, that should give you all you need.  Also note that contrary to the way that we currently run Flash and Silverlight, the DRM plugin, once the user has consented to run it, will run in a sandbox which will not have access to your system (things such as the file system, other processes running on your system, etc.) so even if the user consents to run the DRM plugin, it will be far less risky than running the DRM code that already exists in Flash and Silverlight.
My primary concern isn't exactly about running untrusted code; it's about the privilege level with which this plugin, its components, and/or the untrusted code will run, independently of any sandboxing.  Let me make sure I have this straight:
 - Even in default configuration, the new plugin will *never* run at all without me explicitly allowing it each time.
 - There is nothing the new plugin can do that NPAPI plugins like Flash can't, and there is a sandbox to make serious exploits less likely.

I'm still not clear on one thing though.  Will my system get rootkit just from simply having installed a Gecko-based browser which supports HTML5 DRM on my computer?  Or would I actually have to run the plugin on protected media to get rootkit?


I also have a secondary concern about preserving the open nature of the Web...
> Are you saying that in packaged application builds, this plugin will be a single file

In packaged application builds, this plugin would not exist, I expect.  It would be a separate download (possibly performed by Firefox itself in the background after it's installed).

> the new plugin will *never* run at all without me explicitly allowing it each time

It will never run at all without you allowing it the first time.

I can't speak to the exact UX flow after that point, but it seems like a perfectly reasonable request to basically have a three-state preference: "ask", "run", "not run", with the default value being "ask" and the user-facing UI allowing the user to say "run now", "run now and don't ask me again", "don't run", "don't run and don't ask me again" in some form.  That's something we should figure out with the UX folks.

Certainly supporting a hidden "not run" preference should be perfectly doable no matter what.

> There is nothing the new plugin can do that NPAPI plugins like Flash can't

I think this is pretty much true by default, since existing NPAPI plugins can do whatever they want to do, since typically they are installed by an administrator and can add whatever administrator-level stuff they want at install time.

> Will my system get rootkit just from simply having installed a Gecko-based browser
> which supports HTML5 DRM on my computer? 

No.

> Or would I actually have to run the plugin on protected media to get rootkit?

I'm not sure why you think there is a rootkit involved at all.  Do you think Flash and Sliverlight come with a rootkit?
> I'm not sure why you think there is a rootkit involved at all.  Do you think
> Flash and Sliverlight come with a rootkit?

I would say that the DRM bits of those are indistinguishable from malware certainly.  As for an actual rootkit probably not, but it has happen I imagine you know of http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal .

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #5)
> Kevin, please note that Firefox has supported DRM through NPAPI plugins such

supported feels like a strong description, I'd say allowed, but I'm not going to hold it against you ;-)

> as Flash and Silverlight for years.  But because those plugins are also used
> for other purposes we could not restrict their usage without the user

Well, the real issue is that we gave people a way to do arbitrary things, and that pretty inherantly means allowing them to do evil things, unless you've invented an evil detector.

> consent as it would break a lot of websites.  With the new system being
> implemented in bug 1016162, we now have the opportunity to prompt the user
> before any DRM code gets executed, which is a great improvement over the
> existing system, so if you're worried about running code that you don't
> trust, that should give you all you need.  Also note that contrary to the
> way that we currently run Flash and Silverlight, the DRM plugin, once the
> user has consented to run it, will run in a sandbox which will not have

the unfortunate part of this is that it makes it harder to write a open source plugin that is the Sandboxing the plugin is certainly the less bad thing to do, but it makes me kind of sad that it also makes it hard to write a plugin that just grabs the encryption key from wikipedia.

> access to your system (things such as the file system, other processes
> running on your system, etc.) so even if the user consents to run the DRM

you saw http://openwall.com/lists/oss-security/2014/06/05/24 right?a sandbox certainly makes it harder, but building a sandbox without any flaws is hard :(
(In reply to Trevor Saunders (:tbsaunde) from comment #8)
> > I'm not sure why you think there is a rootkit involved at all.  Do you think
> > Flash and Sliverlight come with a rootkit?
> 
> I would say that the DRM bits of those are indistinguishable from malware
> certainly.

Not sure what you mean here.  You can replace "DRM bits" with the name for any software here, including Firefox, and that sentence will remain technically true I guess.  The point here is, implementing EME would decrease the risk of a rootkit in the DRM code that we run if anything.

> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #5)
> > Kevin, please note that Firefox has supported DRM through NPAPI plugins such
> 
> supported feels like a strong description, I'd say allowed, but I'm not
> going to hold it against you ;-)

No, let's be honest here.  It _has_ been supported.

> > consent as it would break a lot of websites.  With the new system being
> > implemented in bug 1016162, we now have the opportunity to prompt the user
> > before any DRM code gets executed, which is a great improvement over the
> > existing system, so if you're worried about running code that you don't
> > trust, that should give you all you need.  Also note that contrary to the
> > way that we currently run Flash and Silverlight, the DRM plugin, once the
> > user has consented to run it, will run in a sandbox which will not have
> 
> the unfortunate part of this is that it makes it harder to write a open
> source plugin that is the Sandboxing the plugin is certainly the less bad
> thing to do, but it makes me kind of sad that it also makes it hard to write
> a plugin that just grabs the encryption key from wikipedia.

I have difficulty parsing this sentence, but to be clear, our sandboxing code will be open source.  The DRM component will obviously not, as it's not provided by Mozilla.  Not sure what the bit about grabbing encryption keys from wikipedia means.

> > access to your system (things such as the file system, other processes
> > running on your system, etc.) so even if the user consents to run the DRM
> 
> you saw http://openwall.com/lists/oss-security/2014/06/05/24 right?a sandbox
> certainly makes it harder, but building a sandbox without any flaws is hard
> :(

Of course, there is no magic here.  All I said was that the new DRM support being implemented will be more secure than the existing one, and therefore an improvement on the status quo.
(In reply to Boris Zbarsky [:bz] from comment #7)
> In packaged application builds, this plugin would not exist, I expect.  It
> would be a separate download (possibly performed by Firefox itself in the
> background after it's installed).
Then this RFE is very much necessary.  I can't have my browser downloading things like that without my explicit consent, no matter how "safe" the source and the content being downloaded are.

> Certainly supporting a hidden "not run" preference should be perfectly
> doable no matter what.
If by "hidden" you mean "only in about:config", and "not run" also implies "not download", please do that as well.

> I'm not sure why you think there is a rootkit involved at all.  Do you think
> Flash and Sliverlight come with a rootkit?
Well, Flash *did* require me to enter my admin password when I installed it...
And as tbsaunde said, DRM has come with rootkits before, and I can't trust that the sandbox will be perfect.

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #9)
> The point here is, implementing EME would
> decrease the risk of a rootkit in the DRM code that we run if anything.
This is *not* only about the code coming from arbitrary webpages.  It's also about the code that makes up this plugin itself and the related code in the browser itself.
> I can't have my browser downloading things like that without my explicit consent

That's a UX issue, right?  We could prompt before downloading, based on a configuration setting.  That doesn't involve configure-level changes.

> If by "hidden" you mean "only in about:config"

Yes.
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #9)
> (In reply to Trevor Saunders (:tbsaunde) from comment #8)
> > > I'm not sure why you think there is a rootkit involved at all.  Do you think
> > > Flash and Sliverlight come with a rootkit?
> > 
> > I would say that the DRM bits of those are indistinguishable from malware
> > certainly.
> 
> Not sure what you mean here.  You can replace "DRM bits" with the name for
> any software here, including Firefox, and that sentence will remain

technically sure, in any practical sense there's a huge gap between open source code you can modify and code that has deliberately been made hard to control, and to do things you don't want.

> technically true I guess.  The point here is, implementing EME would
> decrease the risk of a rootkit in the DRM code that we run if anything.

sure, if you are going to run DRM code you are more secure, I'm just saying if you care about security you shouldn't run any kind of DRM code.

> > (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> > #5)
> > > Kevin, please note that Firefox has supported DRM through NPAPI plugins such
> > 
> > supported feels like a strong description, I'd say allowed, but I'm not
> > going to hold it against you ;-)
> 
> No, let's be honest here.  It _has_ been supported.

I'm not sure if we have or have not helped there be DRM bits in flash or silverlight, but I'd certainly say we shouldn't have helped with that.  If you just mean the video bits that's clearly true and ok, while there was no real <video>.

> > > consent as it would break a lot of websites.  With the new system being
> > > implemented in bug 1016162, we now have the opportunity to prompt the user
> > > before any DRM code gets executed, which is a great improvement over the
> > > existing system, so if you're worried about running code that you don't
> > > trust, that should give you all you need.  Also note that contrary to the
> > > way that we currently run Flash and Silverlight, the DRM plugin, once the
> > > user has consented to run it, will run in a sandbox which will not have
> > 
> > the unfortunate part of this is that it makes it harder to write a open
> > source plugin that is the Sandboxing the plugin is certainly the less bad
> > thing to do, but it makes me kind of sad that it also makes it hard to write
> > a plugin that just grabs the encryption key from wikipedia.
> 
> I have difficulty parsing this sentence, but to be clear, our sandboxing

yeah, I failed to notice I hadn't actually deleted all the stuff before the comma.

> code will be open source.  The DRM component will obviously not, as it's not
> provided by Mozilla.  Not sure what the bit about grabbing encryption keys
> from wikipedia means.

What I'm saying is this, it would be better if the DRM plugin was sandboxed, but we had a setup for non sandboxed open source plugins too.  That way someone could say write a not DRM plugin that grabs keys from some site on the internet, and then pretend to be the DRM plugin.

> > > access to your system (things such as the file system, other processes
> > > running on your system, etc.) so even if the user consents to run the DRM
> > 
> > you saw http://openwall.com/lists/oss-security/2014/06/05/24 right?a sandbox
> > certainly makes it harder, but building a sandbox without any flaws is hard
> > :(
> 
> Of course, there is no magic here.  All I said was that the new DRM support
> being implemented will be more secure than the existing one, and therefore
> an improvement on the status quo.

right, I agree with you on that, what I think we disagree about is if supporting there being DRM software in the world is an ok thing to do.
(In reply to Trevor Saunders (:tbsaunde) from comment #12)
> What I'm saying is this, it would be better if the DRM plugin was sandboxed,
> but we had a setup for non sandboxed open source plugins too.  That way
> someone could say write a not DRM plugin that grabs keys from some site on
> the internet, and then pretend to be the DRM plugin.
@tbsaunde: I appreciate your support, but so that this bug will stay coherent, please try to stay on topic here.  I don't see what this has to do with my original request for a mozconfig option to build applications without HTML5 DRM / EME (and therefore also without the feature you're talking about).
(In reply to comment #11)
> > I can't have my browser downloading things like that without my explicit consent
> 
> That's a UX issue, right?  We could prompt before downloading, based on a
> configuration setting.  That doesn't involve configure-level changes.

Also, I'm curious to know, are you making the distinction of downloading code and storing it around in a non-executable format vs storing it in an executable format?  IOW, which would you like to prevent against, the act of *downloading* the bits even if you know they will never be executed without your consent or the act of *executing* the downloaded bits without your consent?
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #14)
> which would you like to prevent against, the act of
> *downloading* the bits even if you know they will never be executed without
> your consent or the act of *executing* the downloaded bits without your
> consent?
Both, each individually.  So there would ideally be one prompt before downloading (with a "Remember my choice and don't ask me again" checkbox that corresponds to setting about:config preference(s)) and another prompt before executing (as mentioned earlier).
(In reply to comment #15)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #14)
> > which would you like to prevent against, the act of
> > *downloading* the bits even if you know they will never be executed without
> > your consent or the act of *executing* the downloaded bits without your
> > consent?
> Both, each individually.  So there would ideally be one prompt before
> downloading (with a "Remember my choice and don't ask me again" checkbox that
> corresponds to setting about:config preference(s)) and another prompt before
> executing (as mentioned earlier).

I am not a UX guys so I can't speak to what we'll do exactly but I doubt we'll do what you're asking for here.  Prompting the user for a download that is happening in the background doesn't make much sense and it makes for a pretty terrible experience.
Looks like this has been done in bug 1038031
Resolution: INCOMPLETE → DUPLICATE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.