1540065 - Make about:config access configurable via runtime settings

Status: RESOLVED FIXED

(GeckoView :: General, enhancement, P3)

Description

[Jan Henning [:JanH]]

There might be embedders that legitimately don't want to expose this, but in the general case I don't think this should be hard-locked on the Beta/Release vs. Nightly GeckoView distinction, and tied to a runtime setting instead that the embedding app could then enable/disable as desired.

Comment 1

[Chris Peterson [:cpeterson]]

As a workaround, can the app intercept about:config when the user enters the URL in the address bar?

Comment 2

[Jan Henning [:JanH]]

You mean for blocking access? That would work, too, if we're okay with having this opt-out I guess?

Comment 3

[bamnell]

Why was this blocked in non nightly builds in the first place? It's an essential tool for me to have full control over my browser, even on mobile

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Jan Henning [:JanH] from comment #0)

There might be embedders that legitimately don't want to expose this, but in the general case I don't think this should be hard-locked on the Beta/Release vs. Nightly GeckoView distinction, and tied to a runtime setting instead that the embedding app could then enable/disable as desired.

We could consider this or the suggestion Chris makes in comment #1, but so far I haven't heard a convincing argument for doing so.

The reason about:config is blocked in the first place is because we purposefully don't provide an API to apps for setting prefs, and it seemed wrong to allow users to make a configuration change that the app is unable to do itself. We allow about:config in local and Nightly builds because it was necessary in order to test some experimental platform features such as WebRender.

Comment 5

[bamnell]

So basically if I'm understanding you correctly, you are saying that only settings available via UI should be configurable?

For my use cases at least, that severely limits what I can do

How exactly is it "wrong" to allow us o make changes to our setup, especially the more advanced users who regularly tweak those sort of things? And how is that ok in any other version of firefox besides preview?

I eagerly await your response

Comment 6

[Andrei Petcu]

I'm a power user and I welcome this change. Most advanced users don't use stable anyway.
I also do support as part of SUMO and a lot of n00b users change things they don't understand and then ask for help. When a profile refresh fixes their issue, they blame Firefox for not being able to keep it's profile intact.
People that want to test experimental features, should not do it on stable. They might bump in bugs already fixed in Nightly.

Comment 7

[bamnell]

Um the issue is in Firefox Preview for Android atm.....

Which isn't particularly stable.....

And btw I tweak those settings, know what I'm doing, and DON'T use nightly because I need a stable browser not one that might break next update, had that happen

And also chrome://flags is not restricted to Canary why should about:config be restricted to Nightly?

And it's not just experimental features there it's just really more advanced settings.

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to bamnell from comment #5)

So basically if I'm understanding you correctly, you are saying that only settings available via UI should be configurable?

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

For my use cases at least, that severely limits what I can do

Can you list some of the prefs you'd like to change which don't typically have their own UI?

How exactly is it "wrong" to allow us o make changes to our setup, especially the more advanced users who regularly tweak those sort of things? And how is that ok in any other version of firefox besides preview?

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

Comment 9

[Laurențiu Nicola]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #8)

Can you list some of the prefs you'd like to change which don't typically have their own UI?

Not :banmel, but I looked at my user.js, and here are the ones I would care to change on mobile and are unlikely to be exposed in the UI:

• beacon.enabled
• browser.urlbar.matchBuckets
• dom.forms.autocomplete.formautofill
• extensions.formautofill.creditCards.available
• extensions.pocket.enabled
• javascript.options.asyncstack
• network.IDN_show_punycode
• network.security.esni.enabled

Comment 10

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Laurentiu Nicola from comment #9)

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #8)

Can you list some of the prefs you'd like to change which don't typically have their own UI?

Not :banmel, but I looked at my user.js, and here are the ones I would care to change on mobile and are unlikely to be exposed in the UI:

Thanks for the response! Many of these are completely unused in GeckoView, but there may be a couple that make sense to expose in some kind of way. In particular, network.security.esni.enabled is an experimental feature that we probably don't mind people flipping on (though I haven't checked with the networking folks).

I would be a lot happier if we had something like about:features where we could surface things like that.

Comment 11

[Laurențiu Nicola]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #10)

Thanks for the response! Many of these are completely unused in GeckoView, but there may be a couple that makes sense to expose in some kind of way. In particular, network.security.esni.enabled is an experimental feature that we probably don't mind people flipping on (though I haven't checked with the networking folks).

I would be a lot happier if we had something like about:features where we could surface things like that.

Sure, having an about:features is fine, but it was a product decision to not enable network.IDN_show_punycode by default, which for some users is more of a security risk than avoiding an annoyance.

