User.js: discussion: create System Addon section

Created on 15 Jul 2017  ·  55Comments  ·  Source: arkenfox/user.js

earthlng said

btw how do you feel about adding a new section for all the system-addons prefs? There are likely more of them coming in the future. I recently updated an FF55nightly to 56 and it had like 10 or 12 14 system addons. Instead of adding some of the prefs to the Personal and others to the Quiet Fox section, I think it would be nice to have them all grouped together.

Thorin said

/me nods

earthlng said

adding experiments in there too is probably a good idea.
In Nightly56 the following addons are included (there may be more that get installed later, idk!)
[see checklist below]

from those I think e10s, aushelper and webcompat are probably of no concern.
automigrate-bookmarks doesn't seem to be a system-addon (?)
IDK about 0300. f.e screenshots is not about "quiet fox" at all, it only makes connections if the user initiates it. Maybe 1300? Or more towards the end where Personal stuff is, 2900 for example?

edit: 0300 is also pretty long already, better to use something else IMO


  • [x] clicktoplay-rollout
    clicktoplay-rollout discussion (click me)

@Thorin-Oakenpants wrote

see 1365714 Release Flash plugin Click-to-Play (aka "Ask to Activate") resolved fixed FF55 .. prefs string to look for contains ctprollout? There are none bar the addon itself. I think this is self contained - there are no prefs.
Since we don't encourage Flash, and it would never deploy until Flash was present, we can ignore this.

@earthlng wrote

I think this is self contained - there are no prefs.

from looking at the source the addon consists of a single js file and it deals with plugin.state.flash. Default value for that, at least in ESR52, is 2 (=enabled), while the addon will set it to 1 (=click-to-play)
I agree we can ignore this.

@earthlng wrote

https://developer.mozilla.org/en-US/Firefox/Releases/55#Plugins

For Firefox 55 release version, the plan is to activate this for 5% of users 2 weeks after release, 25% of users 4 weeks after release, and 100% of users 6 weeks after release

FF56 will probably have plugin.state.flash defaulting to 1 then and the addon will get trashed

...

discussion enhancement

Most helpful comment

Added user_pref("extensions.shield-recipe-client.api_url", "");

All 55 comments

current sections

/*** 0100: STARTUP ***/
/*** 0200: GEOLOCATION ***/
/*** 0300: QUIET FOX
/*** 0400: BLOCKLISTS / SAFE BROWSING / TRACKING PROTECTION

▼▼ NEW
/*** 0500: SYSTEM ADD-ONS / EXPERIMENTS ***/
▲▲ NEW

