1458498 - Option "devtools.enabled = false" is not persisted

Status: VERIFIED INVALID

(DevTools :: General, defect)

Description

[AuroraBorealis]

The option "devtools.enabled" gets enabled after a restart of firefox, despite of the fact that it was disabled via about:config or set to false in prefs.js, i.e. devtools are always enabled!

Comment 1

[:Gijs (he/him)]

Not a security issue.

Julian, looks like this is intentional per https://dxr.mozilla.org/mozilla-central/source/devtools/startup/preferences/devtools-startup.js#21-26, and you have blame for those lines - can you clarify what the expected behavior is here?

Comment 2

[Julian Descottes [:jdescottes]]

Thanks for forwarding Gijs, will try to answer as I can!

devtools.enabled is not intended as an API to disable devtools. It is not a feature in itself, but used as part of a bigger feature that is currently tested as a shield study. I don't think anyone should rely on the implementation details that follow but here is the current status:
- if user is not part of shield study -> always enable devtools, flip the preference to true
- if user is in shield study
  - if user has already used devtools (tested with another pref related to console usage) -> flip preference to true
  - if user has never used devtools -> keep preference to false

If users want to disable devtools, there is another preference `devtools.policy.disabled` which will completely disable devtools, no matter what. Although again this preference is not a feature or an exposed API and we might change names/values/behaviors without prior notice.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1440675 for potential changes impacting both preferences.

Closing.

Comment 3

[AuroraBorealis]

