1562549 - Allow user.js files to lock preferences with lockPref()

Status: RESOLVED WONTFIX

(Core :: Preferences: Backend, defect)

Description

[u641775]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 LibreWolf/67.0.4

Steps to reproduce:

Firefox does not allow locking of preferences for user.js

Comment 1

[:Gijs (he/him)]

This is a backend question, so moving components.

I have to say, I don't see the point. Who would you be locking it "from"? The user has write access to user.js, so not them...

Comment 2

[Mike Kaply [:mkaply]]

Yeah, this doesn't really make sense. user.js is for the user.

If you want to lock prefs, use Autoconfig or policies.

Comment 3

[u641775]

Neither autoconfig nor policies provide per profile access. As user.js is the only way to store custom preferences on a per folder basis, the least that could be done is allow the same level of access as default preference files.

Comment 4

[u641775]

There were already patches here https://bugzilla.mozilla.org/show_bug.cgi?id=440908#c0 beforehand that allowed locking for all .js files, however it was in the later stages of the bug where the arbitrary distinction between default preferences and user preferences were made. Even if the user can access user.js to bypass the security, the same could be said about the user bypassing the default preferences or any other software by just using another browser. user.js is hidden enough to be obfuscated to unfamiliar users, while allowing different preferences on a per profile basis.

Comment 5

[:Gijs (he/him)]