/*** 0600: BLOCK IMPLICIT OUTBOUND [not explicitly asked for - eg clicked on] ***/
/*** 0800: LOCATION BAR / SEARCH BAR / SUGGESTIONS / HISTORY / FORMS [SETUP]
/*** 0900: PASSWORDS ***/
/*** 1000: CACHE [SETUP] ***/
/*** 1100: MULTI-PROCESS (e10s)
/*** 1200: HTTPS ( SSL/TLS / OCSP / CERTS / HSTS / HPKP / CIPHERS )
/*** 1400: FONTS ***/
/*** 1600: HEADERS / REFERERS [SETUP]
/*** 1700: CONTAINERS [SETUP]
/*** 1800: PLUGINS ***/
/*** 2000: MEDIA / CAMERA / MIC ***/
/*** 2200: UI MEDDLING
/*** 2300: WEB WORKERS [SETUP]
/*** 2400: DOM & JAVASCRIPT ***/
/*** 2500: HARDWARE FINGERPRINTING ***/
/*** 2600: MISC - LEAKS / FINGERPRINTING / PRIVACY / SECURITY ***/
/*** 2697: USER AGENT (UA) SPOOFING
/*** 2698: FIRST PARTY ISOLATION (FPI)
/*** 2699: privacy.resistFingerprinting
/*** 2700: COOKIES & DOM STORAGE ***/
/*** 2800: SHUTDOWN [SETUP]
/*** 3000: PERSONAL SETTINGS [SETUP]
/*** 9999: DEPRECATED / REMOVED / LEGACY / RENAMED

where to put SYSTEM ADDONS :
IMHO, before or after "PLUGINS", as they both extend the functions of the browser (even if plugins are dying)

Info/ideas for section header:

clicktoplay-rollout: see 1365714 Release Flash plugin Click-to-Play (aka "Ask to Activate") resolved fixed FF55 .. prefs string to look for contains ctprollout? There are none bar the addon itself. I think this is self contained - there are no prefs.

Edit: since we don't encourage Flash, and it would never deploy until Flash was present, we can ignore this.

Thanks for the links, nice find! These 2 definitely need to go in the user.js.
From your first link this part is especially interesting... we can set extensions.systemAddon.update.url to a value to "remove all system add-on updates".
"updates" only though, not the pre-installed versions. But still, we should include that pref in the new section, somewhere at the top. We can set it to empty string (boring ;) or make it pretend there are no updates, or to "remove all system add-on updates".
I mean you have to give these guys credit, they really document their stuff very well and in great detail. Thx for that @mozillaGuys xD

it needs a round hundred, so it has room to grow over time - so 500, 600, 700 etc are all options.

600 is taken but I agree 500 or 700 are also good candidates.

current sections

we should add that list to the Readme IMO.

mortar and pdfjs are the other two not mentioned in earthlng's list

mortar doesn't seem to be a system addon. No idea what that is. pdfjs is likely just hosted there with the rest of them but will unfortunately probably not be made into a system-addon.

we should add that list to the Readme IMO.

Really? Do me a PR so I can look at it. Make sure to use the /wikipiki/ images since https://ghacksuserjs.github.io/ghacks-user.js/ as that url doesn't load these things -> :small_orange_diamond: <- but instead shows the code.

I would also strip off all the items in square brackets. What do you title this? Do you put it under usage (nah) or before (yeah!)? I don't really want to shove usage down too far, but the readme within the user.js now covers everything, so I don't mind. How do you stylize it: keep all caps (nah) or proper case (maybe) or capitalise first letter only (probably) - acronyms excepted.

Dazzle me, earthlng

Edit: We're going with 0500

Pocket - "Important: Remove the pocket icon from your toolbar first" - pretty sure this no longer applies since migration to system addon. I'll remove that line.


Update: Pretty sure this landed in FF39

  • there's a comment in this reddit thread (search for "It actually was default disabled for me" and he provides an imgur link showing FF40 Dev).
  • this ghacks article from May 14th 2015 talk about "beta" introducing Pocket. FF38 was released May 11th, so beta would have been 39 at that time.

If you can correct me, awesome. Maybe go find a bugzilla source. Otherwise I'm going with FF39+


Flyweb - I think was introduced in FF50 - see https://bugzilla.mozilla.org/show_bug.cgi?id=1265441
edit: hmmm 9 months old and untouched https://bugzilla.mozilla.org/show_bug.cgi?id=1311188

long way to go - just throwing this up here

part 1 - DONE

/*** 0500: SYSTEM ADD-ONS / EXPERIMENTS
     System add-ons are a method for shipping extensions, considered to be
     built-in features to Firefox, that are hidden from the about:addons UI.
     To view your system add-ons go to about:support, they are listed under "Features"
     [1] https://gecko.readthedocs.io/en/latest/toolkit/mozapps/extensions/addon-manager/SystemAddons.html
     [2] https://dxr.mozilla.org/mozilla-central/source/browser/extensions
***/
user_pref("ghacks_user.js.parrot", "0500 syntax error: the parrot's cashed in 'is chips!");
/* 0501: disable experiments
 * [1] https://wiki.mozilla.org/Telemetry/Experiments ***/
user_pref("experiments.enabled", false);
user_pref("experiments.manifest.uri", "");
user_pref("experiments.supported", false);
user_pref("experiments.activeExperiment", false);
/* 0502: disable Mozilla permission to silently opt you into tests ***/
user_pref("network.allow-experiments", false);
/* 0510: disable Pocket (FF39+)
 * Pocket is a third party (now owned by Mozilla) "save for later" cloud service
 * [1] https://en.wikipedia.org/wiki/Pocket_(application)
 * [2] https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/ ***/
user_pref("extensions.pocket.enabled", false);
/* 0511: disable FlyWeb (FF49+)
 * Flyweb is a set of APIs for advertising and discovering local-area web servers
 * [1] https://flyweb.github.io/
 * [2] https://wiki.mozilla.org/FlyWeb/Security_scenarios
 * [3] https://www.ghacks.net/2016/07/26/firefox-flyweb/ ***/
user_pref("dom.flyweb.enabled", false);
/* 0512: disable Shield (FF53+)
 * Shield is an telemetry system (including Heartbeat) that can also push and test "recipes"
 * [1] https://wiki.mozilla.org/Firefox/Shield
 * [2] https://github.com/mozilla/normandy ***/
