Closed
Bug 1426187
Opened 6 years ago
Closed 6 years ago
Add documentation to SUMO on user.js (format, content, and where to put)
Categories
(support.mozilla.org :: Knowledge Base Content, task)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: herrold, Unassigned)
Details
Attachments
(1 file)
165.18 KB,
image/png
|
Details |
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
Reporter | ||
Comment 2•6 years ago
|
||
(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
Flags: needinfo?(yfdyh000)
Sorry, I missed the operating system. I am running Firefox on Windows 10.
Flags: needinfo?(yfdyh000)
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Reporter | ||
Comment 4•6 years ago
|
||
(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
Reporter | ||
Comment 5•6 years ago
|
||
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
Reporter | ||
Comment 6•6 years ago
|
||
Comment 7•6 years ago
|
||
(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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 8•6 years ago
|
||
@: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
Reporter | ||
Comment 9•6 years ago
|
||
toggling back to an Open status
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Updated•6 years ago
|
Component: Untriaged → General
Comment 10•6 years ago
|
||
I'm not sure if the documentation on the Mozillazine wiki is up to date. Will investigate.
Flags: needinfo?(ehumphries)
Comment 11•6 years ago
|
||
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.
Component: General → Knowledge Base Content
Flags: needinfo?(ehumphries)
Product: Firefox → support.mozilla.org
Summary: Regression: former appearance of existence of: user.js in: about:support is absent → Add documenation to SUMO on user.js (format, content, and where to put)
Version: 52 Branch → unspecified
Comment 12•6 years ago
|
||
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.
Reporter | ||
Comment 13•6 years ago
|
||
@: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•6 years ago
|
||
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 :-)
Reporter | ||
Comment 15•6 years ago
|
||
@: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•6 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 17•6 years ago
|
||
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: "enterprise@mozilla.org" <enterprise@mozilla.org> for the last month: https://mail.mozilla.org/private/enterprise/ Thank you -- Russ herrold
Reporter | ||
Updated•6 years ago
|
Summary: Add documenation to SUMO on user.js (format, content, and where to put) → Add documentation to SUMO on user.js (format, content, and where to put)
Reporter | ||
Comment 18•6 years ago
|
||
@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
Reporter | ||
Comment 19•6 years ago
|
||
ticking back to an open state in light of comment 18
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 20•6 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → WONTFIX
Comment 21•6 years ago
|
||
See also, regarding enterprise deployments with specialized requirements around security, https://groups.google.com/forum/#!topic/mozilla.dev.platform/VF7cEdlzRg0
Comment 22•6 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•