(In reply to Julian Descottes [:jdescottes][:julian] from comment #2)
> Thanks for forwarding Gijs, will try to answer as I can!
> 
> devtools.enabled is not intended as an API to disable devtools. It is not a
> feature in itself, but used as part of a bigger feature that is currently
> tested as a shield study. I don't think anyone should rely on the
> implementation details that follow but here is the current status:
> - if user is not part of shield study -> always enable devtools, flip the
> preference to true
> - if user is in shield study
>   - if user has already used devtools (tested with another pref related to
> console usage) -> flip preference to true
>   - if user has never used devtools -> keep preference to false
> 
> If users want to disable devtools, there is another preference
> `devtools.policy.disabled` which will completely disable devtools, no matter
> what. Although again this preference is not a feature or an exposed API and
> we might change names/values/behaviors without prior notice.
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=1440675 for potential
> changes impacting both preferences.
> 
> Closing.

Dear all,

> devtools.policy.disabled

this option is not available in firefox version 59.x and lower. The only solution for this behaviour in firefox v. 59.x and lower is to set `devtools.onboarding.experiment` to `on`.

> the expected behavior

For an ordinary firefox user, which is by definition not a software developer, I guess that the expected behavior is based on the following common use cases:

After installation: DevTools are disabled

Activation: If the user enables the devtools via the menu, the activation is only valid for the current session.

Permanent activation: The user has to set the option `devtools.enabled` to `true`

The extraordinary names of the current devtools options `devtools.onboarding.experiment` are confusing for an unexperienced user. Nobody looks in the `devtools-startup.js` file to get an imagination what the consequences are, if a specific option is enabled. A simplification of the names based on common semantic rules increases user acceptance and security as well.

> Not a security issue

Au contrair, mes amis.
We discovered a security vulnerability in firefox 59.x on Windows which can only be used when devtools are enabled. The analysis for the security vulnerability is going on and we are currently not able to provide details. What we currently know: only with disabled devtools the security vulnerability is gone. The security vulnerability allows remote code execution with elevated privileges.

We will provide new information asap. We furthermore will issue a security warning.

Comment 4

[:Gijs (he/him)]

(In reply to AuroraBorealis from comment #3)
> > Not a security issue
> 
> Au contrair, mes amis.
> We discovered a security vulnerability in firefox 59.x

Obviously we will be very interested in more details, in a separate, security-sensitive bugreport. Even partial information (e.g. steps to reproduce the issue) without the full analysis would be helpful. I'm assuming you're also testing the soon-to-be-released Firefox 60 (see https://beta.mozilla.org/ ) and current development builds (Nightly; https://nightly.mozilla.org/ ) ?

> on Windows which can
> only be used when devtools are enabled.

But just the naming of prefs and whether they can disable devtools is not in and of itself a security issue. Confusing, certainly, but not a security issue to which only very few people get access. Hence removing the marker, so the issue is visible to the entire community and can be triaged appropriately.

Comment 5

[AuroraBorealis]

(In> reply to :Gijs (he/him; out 3-8 May) from comment #4)
> (In reply to AuroraBore>alis from comment #3)
> > > Not a security issue
> > 
> > Au contrair, mes amis.
> > We discovered a security vulnerability in firefox 59.x
> 
> Obviously we will be very interested in more details, in a separate,
> security-sensitive bugreport. Even partial information (e.g. steps to
> reproduce the issue) without the full analysis would be helpful. I'm
> assuming you're also testing the soon-to-be-released Firefox 60 (see
> https://beta.mozilla.org/ ) and current development builds (Nightly;
> https://nightly.mozilla.org/ ) ?
> 
> > on Windows which can
> > only be used when devtools are enabled.
> 
> But just the naming of prefs and whether they can disable devtools is not in
> and of itself a security issue. Confusing, certainly, but not a security
> issue to which only very few people get access. Hence removing the marker,
> so the issue is visible to the entire community and can be triaged
> appropriately.


> Obviously we will be very interested in more details, in a separate, security-sensitive bugreport.

As I explained before, we will not provide any details until the analysis is finished.

> I'm assuming you're also testing the soon-to-be-released Firefox 60

No, I get paid for software development for our software products and not for firefox testing. The bug we discovered was the result of a company internal security analysis for existing “gaps in the wall”. In that context we developed a monitoring framework for the intranet. This monitoring framework was used to discover the intrusion details for the specific application under test.

> But just the naming of prefs and whether they can disable devtools is not in and of itself a security issue

In that specific context, where an unspecified security vulnerability may exist in the devtools modules, the naming confusion becomes itself a security issue. If the ordinary firefox user has no chance to identify the option for disabling the devtools (based on about:config), then the firefox users computer security and privacy is at risk. Another example from the real world: a label on a bottle claims “good for your eyes”, but inside the bottle is a toxic acid! 

Confusion, no matter where it is produced, is a security issue.

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to AuroraBorealis from comment #5)
> > But just the naming of prefs and whether they can disable devtools is not in and of itself a security issue
> 
> In that specific context, where an unspecified security vulnerability may
> exist in the devtools modules, the naming confusion becomes itself a
> security issue. If the ordinary firefox user has no chance to identify the
> option for disabling the devtools (based on about:config), then the firefox
> users computer security and privacy is at risk. Another example from the
> real world: a label on a bottle claims “good for your eyes”, but inside the
> bottle is a toxic acid! 
> 
> Confusion, no matter where it is produced, is a security issue.

Prefs serve many different purposes and meanings in Firefox.  A pref might do nothing or something opposite what it says.  It is an arbitrary data store.  This is why about:config shows a warning when it is first opened: it is not meant for the general user and you could open security holes by changing them.

Users should interact with higher level settings layers, like the about:preferences UI, the DevTools options panel, the enterprise policy system, etc. which have clear(er) use cases and expectations.

Bug 1429185 added the first true feature for disabling DevTools via enterprise policy in Firefox 60.  Before that version, no such feature exists, despite what curiously named prefs may suggest.

Comment 7

[AuroraBorealis]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #6)
> (In reply to AuroraBorealis from comment #5)
> > > But just the naming of prefs and whether they can disable devtools is not in and of itself a security issue
> > 
> > In that specific context, where an unspecified security vulnerability may
> > exist in the devtools modules, the naming confusion becomes itself a
> > security issue. If the ordinary firefox user has no chance to identify the
> > option for disabling the devtools (based on about:config), then the firefox
> > users computer security and privacy is at risk. Another example from the
> > real world: a label on a bottle claims “good for your eyes”, but inside the
> > bottle is a toxic acid! 
> > 
> > Confusion, no matter where it is produced, is a security issue.
> 
> Prefs serve many different purposes and meanings in Firefox.  A pref might
> do nothing or something opposite what it says.  It is an arbitrary data
> store.  This is why about:config shows a warning when it is first opened: it
> is not meant for the general user and you could open security holes by
> changing them.
> 
> Users should interact with higher level settings layers, like the
> about:preferences UI, the DevTools options panel, the enterprise policy
> system, etc. which have clear(er) use cases and expectations.
> 
> Bug 1429185 added the first true feature for disabling DevTools via
> enterprise policy in Firefox 60.  Before that version, no such feature
> exists, despite what curiously named prefs may suggest.


> A pref might do nothing or something opposite what it says

Only excuses!
Not a peace of responsibility for the user’s legitimate security and privacy needs. But in the end you’re responsible for every single item of the firefox framework that violates the user’s security and privacy: no escape with whatsoever formed excuse.

Do you remember the claim that firefox displays when the user has disabled the devtools and presses the F12 button? Probably not!

Here a reminder: “Die Entwicklerwerkzeuge von Firefox sind standardmäßig deaktiviert, um Ihnen mehr Kontrolle über Ihren Browser zu belassen.”

What is from your point of view the difference between this claim and the reality in firefox 59.x?

Please avoid excuses in your answer.

Comment 8

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

In Firefox 59, the only way to see such a screen about disabling is via setting a pref manually or perhaps through a Shield Study experiment.  Since these are not long-term supported configurations in this version, there's nothing to do, as Julian and Gijs also concluded earlier in this bug.

In Firefox 60, there is a mechanism for disabling DevTools that is supported (enterprise policy).  If there is a problem with that supported configuration, please file a bug so that it can be investigated.

I would also suggest reviewing the Bugzilla etiquette page[1].  It seems clear that you disagree with the answers we're providing here, but I also don't see any new evidence to suggest that a different action should be taken in this bug.

[1]: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html