user_pref("extensions.shield-recipe-client.enabled", false);
user_pref("extensions.shield-recipe-client.api_url", "");
/* 0513: disable Activity Stream (FF54+)
 * Activity Stream replaces "New Tab" with one based on metadata and browsing behavior,
 * and includes telemetry as well as web content such as snippets and "spotlight"
 * [1] https://wiki.mozilla.org/Firefox/Activity_Stream
 * [2] https://www.ghacks.net/2016/02/15/firefox-mockups-show-activity-stream-new-tab-page-and-share-updates/ ***/
user_pref("browser.newtabpage.activity-stream.enabled", false);

I'll address a couple things but then I really think we should take this step by step. Finish something then move on to the next and cleanup the comments first. Otherwise we end up with walls of text that are all over the place.

Flyweb - I think was introduced in FF50

according to my diffs dom.flyweb.enabled was new in FF49, if that's what we are going by.
I have diffs for as far back as FF38vs39 - I should probably upload them to my repo so you or anyone else can use them as well for things like this.

/* 0517: disable Screenshots (FF55+)

Screenshots definitely exists already in FF54. ie it's shipped with the setup for everyone.
pref("extensions.screenshots.system-disabled", true); was new in FF54. pref("extensions.screenshots.disabled", false); is new in FF55b1


I don't think we necessarily need DESCRIPTION & SCARYSTUFF. A couple of links are good enough IMO.

/* 0503: extensions.systemAddon.update.url ? */
// EARTHLNG: what does this achieve exactly - it could block updates to pdfjs

It could, idk. If we don't "disable" this url then it could install updated versions of addons that someone completely removed from the /browser/features/ folder. Just saying. If we don't care about that, fine.


Are we sure the two experiment prefs belong here. ...

We can name the section "Mozilla System-Addons / Experiments"

Isn't Test Pilot how they now experiment?

Test Pilot, afaik, is something that a user has to install. The other stuff (experiments, shield-shit, etc) is all done without user consent.

If you can correct me, awesome. Maybe go find a bugzilla source. Otherwise I'm going with FF39+

Yes, according to my diffs the old, original browser.pocket.* prefs were new in FF39.
In FF46 they added pref("extensions.pocket.enabled", true); and removed all the browser.pocket.* prefs. All the other replacement prefs (extensions.pocket.*) apart from extensions.pocket.enabled are now set by the addon itself. (.oAuthConsumerKey, .api, etc)
IMO we can remove the following prefs because .enabled is the master switch:

user_pref("extensions.pocket.api", "");
user_pref("extensions.pocket.site", "");
user_pref("extensions.pocket.oAuthConsumerKey", "");

