1426187 - Add documentation to SUMO on user.js (format, content, and where to put)

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Content, task)

Description

[R P Herrold]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20171205144502

Steps to reproduce:

This indication of the presence of a 'user.js' was added in the past

https://bugzilla.mozilla.org/show_bug.cgi?id=557738
Add user.js section to about:support
RESOLVED FIXED in Firefox 19

Entering: 
   about:support
on: 
Name 	Firefox
Version 	52.5.1
Build ID 	20171205144502

contains no such entry




   



Actual results:

Added feature of expected indication that a: user.js exists, in about:support is absent

although the file is present:

sh-4.2$ find /usr/bin/ .thunderbird .mozilla .firefox -name "user.js"
.mozilla/firefox/user.js
sh-4.2$ 




Expected results:

it should indicate the existence of the file, per the prior bug noted

Comment 1

[YF (Yang)]

Work for me in Firefox 52.5.2 and 58.0b11.

Comment 2

[R P Herrold]

(In reply to YF (Yang) from comment #1)
> Work for me in Firefox 52.5.2 and 58.0b11.

Thank you, but this is too bare-bones a report to be useful

Please provide your OS [ uname -a ], and a sample 'find' command result per my report, so I may start bisection

A screen-shot, duly cleaned up of PII, would be nice as well

Comment 3

[YF (Yang)]

Sorry, I missed the operating system. I am running Firefox on Windows 10.

Comment 4

[R P Herrold]

(In reply to YF (Yang) from comment #3)
> Sorry, I missed the operating system. I am running Firefox on Windows 10.

TY

the 'paths searched' mechanism varies, so it probably doe not narrow the issue.  Thank you for the report anyawy

-- Russ herrold

Comment 5

[R P Herrold]

I went digging further

it appears, contrary to the documentation, that it only observes a 'users.js' when found down in the directory BELOW the GUID one

It 'sees' the otehrs and will open for read, one at: ~HOME/.mozilla/ 


the only 'REAL' file in that chain of symlinks



sh-4.2$ pwd
/home/ghola
sh-4.2$ find -name user.js -a -exec ls -l {} \;
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:22 ./.mozilla/firefox/77huh66w.default-1500591005884/bookmarkbackups/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:22 ./.mozilla/firefox/77huh66w.default-1500591005884/datareporting/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/gmp/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:24 ./.mozilla/firefox/77huh66w.default-1500591005884/tidy/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/jetpack/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:24 ./.mozilla/firefox/77huh66w.default-1500591005884/simplemail/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:24 ./.mozilla/firefox/77huh66w.default-1500591005884/storage/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/sessionstore-backups/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/gmp-gmpopenh264/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:22 ./.mozilla/firefox/77huh66w.default-1500591005884/extensions/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/saved-telemetry-pings/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:24 ./.mozilla/firefox/77huh66w.default-1500591005884/weave/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:22 ./.mozilla/firefox/77huh66w.default-1500591005884/browser-extension-data/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 15:23 ./.mozilla/firefox/77huh66w.default-1500591005884/lwtheme/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 13:54 ./.mozilla/firefox/77huh66w.default-1500591005884/user.js -> ../user.js
lrwxrwxrwx. 1 ghola ghola 10 Dec 21 13:53 ./.mozilla/firefox/user.js -> ../user.js
-rw-r--r--. 1 ghola ghola 5830 Dec 21 15:20 ./.mozilla/user.js
sh-4.2$ 

screenshot in a moment

Comment 6

[R P Herrold]

Attachment: mozilla-users.js-path.png -- hover path at bottom

Comment 7

[Masatoshi Kimura [:emk]]

(In reply to R P Herrold from comment #5)
> it appears, contrary to the documentation, that it only observes a
> 'users.js' when found down in the directory BELOW the GUID one

What documentation? `~/.mozilla/` is a location where profile folders will be created, not a profile folder itself.

Comment 8

[R P Herrold]

@:emk

You asked a question and then closed the ticket ... reopening

This is the documentation to which I was referring:


http://kb.mozillazine.org/User.js_file#About_the_user.js_file

Creating the user.js file

To create a user.js file, open a text editor such as Notepad and save the empty 
file as "user.js" inside your profile folder. (If you use a Windows text editor, 
make sure you unhide extensions for known filetypes in Folder Options, so that the 
file isn't really called "user.js.txt". See also the manual editing advice.) 

... following the link to: profile folder


http://kb.mozillazine.org/Profile_folder

Unix/Linux 	~/.mozilla/ 

which is my OS, and pretty clearly says it is the canonical 'profile folder' for my OS

Comment 9

[R P Herrold]

toggling back to an Open status

Comment 10

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'm not sure if the documentation on the Mozillazine wiki is up to date. Will investigate.

Comment 11

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

R P Herrold, I've reviewed the Mozillazine wiki docs and tried installing my own user.js file. 

The instructions in http://kb.mozillazine.org/Profile_folder are confusing, but the user.js file goes in a unique profile folder.

On my Mac, that's file:///Users/<user name>/Library/Application%20Support/Firefox/Profiles/<gid>.<profile name>/user.js

See the official documentation on the profile folder for more information https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

The Mozillazine.org docs are not official, or maintained by Mozilla staff, but I can ask contacts in that group if they'd update their articles on this. 

I'm keeping the bug open because this is a documentation issue. user.js is mentioned in several SUMO (support.mozilla.org) articles, but there's no separate article for it, and the Mozillazine.org article has the important information about the structure of the file, but not where to put it! 

Thank you for your patience on this, and I hope the above is enough to provide a workaround. 

Since a user can have multiple profiles, I don't think linking a ./mozilla/user.js to each profile folder is useful you'd want to have separate user.js files in each profile.

Comment 12

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Also, this mozilliazine article has a little more specific information on where those profile folders live, http://kb.mozillazine.org/Profile_folder_-_Firefox, but the support.mozilla.org site should be the canonical reference for that.

Comment 13

[R P Herrold]

@:emceeaich

Thank you for the follow up

Yup, as I pointed out in comment 4, the location seems to vary by major OS

As to the use of lots of symlinks, and 'find', that was a debugging expedient on my part, and I concur that it is not suitable for production

-- Russ herrold

Comment 14

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

not sure we should documenting user.js because it is very technical and risky
much more risky than userChrome.css

i know the precedent has been set to document both user.js and userChrome.css but i would rather have an API for customization in both cases instead of documenting something that most SUMO users (who can't write JS or CSS let alone debug it or even find profile folders) can't fix if it breaks

my 2 cents :-) FIWI, joni's may vary :-)

Comment 15

[R P Herrold]

@:rolandtanglao

we seem to have both committed into this bug at the same time, and (strangely) Bugzilla did not warn me, as I am accustomed to with the Red Hat Bugzilla

Let me get my content committed:
I have reviewed for accuracy the SUMO article about user.js -- it needs to be tweaked:

It presently states:

> The optional user.js file, if one exists, will override any modified preferences. 

At best, it will over-ride ** SOME ** modifications of preferences.  As to the driving reason for inquiry, locking down involuntary plug-in installations, and involuntary including trying to completely disable 'telemetry' 'phone home' of data [anonimyzed or not], it does ** NOT ** work and stay unaltered

I encountered also UN-asked for changes at:

// set (historical mode):

browser.tabs.remote.autostart = false
browser.tabs.remote.autostart.2 = false

// ... above silently set itself true again  2017 08 29
//      52.2.0 (64-bit) ESR
//      Centos 7, 2017 09 update is: 52.3.0 (64-bit)


contrary to my user.js settings

also "e10s" would invisibly revert 'lockouts' I set in user.js

[herrold@centos-7 firefox]$ grep "e10" *
README-firefox-stuff:e10s.rollout.cohort;disqualified-test
README-firefox-stuff:e10s.rollout.cohortSample;0.059829
x-tunnel-ICP-fail.txt: [e10s] Tabs crash on loading large sites.


I will migrate this to any successor documentation bug if this gets cloned

Comment 16

[Joni Chan]

I agree with not documenting user.js because. It was documented in the past but we won't be able to support users if things go wrong. I think Mozillazine is the best place for this.

Comment 17

[R P Herrold]

another collision this time with @joni Savage

@:rolandtanglao

I wanted to get that committed, as in part it lays part of the foundation as to WHY I was mucking on 'user.js' in the first place

Responding to your comment 14, the 'Mr Robot' and before that the 'e10s' experience have been causing local support load for me, as well as mysterious hangs 

The privacy concerns on exfiltration of browser data had been seen by me (I know how it is 'telemetry') by watching the DNS queries and pages returned on a local boundary 'squid' proxy.  I deal in part with PII in Credit Card clearance and dispute data, and very formal and stringent protection is required.  I _understand_ that there are assertions of aggregation, etc to reduce risk, but:
   1.  they are not under local control, si I cannot get an assessor to 'sign off' on its adequacy  during an audit
   2.  I cannot audit or control that they currently are, and more importantly, will _stay_ effective

There are well know data de-aggregation demonstrations, long ago know when working with U S Census data.  I mucked in this data back  in the Johnson / Nixon administrations, and it is just too easy to slice and dice down into a particular household and person within, and so to violate the legislatively required anonymity of Census questionnaires -- legally required, so one cannot lawfully decline to answer.

To be credible as a enterprise tool, it must to be documented on how to lock down a browser.  If Firefox is not able to attain this, it will not be considered going forward (post the Mr Robot event)

If the implementation sequence is to wait for the future 'more perfect' in favor of the 'present sort of good', that is of course your decision ... but it will not address privacy and data disclosure risks I have to solve with the tools arrayed to me.  I've already written 'cron' based test and diff tools to alert me of changes in config files including 'user.js' 

But I am by no means the only person with this set of requirements:  see your mailing list: To: "[e-mail]" <[e-mail]> for the last month:

https://mail.mozilla.org/private/enterprise/

Thank you

-- Russ herrold

Comment 18

[R P Herrold]

@joni Savage

I think the essence of your close, is saying: it is too hard

and I think 'hiding one's head in the sand', and leaving security to non-authoritative sources rather than in SUMO, is clearly contrary to the first three bullets at:

    https://www.mozilla.org/en-US/privacy/principles/

Reclose if you will, but as I had not made my case yet, due to the two collisions in the 'race to close' the bug before my comments 15 and 17, it seems you are not hearing

Comment 19

[R P Herrold]

ticking back to an open state in light of comment 18

Comment 20

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Russ, 

I asked the SUMO team if they wanted to provide further documentation for user.js. 

The team replied to the question and said they do not plan to, not because it is hard, but because it's out of scope for them. 

Please do not reopen the bug. Per BMO Etiquette reopening a wontfix decision by a person responsible for the component (which Joni is) is not appropriate. 

Comment #15 describes a bug in the interaction of user.js and about:config, that should be forked out of this and into it's own report; I'll do that.

Comment 21

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

See also, regarding enterprise deployments with specialized requirements around security, https://groups.google.com/forum/#!topic/mozilla.dev.platform/VF7cEdlzRg0

Comment 22

[Daniel Veditz [:dveditz]]

preferences come and go, and most of them are an internal implementation detail with an uncertain lifetime. user.js is a hack that ossified into a "feature" but it's still trying to impose state on internal implementation details that are always in flux. Use at your own risk.