Comment 12

[Jan Henning [:JanH]]

(In reply to bamnell from comment #7)

And btw I tweak those settings, know what I'm doing, and DON'T use nightly because I need a stable browser not one that might break next update, had that happen

And also chrome://flags is not restricted to Canary why should about:config be restricted to Nightly?

And it's not just experimental features there it's just really more advanced settings.

Another thing is that multiple profiles aren't really supported on Android, and multiple installs of the same application package aren't possible at all.
The former is a problem because I might like to keep separate profiles for my normal browsing and for experimental testing, and in the absence of real profile support it's easier to just keep Nightly completely for experimental browsing and testing, and use Beta or Release for my normal profile (where I'd still like to tweak some things that aren't possible through the UI, though).
Perhaps even worse is the fact that you can't have multiple installs of the same package, so whenever I need to track down a regression via mozregression or by doing it manually, I have to uninstall my current Nightly (or sometimes Beta) in order to replace it by the Nightly/Beta version I want to test. With the way Android works, doing this also kill all previous app data, i.e. my browser profile. At least personally I use a rooted phone, so can at least restore a full backup of my original profile afterwards, but that's not true for everybody and still somewhat of a hassle - and Sync still needs to be manually reconnected afterwards anyway, which is even more annoying (especially during the time when my former e-mail provider used to randomy greylist the sync confirmation link mails for hours).
Hence one more reason not to use Nightly for regular browsing on my phone.

As for the kind of prefs I've modified,

• occasionally played around with some of the font.size.inflation.* tweaks beyond the main pref that can be controlled via the regular settings
• the ui.touch/mouse.radius.* prefs
• browser.sessionhistory.max_total_viewers back when it was still set to 1 by default because the original Fennec ran on a phone with only 128 MB (!) RAM - and while I also tried it Nightly, being able to tweak this in my main profile (not Nightly, see above for why!) as well and and observing its effects was one reason I finally submitted a patch for increasing the default value
• some of the apz.* scrolling behaviour tweaks
• apz.one_touch_pinch.enabled when it was temporarily disabled on Release because of some bug that didn't really affected me
• potentially network.trr.mode if it starts interfering in unwanted ways with my DNS configuration
• ui.scrollbarFadeBeginDelay and ui.scrollbarFadeDuration because I think the scroll bars disappear too soon by default, and also look nicer if they actually fade out instead of directly disappearing
• view_source.wrap_long_lines before I eventually submitted a patch to change its default value to true

and some things that are rather Fennec-specific and not directly applicable to a GeckoView world, but still examples where having about:config access was useful

• browser.sessionstore.max_tabs_undo (I prefer a slightly larger value than the default)
• browser.tabs.useCache (never permanently enabled on Release because of some major bugs for some users which nobody had the resources to ever track down, but for me this works well enough to keep it enabled regardless)
• Fennec does its own default app selection for downloading, but we never implemented a UI for resetting those choices, so the only way to do that is via about:config
• getting some session store debug logs from regular Beta/Release users - it's already bad enough that accessing logcat logs isn't exactly easy for normal users (and the move to Webextensions killed jchens useful add-on), but at least that way the could use their normal browser and didn't have to install Nightly as well
• disabling automatic add-on updates, because unfortunately on Android there's no UI to manage updates per extension, so if you have >=1 extension that you want to keep on a specific version for whatever reason, the only choice is to completely turn off updates (but at least you have a choice)

Comment 13

[bamnell]

I use prefs related to privacy (such as resist fingerprinting and tracking protection) and disabled webgl

That's all I can think of off the top of my head

Comment 14

[robsmith11]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #8)

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

I'm surprised and disappointed to hear this kind of attitude from Mozilla. One of the main advantages Firefox has over the competition is the increased control over configuration.

It seems you are now adopting a culture of "we know what's better for the user than he does" in the name of protecting the average user from breaking his browser. The average user isn't going to just stumble across "about:config". Add warnings if you feel you must. But completely restricting access just doesn't make sense.

A white list of prefs doesn't make sense either. There will always be prefs that some users want to adjust that you have not anticipated.

As long as all crashes/bug reports show prefs that have been adjusted to non-default values, I see no down side to allowing full about:config access in release builds.

Comment 15

[Steph]

(In reply to James Willcox (:snorp) ([e-mail]) (he/him) from comment #8)

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

• There's an exhaustive list here. That's about 200 items, so good luck. It's actively maintained, and if you want to think through the details of such a critical change to about:config functionality, that's the main place you should reach out to in the Firefox community. (Just open an issue in the Github repository, so we don't clutter Bugzilla.)

• Generally speaking, exhaustive preferences are needed for anything where Firefox engages in network requests that do not result from direct browsing. That includes all requests towards Mozilla including update checks, Google Safebrowsing, and even things like OCSP or prefetching. There are many such items.

• Preferences are also needed to disable most web standards on an individual basis. Tor Browser needs many of these. Non-tor users need a few, like service workers, beacons, EME, HTTP Alternative Services, Push, HTTP/2, ... For fingerprinting reasons it's best not to change too many preferences that sites can detect, but in some cases entropy is lowered by customising. When it's not entropy, it's exposure that gets reduced.

• Certain desktop preferences do not apply to the future Firefox for Android (i.e. Fenix), so it is okay not to list them. For example, browser.uiCustomization.state or anything related to the UI or user interaction that is mouse-only. But we should use a blacklist of prefs irrelevant to Fenix, not a whitelist of prefs deemed "safe".

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix.

• Just like the scratchpad is shielded against copy-pasting, about:config can be shielded from unthoughtful modifications without removing control from users. It can be a door hanger like on desktop, but preferences could also be ranked on criticality, like security.*. Let's think of implementing shields rather than nuking user control.

• Future development policy on Fenix should be to keep adding granular preferences like Firefox does on desktop. Any time they add or remove a feature, they add or remove a set of preferences. It has worked very well on desktop; with a bit of cleaning on items irrelevant to mobile, I see no reason it would not work there.

• Let's not centralise power in the hands of Mozilla developers. There's a matter of trust at the root of Firefox's status in the world. Mozilla is trustworthy because they commit to giving full control over their browser's behaviour to users, so that trust is not necessary. Centralising power by removing granularity and exhaustiviness of user control forces trust back into the equation.

Comment 16

[Bob]

As JanH mentioned, the font inflation options, most especially font.size.inflation.minTwips, have been critical for me to get desktop sites usable on mobile. Without it, text is far too small (or lines stretch too wide, requiring side-to-side scrolling if I've zoomed further). I've been setting that option on install on every new phone since 2012 - usually within a couple days when I realise I'd forgotten and start wondering why text is so small.

But ideally we don't need to pick-and-choose options to expose - a blacklist of unstable options (or keeping it as "at users' own risk") sound sensible to me.

Comment 17

[James Willcox (:snorp) ([e-mail]) (he/him)]

We've decided to add a GeckoRuntimeSetting that will control whether or not about:config is exposed. Fenix will use this to enable about:config in all scenarios. Thanks to everyone here for their input!

Comment 18

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Bug 1540065 - Guard about:config access with 'general.aboutConfig.enable' pref

Comment 19

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Bug 1540065 - Add `GeckoRuntimeSettings` controls for enabling `about:config`

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/82c4e08d9890
Guard about:config access with 'general.aboutConfig.enable' pref r=Ehsan
https://hg.mozilla.org/integration/autoland/rev/6736ed7f5805
Add `GeckoRuntimeSettings` controls for enabling `about:config` r=geckoview-reviewers,agi,esawin

Comment 21

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/82c4e08d9890
https://hg.mozilla.org/mozilla-central/rev/6736ed7f5805

Comment 22

[Chris Peterson [:cpeterson]]

firefox70=wontfix because we don't need to uplift this about:config fix to GV 70 Beta.

Comment 23

[Teoh Han Hui]

As a user it's important for me to be able to use about:config when I need to change preferences which are not exposed in the UI. The "fix" didn't seem to address that concern of the users. We don't want to see Firefox become more locked down, there's already Google Chrome for that (actually, at least they have chrome://flags on Android too). With this kind of dismissive approach, Mozilla risks alienating many power users who chose to use / stick to Firefox because they believed.

Comment 24

[[e-mail]]

I totally agree that about:config should be enabled again. Remember the Firefox slogan: "take back the web"? Where is this spirit? Restricting your own users their freedom is something what Google or Microsoft does. People who do the effort to install Firefox over the build-in Chrome are mostly the ones who want to have control about things. Not the ones who are seemed to be sheep dumb ass mass followers that have to be protected from their own stupidity. The main reason I use Firefox is because it has the ability on Android to install extensions. Mozilla is now blocking all extensions that are "non-recommended" or let's say "not popular enough". Again, why?? More secure... I don't care, I know what I'm doing, I want about:config back, I want my extensions back. Give us at least the possibility to do so. I use Firefox since version 1 because I liked Netscape because it's customizable! What is the reason now to have Firefox? There is no reason anymore if you keep doing things like this.