ToDo: diffs FF67-FF68 #743
Comments
some bugzilla tickets
|
|
I wonder, is it not risky to evaluate preferences one month before they reach the Release channel ? Feels like it forces to duplicate some work in order to check that the decisions made are still correct one month later. Anyway, I went over the last 20 prefs of the "New" list. I mean these prefspref("privacy.storagePrincipal.enabledForTrackers", false);
pref("privacy.trackingprotection.origin_telemetry.enabled", false);
pref("remote.enabled", false);
pref("remote.force-local", true);
pref("remote.log.level", "Info");
pref("security.tls.enable_post_handshake_auth", false);
pref("services.settings.security.onecrl.bucket", "security-state");
pref("services.settings.security.onecrl.checked", 0);
pref("services.settings.security.onecrl.collection", "onecrl");
pref("services.settings.security.onecrl.signer", "onecrl.content-signature.mozilla.org");
pref("services.sync.prefs.sync.browser.contentblocking.features.strict", true);
pref("signon.management.page.enabled", false);
pref("signon.showAutoCompleteOrigins", false);
pref("telemetry.origin_telemetry_test_mode.enabled", false);
pref("toolkit.content-background-hang-monitor.disabled", false);
pref("toolkit.legacyUserProfileCustomizations.stylesheets", false);
pref("toolkit.telemetry.ecosystemtelemetry.enabled", false);
pref("ui.android.mouse_as_touch", 1);
pref("view_source.tab", true);
pref("xul.panel-animations.enabled", true);It appears that all 20 of them can be ignored. Some of them are worth knowing about. pref("remote.enabled", false);
pref("remote.force-local", true);
pref("remote.log.level", "Info");InfoThese three control Firefox Remote agent, turned off by default. More on this. Here's what each pref does, which shows that the default values are just right. pref("privacy.storagePrincipal.enabledForTrackers", false);InfoInformation on Storage Principal. This is a good pref.
I assume it would be enabled by Mozilla when it's ready and depending on user Content blocking preferences. IMO, we know it is ready if/when changing Content blocking prefs from Firefox options switches this pref on if its default is false. Then only it may be worth setting to pref("privacy.trackingprotection.origin_telemetry.enabled", false);
pref("telemetry.origin_telemetry_test_mode.enabled", false);InfoOf note are comment 0 and comment 4. This has to do with an experiment on 0.014% of page loads from each user from a random group of 1% of the Release channel users who did not disable telemetry. The experiment lasts 6 months and seeks to improve efficiency of Firefox's built-in content blocking. The main telemetry switches are said to command this experiment, so assuming no bug, it will not happen if they are off. The function IsReportingEnabled shows that both prefs should be pref("toolkit.telemetry.ecosystemtelemetry.enabled", false);InfoIt is part of Firefox Ecosystem Telemetry. Here's more information on how it works. It obeys the main telemetry switches, according to comments, but should be kept to false by people who intend to never enable telemetry; to cover for the eventual bug (defence in depth). The pref is false by default in 68 anyway, so there's nothing to do. pref("toolkit.legacyUserProfileCustomizations.stylesheets", false);This one must be set to |
|
Wow, thanks @Okamoi, now that's some quality contribution right there! 👍
For a while now I've always waited with creating the diffs issue until a Beta is no longer in its early-beta stage. That reduces the amount of changes quite a bit and as you can see in the older diff issues there's usually not a lot that changes between the 1st non-early beta and the final release. |
pref("network.protocol-handler.external.ie.http", false);
pref("network.protocol-handler.external.iehistory", false);
pref("network.protocol-handler.external.ierss", false);these 3 new prefs seem to be security related (1552627 = ACCESS DENIED) but they also landed these in 67.0.2 so I moved them to the ignore list. |
|
^^ yes, I noted gk backported them in TB, there's also another one (1549833), but i have no idea what it is exactly: https://trac.torproject.org/projects/tor/ticket/30849 |
|
1549833 is about |
|
WTF is an |
Edit: they set the default to |
Thanks! I wanted to reduce visual clutter while leaving relevant information searchable with a CTRL+F based on pref names. (Since collapsed = unsearchable. I wonder what search engines think of collapsed text now though...) This comment now is still a bit too lengthy with all the By the way your bug list is really useful, are you getting them by searching for the pref name here ?
Okay then, fair enough! I didn't know there was such a thing as an early-beta stage and a more consolidated one. So I went over 20 more prefs from the bottom of the "New" list. These prefspref("media.audiograph.single_thread.enabled", false);
pref("media.cache_readahead_limit.cellular", 30);
pref("media.cache_resume_threshold.cellular", 10);
pref("media.cache_size.cellular", 32768);
pref("media.devices.insecure.enabled", true);
pref("media.getusermedia.insecure.enabled", false);
pref("media.videocontrols.picture-in-picture.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-wait-ms", 5000);
pref("network.cookie.staleThreshold", 60);
pref("network.delay.tracking.load", 0);
pref("network.dns.resolver_shutdown_timeout_ms", 2000);
pref("network.http.enforce-framing.strict_chunked_encoding", true);
pref("network.ssl_tokens_cache_capacity", 2048);
pref("network.ssl_tokens_cache_enabled", false);
pref("network.traffic_analyzer.enabled", true);
pref("network.trr.excluded-domains", "localhost,local");
pref("network.trr.resolvers", "[{ \"name\": \"Cloudflare\", \"url\": \"https://mozilla.cloudflare-dns.com/dns-query\" }]");
pref("privacy.annotate_channels.strict_list.enabled", false);It appears that 16 of them can be ignored, 1 should probably be changed, 1 depends on RFP specifics, 1 depends on your policy for this A couple more are worth knowing about, but not changing. The 16 prefs ignore listpref("media.audiograph.single_thread.enabled", false);
pref("media.cache_readahead_limit.cellular", 30);
pref("media.cache_resume_threshold.cellular", 10);
pref("media.cache_size.cellular", 32768);
pref("media.getusermedia.insecure.enabled", false);
pref("media.videocontrols.picture-in-picture.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-wait-ms", 5000);
pref("network.cookie.staleThreshold", 60);
pref("network.delay.tracking.load", 0);
pref("network.dns.resolver_shutdown_timeout_ms", 2000);
pref("network.http.enforce-framing.strict_chunked_encoding", true);
pref("network.ssl_tokens_cache_capacity", 2048);
pref("network.ssl_tokens_cache_enabled", false);
pref("network.trr.excluded-domains", "localhost,local");4 preferences to consider for change: pref("network.traffic_analyzer.enabled", true);InfoAn experiment that analyses HTTP traffic and will run at most until Firefox 73, looking for the prevalence of tracking resources going through HTTP. According to comments the experiment can't occur if telemetry is disabled through the main switches. For defence in depth, I would set it to pref("media.devices.insecure.enabled", true);InfoThis should allow access to navigator.mediaDevices features on insecure web pages (HTTP), except for It is I don't intend to interact with a site that uses HTTP for If RFP covers it well, then the pref could be ignored, otherwise I would set it to
EDIT: According to Firefox Site Compatibility, this pref is going to get turned off by default in the future. So I would ignore it. It seems that in the wild, On my end, only the former is disabled, but I think it is because I verified that RFP lies properly about If someone is reading this and knows, can you confirm ? pref("privacy.annotate_channels.strict_list.enabled", false);InfoThis one is related to Tracking Protection - basic vs strict lists, both for tracking and crypto-mining. I suppose it can be set through Firefox 68's UI, but I can't check. What to do with this depends on what this repo's pref("network.trr.resolvers", "[{ \"name\": \"Cloudflare\", \"url\": \"https://mozilla.cloudflare-dns.com/dns-query\" }]");InfoAn interesting one: It shows that DNS over HTTPS is moving to the point where there can be UI. At some point I'm probably going to enable DNS over HTTPS. For now, I would ignore this pref and rely on Ignored prefs worth knowing about: pref("network.ssl_tokens_cache_enabled", false);Nothing to do here, since the pref is pref("network.delay.tracking.load", 0);A temporary value, I would guess. In the future, it might be used to delay third party tracking resources by a number of milliseconds in order to improve page load time. Today, a good pref that does nothing. pref("network.cookie.staleThreshold", 60);The cookie part draws attention, but it sounds like it's of no interest to us. The value is in seconds. |
|
Well, the next next 16 more preferences to ignorepref("extensions.htmlaboutaddons.inline-options.enabled", true);
pref("fission.preserve_browsing_contexts", false);
pref("fission.rebuild_frameloaders_on_remoteness_change", false);
pref("gfx.direct3d11.use-double-buffering", false);
pref("gfx.logging.slow-frames.enabled", false);
pref("gfx.webrender.split-render-roots", false);
pref("intl.hyphenate-capitalized.de-1901", true);
pref("intl.hyphenate-capitalized.de-1996", true);
pref("intl.hyphenate-capitalized.de-CH", true);
pref("javascript.options.experimental.await_fix", false);
pref("javascript.options.mem.nursery.min_kb", 256);
pref("layout.css.line-height-moz-block-height.content.enabled", false);
pref("layout.css.resizeobserver.enabled", false);
pref("layout.css.shared-memory-ua-sheets.enabled", false);
pref("layout.css.simple-moz-gradient.enabled", true);
pref("layout.css.webkit-line-clamp.enabled", true);EDIT: Corrected an overlap of 4 prefs with the previous list |
|
Thanks @Okamoi / @WellOrientedLlama .... only 2 weeks to go. Are you guys going to get this done on time, or do I need to help out? Asking for a friend! |
|
Sorry! I pledged to do 20 prefs and ended up doing 56, but I probably won't do much more before release. I always review all preferences on my own, but the context is different here; there's more work, so I need to fine tune over several Firefox releases and figure out where to cut corners. Perfectionism is a fucking curse to guard against, it's not a virtue. So I think I'll keep the pledge approach for now, even if I increase the amount from 20. IMHO we need more people to pledge to take work off your shoulders; even a 10 prefs pledge would be great. Plus if we had 10 people doing 10 prefs each, they could even do it at maximum perfectionist snail-speed and still not feel burdened. And we would get more and better information. We can teach people how to look for data, it's not hard, it just gets tedious beyond the first few.
The second issue I have is that if I cover too many preferences, this repository's findings will not be independent from mine any more. The more prefs I cover, the less I will be able to continue using this repository to cross-check my decisions. So it is in my interest to do less, but it is also in my interest that you don't get tired of maintaining this repo. So... basically recruiting is the best solution from this viewpoint as well!
From a quick look that should not be blindly relied on, these are the remaining interesting prefs: ListNEW pref("app.update.BITS.enabled", false); // https://github.com/ghacksuserjs/ghacks-user.js/issues/743#issuecomment-501676756
pref("browser.contentblocking.features.strict", "tp,tpPrivate,cookieBehavior4,cm,fp");
pref("browser.contentblocking.maxIntroCount", 5);
pref("browser.in-content.dark-mode", false);
pref("browser.newtabpage.activity-stream.asrouter.providers.cfr-fxa", "{\"id\":\"cfr-fxa\",\"enabled\":true,\"type\":\"remote-settings\",\"bucket\":\"cfr-fxa\",\"frequency\":{\"custom\":[{\"period\":\"daily\",\"cap\":1}]}}");
pref("corroborator.enabled", false);
pref("devtools.aboutdebugging.showHiddenAddons", false);
pref("devtools.browserconsole.contentMessages", false);
pref("devtools.browserconsole.filterContentMessages", false);
pref("dom.link.disabled_attribute.enabled", true);
pref("dom.metaElement.setCookie.allowed", false);
pref("dom.presentation.testing.simulate-receiver", false);
pref("dom.vr.process.enabled", true);
pref("dom.window.open.noreferrer.enabled", true);
pref("extensions.abuseReport.enabled", false);
pref("extensions.cookiesBehavior.overrideOnTopLevel", false);
pref("extensions.htmlaboutaddons.discover.enabled", false);GONE or HIDDEN pref("devtools.aboutdebugging.showSystemAddons", false); // Migrated to devtools.aboutdebugging.showHiddenAddons ?
pref("network.cookie.same-site.enabled", true); // Why ?
pref("prio.enabled", false); // Why ?CHANGED pref("browser.newtabpage.activity-stream.asrouter.providers.cfr", "{\"id\":\"cfr\",\"enabled\":true,\"type\":\"remote-settings\",\"bucket\":\"cfr\",\"frequency\":{\"custom\":[{\"period\":\"daily\",\"cap\":1}]},\"categories\":[\"cfrAddons\",\"cfrFeatures\"],\"updateCycleInMs\":3600000}"); // prev: "{\"id\":\"cfr\",\"enabled\":true,\"type\":\"local\",\"localProvider\":\"CFRMessageProvider\",\"frequency\":{\"custom\":[{\"period\":\"daily\",\"cap\":1}]},\"categories\":[\"cfrAddons\",\"cfrFeatures\"]}"
pref("browser.newtabpage.activity-stream.telemetry.structuredIngestion", true); // prev: false
pref("browser.urlbar.quantumbar", true); // prev: false
pref("dom.storage.next_gen", true); // prev: false
pref("dom.vr.external.enabled", true); // prev: false
pref("dom.vr.openvr.action_input", true); // prev: false
pref("extensions.webcompat-reporter.enabled", true); // prev: false
pref("privacy.trackingprotection.cryptomining.annotate.enabled", true); // prev: false
pref("privacy.trackingprotection.fingerprinting.annotate.enabled", true); // prev: false
pref("security.certerrors.mitm.auto_enable_enterprise_roots", true); // prev: false
pref("webchannel.allowObject.urlWhitelist", "https://content.cdn.mozilla.net https://support.mozilla.org https://install.mozilla.org"); // prev: "https://content.cdn.mozilla.net https://input.mozilla.org https://support.mozilla.org https://install.mozilla.org" |
|
relax 🐫 ... i'm just messing with you (all) ... I took this on (i.e moving to github, with earthlng), so I'll make sure we get there. Any help is appreciated and is a bonus, not an expectation Thanks for providing links and context etc 🥇 |
That didn't work.
As long as I'm not spitting right in your face, I'm always well-oriented, whatever that means. But I'm really ready to help organise a pledge system to get more people to participate, including writing up a fishing tutorial if necessary. If you're reading this and would agree to *trying* to engage in such a promise-based participation, could you add the eyes smiley to this comment ? With 3 of those it might be worth it already, excluding Pants, Earthlng and whoever already has larger commitments to this repo. |
|
I'm not entirely sure what "a pledge system" means or entails, and given my dedication (yeah, I make not-so-subtle remarks alluding to being over-worked all the time), it will always be done. So that's not the problem IMO. The problem is I'm not an expert, at least not in all areas. I don't think any of us are. So the more eyes and brains working on it, the better the end result. As you said, "if I cover too many preferences, this repository's findings will not be independent from mine any more". <-- this Can you enlighten me as to what form a pledge system would take? By fishing tutorial, do you mean a guide on how to investigate changes (searchfox, dxr, bugzilla search parameters, etc)? PS: I'm not well-oriented at all: I'm isolated and not grounded to anything, I think. Not even sure what that means. |
|
@earthlng IDFK .. am I doing something wrong? Never had this issue before, but I don't see anything in the related bugzillas to show me the prefs were removed. I normally do all this ahead of time in the deprecated sticky |
|
changes (if anyone wants to spot check them)
moved from new to ignore
pref("apz.fixed-margin-override.bottom", 0);
pref("apz.fixed-margin-override.enabled", false);
pref("apz.fixed-margin-override.top", 0);
pref("browser.contentblocking.features.strict", "tp,tpPrivate,cookieBehavior4,cm,fp");
pref("browser.contentblocking.maxIntroCount", 5);
pref("browser.in-content.dark-mode", false);
pref("browser.newtabpage.activity-stream.asrouter.providers.cfr-fxa", "{\"id\":\"cfr-fxa\",\"enabled\":true,\"type\":\"remote-settings\",\"bucket\":\"cfr-fxa\",\"frequency\":{\"custom\":[{\"period\":\"daily\",\"cap\":1}]}}");
pref("browser.safebrowsing.prefixset_max_array_size", 524288);
pref("corroborator.enabled", false);
pref("devtools.aboutdebugging.local-tab-debugging", false);
pref("devtools.aboutdebugging.process-debugging", true);
pref("devtools.aboutdebugging.showHiddenAddons", false);
pref("devtools.browserconsole.contentMessages", false);
pref("devtools.browserconsole.filterContentMessages", false);
pref("devtools.debugger.log-actions", false);
pref("devtools.inspector.inactive.css.enabled", false);
pref("devtools.netmonitor.requestBodyLimit", 1048576);
pref("devtools.webconsole.input.autocomplete", true);
pref("dom.window.open.noreferrer.enabled", true);
// ^^ no need to enforce: nice it landed for ESR68
pref("fission.preserve_browsing_contexts", false);
pref("fission.rebuild_frameloaders_on_remoteness_change", false);
pref("gfx.direct3d11.use-double-buffering", false);
pref("gfx.logging.slow-frames.enabled", false);
pref("gfx.webrender.split-render-roots", false);
pref("intl.hyphenate-capitalized.de-1901", true);
pref("intl.hyphenate-capitalized.de-1996", true);
pref("intl.hyphenate-capitalized.de-CH", true);
pref("javascript.options.experimental.await_fix", false);
pref("javascript.options.mem.nursery.min_kb", 256);
pref("layout.css.line-height-moz-block-height.content.enabled", false);
pref("layout.css.resizeobserver.enabled", false);
pref("layout.css.shared-memory-ua-sheets.enabled", false);
pref("layout.css.simple-moz-gradient.enabled", true);
pref("layout.css.webkit-line-clamp.enabled", true);
pref("media.audiograph.single_thread.enabled", false);
pref("media.cache_readahead_limit.cellular", 30);
pref("media.cache_resume_threshold.cellular", 10);
pref("media.cache_size.cellular", 32768);
pref("media.getusermedia.insecure.enabled", false);
pref("media.videocontrols.picture-in-picture.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.flyout-wait-ms", 5000); |
|
@Thorin-Oakenpants Looked up two of the four prefs from your previous post: browser.aboutHomeSnippets.updateUrl <-- where?Removed here, functionality seems covered by lightweightThemes.update.enabled <-- where?This one, sounds like the entire update system is scrapped for lightweight themes. Maybe themes will now be updated like regular add-ons or system add-ons or search engines ? I didn't check any further. For the pledge thing, I'll get back to it later :) |
|
OK, I must be fucking tired or something, because that's exactly what I was already looking at: https://phabricator.services.mozilla.com/D27252 and couldn't see it |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1525762 : yes, I was looking at that and E said it was Part 3b but I can;t see it's removal.Maybe I need a break |
1st of all, sorry for the late reply.
https://bugzilla.mozilla.org/show_bug.cgi?id=1386214 is the one where they removed it:
another case of when searching for the whole prefname doesn't work.
|
/* 0321: disable recommendations in about:addons' Extensions and Themes panes [FF68+] ***/
user_pref("extensions.getAddons.discovery.api_url", "");
user_pref("extensions.htmlaboutaddons.discover.enabled", false);The boolean is default true in the latest dev (and E will update it with the final diff). I have to say this pref has no effect. Only blanking the URL works |
|
pref("security.certerrors.mitm.auto_enable_enterprise_roots", true);
https://blog.mozilla.org/security/2019/07/01/fixing-antivirus-errors/ |
|
68.0 changes since 68.0b9 newpref("app.update.BITS.enabled", true); // "new" with value false in 68.0b9
pref("extensions.abuseReport.enabled", true); // "new" with value false in 68.0b9
pref("extensions.htmlaboutaddons.discover.enabled", true); // "new" with value false in 68.0b9
pref("extensions.htmlaboutaddons.recommendations.enabled", true);
pref("extensions.recommendations.privacyPolicyUrl", "https://www.mozilla.org/privacy/firefox/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_content=privacy-policy-link#addons");
pref("extensions.recommendations.themeRecommendationUrl", "https://color.firefox.com/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_content=theme-footer-link");
pref("fission.autostart", false);
pref("privacy.file_unique_origin", true);
pref("services.sync.prefs.dangerously_allow_arbitrary", false);removed, renamed or hiddenpref("services.sync.prefs.sync.browser.safebrowsing.downloads.enabled", true); changed
EDIT : updated 1st post |
|
OT: it only took a shade over 2 days .. fixed with an approval-mozilla-esr68 flag. I guess if you want something fixed get gk onto it Weird how this doesn't even affect Tor Browser, but he upstreams a ticket. The examples given are uBO and uM. And yet the CSP header modification bugzilla he doesn't want to wade into (I probably don't blame him) - and the CSP issue examples includes uBO which does affect TB on Tails (and would affect TB if they include an adblocker at some stage: which they might in order to improve latency, stability, capacity etc in the Tor network) :head-scratcher: Also: For earthlng's amusement: https://trac.torproject.org/projects/tor/ticket/31134 |
|
I gotta say, this has been one of the whackiest updates in a long time, with some miscellaneous non-related BS'ery
also .. just quietly
I'm starting to feel as if something is broken, and I think I've forgotten a few other issues as well: been so many little things. Shoot me now. |
|
Edit: I just gave up and allowed images from It's like something is wrong with uBO, uMatrix (not speed dial which I did a clean install of) OT: I've narrowed it down .. again with extensions... If I use the panel dropdown and disable cosmetic filters, it goes away. But it's not a cosmetic filter: if I instead disable all cosmetic filters from the dashboard filters lists, the problem is still there. [edit: uBO] I think this is some sort of background image, and it's getting replaced with a placeholder (and uBO placeholders are disabled), which is creating an element height .. IDK .. this doesn't happen in Opera. Starting to get really fucked off with this release ... dozens, hundreds of little breakages .. why is everything fucking breaking :suicide: :smashhead: :get-wrecked: :cocaine: :beerbeerbeer:
I think I'll just see if I can change display from inline to none for |
**: this is the tool I use to extract the prefs from about:config: http://pasted.co/44159c46 In case this might be helpful, here's the list of prefs I extracted from FF68.0: http://pasted.co/71c0d34f |
When I upgraded to 68, I ended up entirely removing uMatrix and remnants, and re-installing. Seems I forgot to tick hide placeholders. I had only copypasta'ed my rules out beforehand to a text file: since the settings are only a few ticks (and I wanted to clean up rules anyway) About the only thing still iffy is some sticky cookie preferences: I swear there's like a fallback duplicate OA set somewhere due to recent changes: but I might be getting mixed up with FPI -> site permissions in 69 But I have an idea
Maybe this weekend |
That's how I did it originally but then somewhere around FF61 my script falsely reported a bunch of prefs as removed and I noticed that they started moving prefs to StaticPrefList.h and removed them from the default pref files. So I had to change my approach and getting the prefs in the same way that about:config retrieves them, seemed to be the best way to go. |
|
IMO ...
from "changed":
|
|
Sorry, I should have gotten back to this earlier, but you know, it's interesting watching it and seeing what happens. Hadn't gotten around to re-cleaning up the changed stuff
Trailhead: I never saw any trailhead about welcome. I'll do some more first post manipulations to see what's left: edit - |
|
|
WTF&^#@!&T#!: 1428901 - are they seriously considering persisting SSL session ticket IDs across sessions? Is it April 1st? |
|
^^ LOL! comment 26:
priceless |
|
comment 1, first two paragraphs. WTF are they thinking: speeding up people's first loads back to Fuckbook in a new session (see comment 2)? Gimme a break! |
|
^^ indeed. It's just a pref in case they need to roll it back due to breakage Disable getUserMedia on non-secure origins
|
|
What do you think we should do about
To save looking at E's list
I haven't looked into this, so not entirely sure of the diff between
I for one do not want anything auto-turned on (disclosure: i have no AV to test with), but then I also do not want to break the web for end users who have AV monitoring HTTPS traffic (Enterprise, I don't care: they can handle it on their own). |
|
Source: https://www.soeren-hentzschel.at/firefox/firefox-esr-68-faq/ (:de:)
|
|
In enterprise environment most probably on-premise PKI is in place, so the client need to have on-premise Root CA Cert (public) installed/deployed. IHMO, Cheers |
|
Tested with Firefox 68 under Fedora: |
|
^^ AFAIK its default false on all platforms, and only gets (permanently?) flipped to true when FF detects a MitM error (and the mitigation fixed the problem) I'm leaning towards just ignoring these two prefs. those who don't use an AV, or don't let AV meddle with HTTPS traffic: then it's a non-issue (I think). Otherwise the end-user probably needs to allow it (and if they want an AV snooping on all their traffic: that's their problem) PS: one last time: I do not care about enterprise: enterprise users can get their Enterprise IT people to sort it out if we break anything |
|
IMO we should add People who have a broken AV or other SW that MITMs their connections would have radical breakage anyway on pretty much every HTTPS request presumably. For everyone who has setup their MITM software correctly and everyone without any MITM SW, If we do that, we can ignore Even without this priming feature, FF still has a separate MITM detection that works without making additional requests and runs on every update request and blocklist update. |
|
OK, I have some time free ... lets get this finished trailhead: ignore it because it only runs on first startup. I have to admit I did not follow (read) this, and as I already mentioned earlier ("Trailhead: I never saw any trailhead about welcome"), what exactly is the threat here? super-early draft /* 1224: fuck enterprise/AV certs and stop Firefox automatically enabling them
* [1] https://blog.mozilla.org/security/2019/07/01/fixing-antivirus-errors/ ***/
user_pref("security.enterprise_roots.enabled", false);
user_pref("security.certerrors.mitm.auto_enable_enterprise_roots", false);
"have I got this the right way round?"
/* 2705: make extensions respect cookie settings
* [1] https://bugzilla.mozilla.org/1525917 ***/
// user_pref("extensions.cookiesBehavior.overrideOnTopLevel", false); // [DEFAULT: false]side-note: https://bugzilla.mozilla.org/show_bug.cgi?id=1525917#c9
Hmmm, I wonder if this has any bearing on my extensions kinda going a bit mental: seeing as I block all cookies by default. Not sure it does, as filters, rules, assets were still working, getting updated. IDK. Am so over this release. Can't wait for site permissions to be OA'ed (fun times!) - wonder how that works with temp containers |
probably because you activated some or all of the
FYI the disable value is
You could instead set I think we can ignore
|
Cool. Will amend OP
The opposite in fact. I do not override any of those whats new/welcome/url things in section 5000, I also don't have any AS (isn't that what triggers it?) ... (my start/home page is an extension)... I guess it just never gets to trigger in my setup (for now) I still do not understand the threat here. So a one off about page loads? Is that it? |
|
No one has commented on my super early draft /* 1224: fuck enterprise/AV certs and stop Firefox automatically enabling them
* [1] https://blog.mozilla.org/security/2019/07/01/fixing-antivirus-errors/ ***/
user_pref("security.enterprise_roots.enabled", false);
user_pref("security.certerrors.mitm.auto_enable_enterprise_roots", false); |
|
Trailhead - no-one has shown me that there is an actual threat, and only hinted at possible future vagueness. AFAIK, it's a one-off page. I'm not keen on adding this for that reason. If you don't trust Mozilla by now, then go use some other browser. They're not monetizing you, they're not collecting your PII, etc. Your browser connects to Mozilla to check for updates, revoked certs, update extensions - hell, just looking at your extensions will contact AMO and I'd rather stop that, than worry about a one-off. That said, I do get that some users want a "quiet" FF. I just don't see a one-off fitting this. I'd rather have less stuff in the user.js (and I also do not want to feed assholes like So AFAIConcerned, there are two options
Speak now, or never mention it again (unless how trailhead is used changes). If i got something wrong about this, then let me know: because I'm just going to ignore it, despite asking numerous times what the actual threat is (to privacy, security, tracking, FP'ing, anonymity: I can't see any threat TBH). Also: give me the heads up on the enterprise_roots. I don't really care if we do nothing TBH. If I don't get any replies, then I'll just ignore the whole lot and close this issue. Thanks |
and others
FF68 is scheduled for release July 9th
FF68 release notes [when ready]
FF68 for developers
FF68 compatibility
FF68 security advisories
237 diffs ( 133 new, 76 gone, 28 different )
new in v68.0:
240345024502removed, renamed or hidden in v68.0:
ALL DONE- 9aa8e270105b- 15409390105b- 15461900307- 1525762 (part 3b)2682- 1386214changed in v68.0:
2212- 42281a9auxclick2662input.mozilla.org2612https://input.mozilla.orgignore
click me for details
==NEW
==REMOVED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: