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 1214 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
@Thorin-Oakenpants wrote
see 1365714 Release Flash plugin Click-to-Play (aka "Ask to Activate") resolved fixed FF55 ..
prefsstring to look for containsctprollout? 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, is2(=enabled), while the addon will set it to1(=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.flashdefaulting to1then and the addon will get trashed
nothing to donothing to donothing to donothing to do0518 - https://github.com/ghacksuserjs/ghacks-user.js/commit/049841acb13f88dcc06fd5eef3ead4019000a3460514 - https://github.com/ghacksuserjs/ghacks-user.js/commit/71c81992f5607609746015e9f48661fed4cc45c7 (originally 0513)0510 - https://github.com/ghacksuserjs/ghacks-user.js/commit/71c81992f5607609746015e9f48661fed4cc45c70511 - https://github.com/ghacksuserjs/ghacks-user.js/commit/71c81992f5607609746015e9f48661fed4cc45c70517 - https://github.com/ghacksuserjs/ghacks-user.js/commit/808196718736b84d9ec9938212c47fc23fa8fd870515 - https://github.com/ghacksuserjs/ghacks-user.js/commit/4e36051192b2ee20c0fc5a26473e8fc6f6f7b8020516 - https://github.com/ghacksuserjs/ghacks-user.js/commit/16499e961100e750751fa9187e2b72174f7360630512 - https://github.com/ghacksuserjs/ghacks-user.js/commit/bcf38ca80b0728d919ee87aecbe41b30d9bb8aef0513 - https://github.com/ghacksuserjs/ghacks-user.js/commit/63ed779776d15440df93417c0204993a984bf591...
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
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.
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?
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:
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 ...toolkit.telemetry.unified or extensions.shield-recipe-client.enabled are set to falsewe 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
Other:
I looked at some of the addons on DXR (nightly) to see what they do and if there are any other prefs for them...
extensions.webcompat.perform_ua_overrides but it gets reset if it's user-set, right at the beginning in the startup function: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.loglevelMake 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
dom.forms.autocomplete.experimental ( 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");
extensions.formautofill.loglevel - https://bugzilla.mozilla.org/show_bug.cgi?id=1339515 . IMO we can drop this pref, since if the addon is disabled, it wont log anythingWeb 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-disabledIMO 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
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/ ***/
FYI: https://addons.mozilla.org/en-US/firefox/addon/firefox-pioneer/
https://medium.com/firefox-context-graph/make-firefox-better-with-pioneer-10c82d0f9301
And there are other experiments. So glad we have a system add-on section now
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.
Most helpful comment
Added
user_pref("extensions.shield-recipe-client.api_url", "");