Proof: here you can see that in the addon's startup() function it sets the default prefs (but doesn't overwrite them if already set), then migrates the old master pref, adds an observer (so that toggling the pref in about:config actually does something) and then returns if the master switch is set to false ie it never runs PocketOverlay.startup()
oAuthConsumerKey also seems to be the same for everyone anyway.

  • Would be nice to know if "experiments" was just additional telemetry stuff but ya know what - testing out new features is telemetry and since system addons are now a thing, this is probably one of the mechanism they use, so it's all tied together anyway (eg Shield has heartbeat & necko in it) - forget I mentioned it. Test Pilot is just another way for them to try new things I suppose, and yeah, you have to install it, and it shows in about:addons
  • Section renamed in list above and draft (excellent idea)
  • Screenshots: I was aware there were two prefs, in my haste to throw up a sample I just added one. fixed
  • Pocket in 39, sweet - done (thanks for confirming). Note when I do the commit I will adjust the one we already have in deprecated FF46 to match numbers (yup aware of the pref renaming) - already had it covered
  • Flyweb in 49, sweet - done (thanks for confirming)
  • extensions.systemAddon.update.url - I do not think we should list this or meddle with this. You either physically remove an item/xpi or use the built in switches. There's not much that can't be disabled by the looks of it (despite the statement in link [1] that "[they] cannot be user disabled" . Besides, these could contain fixes for security or privacy. The whole point was the quick updating, restartlessness. Seems Monty Pythonesque to turn that off (might as well buy a dead parrot to begin with).
  • DESCRIPTION (& scarystuff). Well I wanted every system addon to have a link to official mozilla page, a simple description of WTF it is, and to say WHAT it bad about it as to why we disable (because not all of these are "bad" - eg screenshots, AFAIK - just don't use the online bit I guess). That was all. Maybe add a line to the section description?

edit

extensions.systemAddon.update.url

I do not think we should list this or meddle with this.

I disagree. We should at least list it as inactive.

You either physically remove an item/xpi or use the built in switches.

But that's the thing - even if you remove an xpi completely they can still install you a new version

There's not much that can't be disabled by the looks of it (despite the statement in link [1] that "[they] cannot be user disabled")

Unless you remove them from your install-dir they are "technically" impossible to disable ie they show up in about:support as "enabled". Yes you can "stop" most of them from doing anything but that's not what [they] are talking about.

Besides, these could contain fixes for security or privacy. The whole point was the quick updating, restartlessness. Seems Monty Pythonesque to turn that off (might as well buy a dead parrot to begin with).

AFAIK if that's a concern we need to enable auto-install "app-updates" according to this comment. IDK if that's still the case though but I've certainly never received any system-addon updates or fresh installs (fe the HSTS one they mention in that comment)

(That ticket opens a can of worms). APP updates are expected on a regular basis (8 weekly) and you get notifications. I do not know exactly how a system addon update works (outside changes bundled with an app update), but I would suspect that they are irregular and could be almost never. The whole purpose is restartless push to fix issues (without doing minor releases) and this IMO outweighs anything else - eg imagine an exploit fix to pdfjs, or a privacy leak fix in Pocket, or a security fix in AutoFormFill.

What I'm concerned about now is that with our default settings - i.e check but allow me to choose when to update the application - that as per that ticket, system addons will not update

Edit: Hence I am against even listing it because it goes against the very purpose system addons were created and can put people at risk. I'll think about it. Add it to the list

What I'm concerned about now is that with our default settings - i.e check but allow me to choose when to update the application - that as per that ticket, system addons will not update

that's what I meant

Re updating system addons with our settings - then the solution is to log a bug. Not sure how we can test - maybe open an issue with one of the system addon github repos and ask for help?

  • Shield - this is a bitch!

from https://wiki.mozilla.org/Firefox/Shield:

December 2016 - SHIELD System Add-on lands in mozilla-central

according to the changeset for that bugzilla, shield was first deployed in FF53

The only good thing about Shield is that it lead to the removal of SelfSupport from FF's core:
https://hg.mozilla.org/mozilla-central/rev/5a8f2dcbeac0
It still looks at browser.selfsupport.enabled but it needs that pref to be false for Shield to do something.
The problem with this addon is that it auto-uninstalls when it's done and I'm not sure we should try to stop it from gathering telemetry ie hit the return here. Instead, in addition to setting extensions.shield-recipe-client.enabled, we should just neutralize the .api_url by setting it to empty string.

.api_url = https://normandy.cdn.mozilla.net/api/v1 - this is where it gets everything from, f.e the current "recipes" https://normandy.cdn.mozilla.net/api/v1/recipe/

extensions.shield-recipe-client.enabled is checked a bit later on and only after toolkit.telemetry.unified is checked first. see lines 44, 63 + 68 here
I think we should still set .api_url to empty string, just in case.

I guessed 53 from when they closed the ticket as fixed 6 months ago, and allowed for a couple of versions out from stable, and also from the recent reddits and here and at PK's about the pref suddenly turning up starting about 53 but before 54 :)

https://dxr.mozilla.org/mozilla-central/search?q=shield-recipe-client.api&redirect=false
I do not understand this .api_url - it doesn't seem to exist except in tests, or it sets it, or it logs it. I don't follow.

I do not understand this .api_url

It all starts here in bootstrap.js function startup(). That's the entry point for all bootstrapped addons. There it calls ShieldRecipeClient.startup() which is here. On the first line it sets the default values which you can see on line 34. The api_url is then later, maybe among other places, checked here to make sure it's a valid url.
Granted at that point we would have already returned if either toolkit.telemetry.unified or extensions.shield-recipe-client.enabled are false, and we probably don't need to include api_url in the user.js

stopping shield:

  • bootstrap.js startup() calls ... // if you somehow get that addon, this is where it starts

    • ShieldRecipeClient.startup(), which calls ... // no way to stop hitting this



      • ShieldRecipeClient.setDefaultPrefs(); // this is fine


      • does // Setup logging and listen for changes to logging prefs


      • it returns here if browser.selfsupport.enabled=true && extensions.shield-recipe-client.dev_mode=false // we could make it stop right here! is it a good idea though? idk! otherwise it continues by calling ...


      • PreferenceExperiments.init(); // can this be stopped? idk yet, need to look at the code


      • RecipeRunner.init(); // this returns without doing anything if either toolkit.telemetry.unified or extensions.shield-recipe-client.enabled are set to false



we probably don't need to include api_url in the user.js

^^ that's what I wanted to hear :smiley: :smile: :)

We could add this to info to the section header. eg "To view your system add-ons go to about:support, they are listed under Features" (I do not have 55, can anyone tell me the section title?)

In nightly 55+56 they are listed under "Nightly Features" and the normal addons are listed under "Extensions".

Thanks. Once 55 to lands we should confirm the title. I'll add it without the word Nightly for now

Added user_pref("extensions.shield-recipe-client.api_url", "");

Added some stuff - see revamped js up above

I ticked off Activity Stream, Shield, Pocket in the first post, as well as e10s which will become obsolete

ToDo

  • Onboarding: add a one-liner about what it is: eg "Onboarding is a new user/profile tour experience"
  • Screenshots: check out the diff between the two prefs, and check out about shots containing data and cloud services
  • AutoFormFill: links and one-liner maybe about local collection of types of data and exposure
  • Web Compatibility Reporter: one-liner? link?

Other:

  • aushelper & webcompat (nothing more we can do with AFAIK)
  • follow-on-search
  • presentation
  • aushelper - this is fine. It changes the app update url if someone has Websense installed because that apparently causes problems with certain FF versions. And also something to do with CPUs, idk exactly. "aus" probably stands for application update service or something like that.

I looked at some of the addons on DXR (nightly) to see what they do and if there are any other prefs for them...

  • webcompat - the current version has 1 pref extensions.webcompat.perform_ua_overrides but it gets reset if it's user-set, right at the beginning in the startup function:
    ```js
    // Intentionally reset the preference on every browser restart to avoid site
    // breakage by accidentally toggled preferences or by leaving it off after
    // debugging a site.
    Services.prefs.clearUserPref(UA_ENABLE_PREF_NAME);
Atm (in nightly!) that's all it does: user-agent overrides. But so far there's only [one override](https://dxr.mozilla.org/mozilla-release/source/browser/extensions/webcompat/content/data/ua_overrides.jsm#41) set up, for an example site to test if the addon works:
```js
  /*
   * This is a dummy override that applies a Chrome UA to a dummy site that
   * blocks all browsers but Chrome.
   *
   * This was only put in place to allow QA to test this system addon on an
   * actual site, since we were not able to find a proper override in time.
   */

It does register an observer for that pref so you can toggle it off if the override causes problems, but the only way to completely stop this addon from the user.js is to use "pref()" instead of "user_pref" (or lock the pref). But I don't think we should do that. We can add the pref commented out IMO.

removed those 3 pocket prefs leaving just the master switch

so we don't have to scroll heaps. Note: removed // user_pref("extensions.screenshots.system-disabled", true); // (FF54+) - and thus the pref left is FF55+

part 2 - DONE

/* 0515: disable Onboarding (FF55+)
 * Onboarding is an interactive tour/setup for new installs/profiles and features. Every time
 * about:home or about:newtab is opened, the onboarding overlay is injected into that page
 * [1] https://wiki.mozilla.org/Firefox/Onboarding ***/
user_pref("browser.onboarding.enabled", false);
/* 0516: disable Screenshots (FF55+)
 * [1] https://github.com/mozilla-services/screenshots
 * [2] https://www.ghacks.net/2017/05/28/firefox-screenshots-integrated-in-firefox-nightly/ ***/
   // user_pref("extensions.screenshots.disabled", true);
/* 0518: disable Web Compatibility Reporter (FF56+)
 * Web Compatibility Reporter adds a "Report Site Issue" button to send data to Mozilla ***/
user_pref("extensions.webcompat-reporter.enabled", false);

ToDo: Say what onboarding is. A link for AutoFormFill. Check formfill.loglevel. Make distinction between the two Screenshot prefs. Explain what Web Compat Reporter does.

Anyone wanna build a draft, man :snowman: I guess not! Might as well do it myself then sigh

Screenshots: https://reviewboard.mozilla.org/r/145308/diff/2#index_header - We can remove extensions.screenshots.system-disabled IMO Y/N? If so, then the pref that matters is FF55, so changed version

Onboarding: https://dxr.mozilla.org/mozilla-central/source/browser/extensions/onboarding/README.md#18 .. I assume this is only if the tour hasn't been completed. BTW, part of the onboarding includes automigration of bookmarks from the default browser. Also, they can bump version numbers and force new tours, so it's not really just new installs (I think). And then there's this https://dxr.mozilla.org/mozilla-central/source/browser/extensions/onboarding/content/onboarding.js#310 - hidden tabs. Going with this

/* 0515: disable Onboarding (FF55+)
 * Onboarding is an install/new profile experience/user-tour. Everytime `about:home` or
 * `about:newtab` page is opened, the onboarding overlay is injected into that page

AutoFormFill

  • Should look at dom.forms.autocomplete.experimental (not sure when it landed) as this is used in the autoformfill tests - FF52+ (https://reviewboard.mozilla.org/r/85784/diff/3#index_header)
  • Data is stored in a JSON file (that's not very secure!) - https://dxr.mozilla.org/mozilla-central/source/browser/extensions/formautofill/ProfileStorage.jsm
  • There is a UI pref - what is it (if you have 55+ let me know if it has changed) - https://dxr.mozilla.org/mozilla-central/source/browser/extensions/formautofill/FormAutofillPreferences.jsm - It should be [SETTING] Options>Privacy>Forms & Passwords>Enable Profile Autofill
      formAutofillGroup.hidden = document.location.href != "about:preferences#privacy";
      // Use .setAttribute because HTMLElement.dataset is not available on XUL elements
      formAutofillGroup.setAttribute("data-category", "panePrivacy");
      formAutofillGroup.appendChild(caption);
      caption.appendChild(captionLabel);
      captionLabel.textContent = this.bundle.GetStringFromName("preferenceGroupTitle");

Web Compatibility Reporter ( https://dxr.mozilla.org/mozilla-release/source/browser/extensions/webcompat-reporter/test/browser/browser_report_site_issue.js ) basically enables a Report Site Issue button which sends a screenshot to Mozilla (and maybe you can enter some text who knows). Added a description line


Sidenote: reading about so many of these system add-ons, I see an awful lot of tickets references to telemetry - A lot of these are/were experimental, and some telemetry will now not be needed as they land in stable - but it really makes me question if these system add-ons RESPECT the telemetry opt-out. We should follow up on that.

Anyone wanna build a draft, man :snowman: I guess not! Might as well do it myself then sigh

yeah sorry mate, was kinda busy with the canvas blocker testing stuff 🤦‍♂️
offtopic but how the fuck is :man_facepalming: = a woman facepalming ??? gender madness on github now too?! or is this coming from FF?? well that's just fucking great /rant

AutoFormFill

  • Data is stored in a JSON file (that's not very secure!)

They also want to add support for credit cards 🤦‍♂️ ez matching email addresses + cc numbers - nice.
https://blog.nightly.mozilla.org/2017/05/23/preview-form-autofill-in-firefox-nightly/

Web Compatibility Reporter ... basically enables a Report Site Issue button which sends a screenshot to Mozilla (and maybe you can enter some text who knows).

That's in a test file and I didn't look at those. But you're right there's something in it that does that (I looked at the code that came bundled with FF56 nightly). There's another pref that holds the URL for the endpoint: https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4939
You can look at the site - it's already up and has a nice little window where the screenshot would go.

We can remove extensions.screenshots.system-disabled IMO Y/N?

yes

extensions.formautofill.loglevel - IMO we can drop this pref, since if the addon is disabled, it wont log anything

definitely. Even if it did log something, these .loglevel prefs usually only control the verbosity of console output

AutoFormFill - There is a UI pref - what is it (if you have 55+ let me know if it has changed)

the addon itself adds that option to the UI. In my FF56 nightly with all the system-addons removed, that option doesn't exist in the UI

Onboarding is an install/new profile experience/user-tour.

that's some weird word separation. "Onboarding is an install profile experience" - would that be one part of it or what? what does that mean? this needs some re-wording IMO

https://bugzilla.mozilla.org/show_bug.cgi?id=1369046 - its a button you can click, you know, like on your toolbar. The test is just a test. Reworded to say "* Web Compatibility Reporter adds a "Report Site Issue" button to send data to Mozilla */"

? should I add user_pref("extensions.webcompat-reporter.newIssueEndpoint", "");

EDIT: Lets get this sucker wrapped, and then I will get martin to do an article on system add-ons and the upcoming plethora of them, and link back to us.

Also, did you want to do the readme and add in the section titles?

Also, kinda not happy with dom.forms.autocomplete.experimental being in system addons section. It was created as part of the autofornfill stuff (I found it in the bugzilla list wiki, one of the first ones) but it isd clearly not part of the system addon

 * Onboarding is an interactive tour/setup for new installs/profiles and features. Every time
 * about:home or about:newtab is opened, the onboarding overlay is injected into that page

That sums it up. They can trigger it for new features if they want to, at any time - they could push a nasty 12 page next next next slideshow of crap on anyone at any time. But its purpose seems to be for new installs / profiles

Yeah we can always change it later. Someone cough needs to take one for the team and test this shit I guess. cough yes-i-will-do-it-i-am-selfless cough

follow-on-search
https://blog.nightly.mozilla.org/2017/07/19/these-weeks-in-firefox-issue-20/

The Follow On Search Count addon was shipped to 54 population.

There's currently no pref to stop this addon (except setting distribution.id to a non-empty string). Atm it only collects telemetry and that's stopped by disabling telemetry. There is however a logging pref extensions.followonsearch.logging that you can set to true to get console output about what it would send as telemetry. IMO we should include that pref (inactive) so we don't forget that this thing exists, and then check back from time to time to see if it "evolved" and if by then there are prefs to disable it completely.

edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1372307#c0

This bug is to ship to 54 the same system addon for follow on counts that was shipped to 53.

= changed it to FF53+ in the draft below

so we don't have to scroll heaps

part 3

/* 0513: disable Follow On Search (FF53+)
 * [1] https://blog.mozilla.org/data/2017/06/05/measuring-search-in-firefox/ ***/
   // user_pref("extensions.followonsearch.logging", true);
/* 0517: disable AutoFormFill (FF55+)
 * [SETTING] Options>Privacy>Forms & Passwords>Enable Profile Autofill
 * [NOTE] Stored data is NOT secure (uses a JSON file)
 * [NOTE] Heuristics controls Form Autofill on forms without @autocomplete attributes
 * [1] https://wiki.mozilla.org/Firefox/Features/Form_Autofill
 * [2] https://www.ghacks.net/2017/05/24/firefoxs-new-form-autofill-is-awesome/ ***/
user_pref("extensions.formautofill.addresses.enabled", false);
user_pref("extensions.formautofill.experimental", false);
user_pref("extensions.formautofill.heuristics.enabled", false);
user_pref("dom.forms.autocomplete.experimental", false) // (FF52+)

Again .. not happy sure with dom.forms.autocomplete.experimental being in here. It was introduced in 52 and clearly uses a different naming convention, yet it seems tied. Please 'splain. And feel free to fill in 0514 0513

https://blog.mozilla.org/data/2017/06/05/measuring-search-in-firefox/

I can't stand this fucking marketing talk/spin. I'm pretty sure they will eventually intercept the follow-on-search requests and add their utm tracking parameters.

This data will allow us to greatly improve the Firefox search experience while still respecting user privacy.

"greatly" huh? bullshit! They hadn't even started collecting anything at that point, how could they already know the outcome?! and not just "improve" either but "greatly improve". BS!

"Search is blah blah how Mozilla makes much of its revenue." = this is the only time where they come right out and say what all of this is really about.

Firefox telemetry already includes a count of the searches users perform in all Firefox search bars. Firefox does not yet count follow-on searches.

= we already make money from searches users perform and we want money for follow-on searches as well.

When you search with one of the search engines that we include in Firefox, we will increment a counter for each follow-on search.

= they can only make money from SEs included in Firefox, basically admitting that it's not really about improving " Firefox search experience for our users", because they can also get telemetry for user-added search engines. Why are they not interested in those?

We seek these new measurements to gain missing insight into a crucial browser interaction.

= "gain" is an interesting choice of words. It hints at what they really had in mind while writing this. There are a few more of those: "our limited resources", "continue to sustain"

read the blog post again and tell me I'm wrong.

What exactly is a "follow-on search"?

We know from internal user research studies that users often start a search from places like the Awesome Bar or search bar and then continue to refine their search on the search engine results page. We call these additional searches follow-on searches.

So in other words, they want to TRACK search engine web page activity (not done from the UI). That's some massively overstepping BS right there.

Again, I ask, in any of the code (for these system addons) is there a lookup to respect a user's opt-out of telemetry

Why comment out // user_pref("extensions.followonsearch.logging", true) ? Why is it true? Needs more info. eg "Enable the logging pref to see in the console what is being collected."?

We could add some lines to the section header where these are kept and how to kill: I for one am going to remove the ones I do not want anything to do with eg

/***
     Some system add-ons have no on-off prefs. Instead you can manually remove them. Note that app
     updates will restore them. They may also be updated and possibly restored automatically (see 0505)
     * Portable: "...\App\Firefox64\browser\features\" (or "App\Firefox\etc" for 32bit)
     * Windows: "...\Program Files\Mozilla\browser\features" (or "Program Files (X86)\etc" for 32bit)
***/
/* 0505: block URL used for system add-on updates (FF44+)
   [NOTE] You will not get system add-on security/privacy fixes except when you update Firefox ***/
   // user_pref("extensions.systemAddon.update.url", "");

I'm not sure on that update url. If you delete a system addon, will the update check restore it - or will it only update those that are present?

https://bugzilla.mozilla.org/show_bug.cgi?id=863246#c154

Another reason Onboarding sucks - injecting code into pages and opening up resources to be accessible

extensions.systemAddon.update.url was added in FF44

Again, I ask, in any of the code (for these system addons) is there a lookup to respect a user's opt-out of telemetry

The shield client for example looks at the telemetry pref before initiating the recipe manager.
But unless an addon uses google analytics, telemetry always uses the built-in telemetry framework. If that's disabled, afaik it doesn't matter whether there are telemetry gathering calls made in the addon.

delete me

I used to have portable nilla FF's going back to 20 (and even some 3.x and earlier versions) - but I nixed em all

I think we can tick off aushelper and webcompat

If you delete a system addon, will the update check restore it - or will it only update those that are present

It asks for updates based on your FF version. f.e lets say screenshots_v1.0 comes bundled with FF54:
if you remove the addon it will probably not get "restored" as long as there's no new version. It will probably re-install (into your profile folder!) a new version (v1.1) regardless whether you removed v1.0 or not, because otherwise they could never deploy completely new addons

presentation: https://dxr.mozilla.org/mozilla-central/source/browser/extensions/presentation/content/PresentationDevicePrompt.jsm#8

This is the implementation of nsIPresentationDevicePrompt XPCOM.

  • It will be registered into a XPCOM component by Presentation.jsm.
    This component will prompt a device selection UI for users to choose which
  • devices they want to connect, when PresentationRequest is started.

--> https://dxr.mozilla.org/mozilla-central/source/accessible/jsat/Presentation.jsm

Which is about braille and other accessibility thingies

I think we can ignore this. We already have 2513 which disables the Presentation API (although I'm not sure if that API is what also covers this)

dom.forms.autocomplete.experimental has never been in the user js (search the repo, I did). I came across it in the autoformfill tickets - landed FF52 - see https://reviewboard.mozilla.org/r/85784/diff/3#index_header

I may be wrong on that - that new code is just using the pref. What do your diffs say for when it arrived (I'd look but I'm overworked).

FYI: shield recipe for measuring resistFingerprinting etc - https://bugzilla.mozilla.org/show_bug.cgi?id=1356381

@grauenwolfe Can you please tell me where on a Mac are system add-ons stored?

FYI

  • Portable

    • "...\App\Firefox64\browser\features\" (or "App\Firefox\etc" for 32bit)

  • Windows

    • "...\Program Files\Mozilla\browser\features" (or "Program Files (X86)\etc" for 32bit)

At the very least you should have an [email protected] file (in case you want to search for it)

@earthlng
I have edited the first post checklist, speak up if you're unhappy. Down to one item. Suggest this, and then I can commit, close the issue, and get Martin to do an article. :+1: if you're ok with it

/* 0513: disable Follow On Search (FF53+)
 * Just DELETE the XPI file in your system add-ons directory
 * [1] https://blog.mozilla.org/data/2017/06/05/measuring-search-in-firefox/ ***/

Shield Recipe Client issues.
It had an application on heroku, on hold before next iteration.

FF Pioneer... who the hell are the authors? The anonymous names have no homepage.
I won't contribute while being deep probed. No, thanks.

Article: https://www.ghacks.net/2017/07/30/control-firefox-system-add-ons-with-the-ghacks-user-js-file/

I sent Martin the the entire 0500 section code a day ago, along with links this to this issue and the one for the system add-ons update bug. I guess he felt he only wanted to mention a handful of prefs. Nothing about Onboarding, Screenshots, Auto Formfill etc, none of our links

:sad face:

we missed extensions.webcompat.perform_ua_overrides

And what? And what are those links supposed to tell me?

https://github.com/ghacksuserjs/ghacks-user.js/issues/171#issuecomment-316096653

we can ignore that pref IMO. I saw it in @Theemim's diff and thought we forgot to add it. nvm.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Thorin-Oakenpants picture Thorin-Oakenpants  ·  7Comments

crssi picture crssi  ·  3Comments

Thorin-Oakenpants picture Thorin-Oakenpants  ·  5Comments

earthlng picture earthlng  ·  4Comments

Thorin-Oakenpants picture Thorin-Oakenpants  ·  5Comments