(In reply to disruptivefalcon20 from comment #4)

There were already patches here https://bugzilla.mozilla.org/show_bug.cgi?id=440908#c0 beforehand that allowed locking for all .js files, however it was in the later stages of the bug where the arbitrary distinction between default preferences and user preferences were made.

It's a pre-existing distinction, it's not really arbitrary...

Even if the user can access user.js to bypass the security, the same could be said about the user bypassing the default preferences or any other software by just using another browser.

Most situations where pref locking is used for enterprise policy don't allow software installs, and also enforce whatever required prefs on the other browsers, so no.

user.js is hidden enough to be obfuscated to unfamiliar users, while allowing different preferences on a per profile basis.

Why do you need different locked prefs on a per-profile basis?

Comment 6

[u641775]

Some preference changes, do not take effect until they are locked. I still do not understand why there was a need to seperate user preferences and default preferences, in terms of their ability to lock or not. Allowing locking across the board actually, improves security, rather than reduces it, and also improves flexibility while providing a more consistent interface for js files that is not only easier to document, but also maintain. With the way things are, you currently have four different possible types of setting files to manage, each with their own behavior. Policies.json, autoconfig, default js files and user js files. Undoing this arbitrary change would bring that down to 3, and offer consistent syntax and functionality for all js files. As it stands, there is no documentation for the distinction between user.js and default js files, and as far as i can see, that distinction was made when that referred to bug was resolved.

Comment 7

[:Gijs (he/him)]

(In reply to disruptivefalcon20 from comment #6)

Some preference changes, do not take effect until they are locked.

Like what?

Comment 8

[u641775]

Like what?

I cannot seem to be able to find the link, but i believe at one point, app.updates.enabled would not be honored unless it was locked (possibly other preferences could be the same). Then again, i could be mistaken. However, the argument still remains that locked preferences are safe from UI changes and changes by extensions, and this could be useful on a per profile basis.

However, with my argument for simplicity of maintenance and documentation, greater flexibility and security by offering the only way to lock settings from the gui on a per profile basis and a more consistent syntax style across all .js preferences files, I ask you for justification on the need to remove locking abilities from the user.js file: why is it needed?

Comment 9

[Mike Kaply [:mkaply]]

The only preference that requires being locked is xpinstall.enabled, and that can be set via policy now.

I realize Linux doesn't have user specific policy, but that's a limitation of the platform, not Firefox. If you have any suggestions on how to do that, I'm more than happy to hear ideas.

Side note, you can use Autoconfig to do user specific preferences by checking for user account in autoconfig via environment variables.

user.js was never intended to be a management feature, and there's no guarantee it will be around going forward. We're not going to be adding new features to it.

Comment 10

[u641775]

user.js already exists, and already provides all the functionality of other preferences files, with the sole exception of locking. It already did support this feature in previous patches but it was removed.

The policies.json file is still in its infancy, still hasn't been fully documented and doesn't nearly encompass all the flexibility of changing every possible preference through a js file.

locking a preference prevents it from being changed by both the ui and extensions, and neither autoconfig nor policies would carry over with the profile across installs.

All i am asking for is the simple ability to lock user.js preferences.

Is that really such a difficult request?

Comment 11

[u641775]

So far the only documented differences between default preferences and user preferences is the location of the files, and the order of loading. The need for user preferences to not have the ability to lock preferences, is purely an arbitrary one. User.js is the only, cross platform, profile specific option to change preferences. Why cripple it? Its not the addition of a new feature. Previous patches already had this capability. It was the distinction between user preferences and default preferences, for only this reason, that was a deliberate addition

Comment 12

[:Gijs (he/him)]

The terminology here is really confusing. Internally, Firefox has always had a difference between user-set and default preference values. They are stored on different "branches", and we only store user prefs where their values differ from the default branch. That wasn't introduced in bug 440908, it's how prefs have worked since netscape, I think (or at least since suite days / 1998 or thereabouts). We (comparatively recently) introduced "sticky" prefs, where we always write the user value, even if it matches the default.

user.js is then itself quite weird in that it gets loaded after prefs.js, but is effectively the same kind of data (ie it gets stored on the user branch). So it overrides prefs as set through the user interface in Firefox on startup (because user.js is loaded later, and the UI only writes to prefs.js, never user.js). This then means people can be surprised when they use it, even without using locking prefs, because any customizations they make using Firefox UI that get stored in user.js prefs get overridden on the next start, which gives the impression that Firefox is just broken / forgetting all their changes all the time. This is why I would like to remove support for user.js altogether - it doesn't really make sense to most people, and they use it because random webpages tell them to, and then they end up frustrated because things are broken. It also gets abused by third party software (some of which is likely malware), cf. this comment https://searchfox.org/mozilla-central/rev/8a990595ce6d5ed07ace2d4d5d86cc69aec90bde/modules/libpref/Preferences.cpp#4124-4125 . We have no visibility into how much of user.js use is user-intended and how much isn't, of course.

We can't "just" read user.js as a "default" type pref file, because then the above stops working for people who expect it - that is, then user.js things get overridden by prefs.js things if they're different, because user-branch pref values trump default-branch pref values. Also, extant files would fail to parse because they use user_pref instead of default_pref, so it wouldn't be backwards-compatible without substantially more work (where we'd need to be reading a file called user.js, which takes user_pref syntax, and gets stored in the default branch of prefs, which is a recipe for disaster/confusion).

Adding sticky/lock support to pref files that get read into the user branch:

• means changing the parser substantially, it's not enough to "just" remove the user/defaults distinction (in fact, we cannot, it was there before, it is apparently just more obvious to you, the reporter, after the patch in 440908)
• makes things easier for malware and other third party software to (to the user, inexplicably) interfere with Firefox settings
• makes it even harder to debug issues with prefs, because now there'll be more places that can do certain things, meaning you have to go through more steps when debugging issues with users
• means we have to change the write format for prefs.js in a way that probably won't be backwards-compatible (otherwise we'd overwrite locked/sticky-ness set up in prefs.js every time)
• makes ripping out user.js harder (because people will start to rely on it for this thing instead of using policies)
• offers no benefit over the current setup except for (apparently?) multi-user linux environments, which is a tiny fraction of our userbase, where other solutions already exist

So I still think this is a terrible idea. Anyway, it's :njn's call.

Comment 13

[Nicholas Nethercote [inactive]]

My decision to have different syntax between default pref files and user pref files was deliberate.

The default pref file defines the default value of each pref and also specifies other attributes of that pref, such as whether it is locked or sticky. The number of attributes possible in this file is likely to increase in the future, e.g.: Should it be shown in about:config? Should it be shown in about:support? Should it be sent to content processes? Should it be sync'd?

In contrast, the user pref file merely defines the user value of the pref, which overrides the default value. The file deliberately doesn't permit the changing of attributes, because that would give it more power than it should have.

Because of this, and the reasons mentioned by Mike and Gijs above, I am not willing to make the suggested change. I apologize for any disappointment this causes.