ToDo: diffs FF69-FF70 #805
Comments
some bugzilla tickets
|
|
moved from NEW to ignore:
|
|
OT: 1576254 cool Edit: and hopefully backported to ESR |
|
FYI: FF70+ (and ESR68.1.0+) will allow extensions to use SVG content regardless of whether the Maybe worthy of a |
|
70.0 changes since 70.0b8 newpref("browser.contentblocking.report.lockwise.url", "https://lockwise.firefox.com/?utm_source=firefox-desktop&utm_medium=referral&utm_campaign=about-protections&utm_content=about-protections"); // "https://lockwise.firefox.com/" in FF70.0b8
pref("browser.contentblocking.report.proxy_extension.url", "https://fpn.firefox.com/browser?utm_source=firefox-desktop&utm_medium=referral&utm_campaign=about-protections&utm_content=about-protections"); // "https://private-network.firefox.com/" in FF70.0b8
pref("browser.newtabpage.activity-stream.discoverystream.engagementLabelEnabled", false);
pref("devtools.debugger.features.inline-preview", false); // true in FF70.0b8
pref("devtools.storage.extensionStorage.enabled", true); // false in FF70.0b8
pref("dom.security.respect_document_nosniff", false); // true in FF70.0b8
pref("security.allow_eval_in_parent_process", false); // true in FF70.0b8
pref("security.allow_eval_with_system_principal", false); // true in FF70.0b8removedpref("plugin.persistentPermissionAlways.intervalInDays", 90); changed
EDIT : updated 1st post |
|
@Thorin-Oakenpants none of these pref changes landed in ESR. They still have their old values and/or are still hidden in ESR |
|
NEW prefs which we can ignore IMO:
👖 : done, and I added |
|
If someone wish to have an "old" green padlock instead of a new "gray": |
This comment has been minimized.
This comment has been minimized.
|
^^ If I delete that folder and create a file with the same name, then FF cannot create the folder and files in it... and YT still works at 1080p/Max (also 4K) resolution. Edit by Thorin: just delete the folder and set |
This comment has been minimized.
This comment has been minimized.
|
Ok. One more thing. I`m notice when user open site with a self-signed certificate FF phone to:
You can check using this site: It can be stopped: May I find out why you still haven't added this to user.js? |
This comment has been minimized.
This comment has been minimized.
|
@Dragomir7 the purpose of that pref is to inform you of potential MitM attacks. The mechanism triggers only during cert-related errors, and Mozilla's servers receive almost no information whatsoever about you in the process. That does not qualify as "phoning home" IMO. See #740 for more info (skip to this comment if you don't feel like reading everything). |
I mentioned it here and actually proposed to disable it.
are you sure? I think this only covers local MITM like AV and things like that. |
This comment has been minimized.
This comment has been minimized.
Yeah, attack or not, that's probably the main goal, but it also detects at least one specific type of MitM attack outside the local network (it's not 100% reliable).
I speak with certain confidence because I looked at the source code at the time this was implemented (haven't looked at it since). As you said, leaving that pref enabled does not increase security, because cert errors are enough to cover that, but when priming triggers, it does not directly inform Mozilla of anything. They don't get to know what's the site in question or anything else. It's a ping. |
|
It's also worth mentioning that |
|
Just in case, I want to make clear that I'm neither for nor against adding this pref to the |
that's correct. It does not leak fe the visited site that triggered the error page in the 1st place as @Dragomir7 believes
but this priming feature is not about "protection" and only about better information. All it does is in some cases upgrade the UNSEC_ERROR message to a page informing you about a potential MITM. ie the MITM attempt would have already failed because otherwise you wouldn't get the error message in the 1st place. https://bugzilla.mozilla.org/show_bug.cgi?id=1529643#c0:
ie the only reason why they added this ping feature is "because the user's browser may not have triggered any internal requests at the time they view the certificate error." and explicitly to help with their AV MITM detection ie local MITM |
oh nvm, you already acknowledged that "leaving that pref enabled does not increase security, because cert errors are enough to cover that" |
|
@crssi wrote:
1270 doesn't matter anymore because we enabled 1201 a while ago. On that note, AFAICT the title of 1201 is actually incorrect because that pref is about "negotiation" not re-negotiation and the note about % of servers not supporting secure renegotiation therefore probably irrelevant ... https://wiki.mozilla.org/Security:Renegotiation:
and under https://wiki.mozilla.org/Security:Renegotiation#security.ssl.require_safe_negotiation:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hmmm... in my overrides I have 1201 set to false and it still doesn't matter from GUI point of view... talking about padlock icon, not saying whats behind-the-scene, since as a noob I really don't have a clue. 😉 |
|
I added I put it as |
|
Both can/should be ignored.
https://dxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#1687-1692
Setting this to |
|
Yeah, I left it there to remind me about fingerprinting widgets, which is already a known issue, and I already have something in the pipeline (as does Mozilla) Edit: also moved
|
|
browser.newtabpage.activity-stream.discoverystream.enabled added in FF69 (false), flipped true in FF70
// These prefs control if Discovery Stream is enabled.
#ifdef NIGHTLY_BUILD
pref("browser.newtabpage.activity-stream.discoverystream.enabled", true);
#else
pref("browser.newtabpage.activity-stream.discoverystream.enabled", false);
#endif
pref("browser.newtabpage.activity-stream.discoverystream.hardcoded-basic-layout", false);
pref("browser.newtabpage.activity-stream.discoverystream.spocs-endpoint", "");
So AFAICT, this has no affect on whether or not anything is displayed or not, that's still the checkboxes and relative prefs in the UI. And it won't even be used if you don't use AS as a landing page: which is what I said here So moving to ignore |
|
I have NFI about get, head or cors: so someone else will have to decide without explaining (earthlng) or explain it to me (anyone else) why this can be ignored or why it should be added at what value and what state (active/inactive). Otherwise I cannot move forward with closing this ticket (edit: unless I stick it on the sticky issue of items to investigate, or move it to the next diffs) // FF59+
// Include an origin header on non-GET and non-HEAD requests regardless of CORS
// 0=never send, 1=send when same-origin only, 2=always send
pref("network.http.sendOriginHeader", 2); // prev: 0sources |
|
I would say |
|
I'm asking anybody Mozilla (like Chrome) is changing from highlighting secure sites, to highlighting insecure sites - e.g no padlock = good, padlock = bad. Not sure on the rollout of that stuff and its not worth looking up, TBH. So all I really need to do is a test, on both ESR68 and FF68. That's with 1270 and 1201 both inactive and at default. So I want a test page. Either someone does the tests for me, or gives me a test page to trigger the "red padlock" in 1270 |
|
On FF 70 the "red padlock" is triggered in any case on HTTP site. Try UPDATE: That is not the case for FF 68.2 and ESR68.2 (portable) vanilla... "red padlock" is not triggered on |
but we need to explicitly test for the case in 1201 .. and I don't fully understand the whole (re)negotiation thing - but doesn't it still mean you end up with HTTPS (no need to answer). The thing is it might be impossible to find a working test. And we'd only keep 1270 as a fallback (if it actually does something: hence the required test) in case someone flipped 1201 /* 1201: disable old SSL/TLS "insecure" negotiation (vulnerable to a MiTM attack)
* [1] https://wiki.mozilla.org/Security:Renegotiation ***/
user_pref("security.ssl.require_safe_negotiation", true);
/* 1270: display warning (red padlock) for "broken security" (see 1201)
* [1] https://wiki.mozilla.org/Security:Renegotiation ***/
user_pref("security.ssl.treat_unsafe_negotiation_as_broken", true); |
|
Sure, as said before, I am seeing this from UI perspective only. There must/might be something more behind-the-scene. |
Sound related to @claustromaniac Extension. https://addons.mozilla.org/de/firefox/addon/privacy-oriented-origin-policy/ |
|
testpage for 1201 + 1270: https://secure.brightcove.com/
SGTM. Maybe add a note to 1270 that there's this bug: warning padlock not indicated for subresources on a secure page The red padlock on http sites that @crssi is talking about is probably due to |
Thats it 👍 |
|
same behavior on ESR68, FF68, FF70, FF72 about:config: security.ssl*negotiation
OK, my mind is zonked, but I'll try (correct me if I fuck up)
So: in order to make it simpler, we could merge 1270 into 1201. And we can fix up the description and add the bugzilla about subresources. Does anyone want to have a stab at that while I take a break? |
in order to not block pages (or subresources in some cases), 1201 would need to be false. |
yup, completely fucked that up. I knew it, I could feel myself getting totally exhausted and not thinking straight trying to match pref numbers to pref names to defaults to what we have Meanwhile - what do you think if we merge 1270 into 1201 - thumbs up if you agree: I'll do a PR tomorrow after a sleep - @earthlng |
|
yeah, do a PR and we can take it from there. But please, no hurry! like, don't close it if I don't respond in a timely manner etc ;) |
|
I can't make any headway with these: too many variables and I do not know enough about WebRTC (i.e, I know nothing) /* 2002: limit WebRTC IP leaks if using WebRTC
* [TEST] https://browserleaks.com/webrtc
* [1] https://bugzilla.mozilla.org/buglist.cgi?bug_id=1189041,1297416
* [2] https://wiki.mozilla.org/Media/WebRTC/Privacy ***/
user_pref("media.peerconnection.ice.default_address_only", true);
user_pref("media.peerconnection.ice.no_host", true); // [FF51+]pref("media.peerconnection.ice.obfuscate_host_addresses", false);
I think/hoope this will get flipped when they iron out the bugs - but if they don't then we'll never pick up on this pref again? The pref name looks like it should be true from a privacy standpoint pref("media.peerconnection.ice.proxy_only_if_behind_proxy", false);
I read it, twice, and am still none the wiser. I think it can be ignored |
|
When you mention WebRTC... I don't know why not leave And thank you @Thorin-Oakenpants and @earthlng for your hard work... I really love you guys ❤️ . |
|
re: media.peerconnection.ice.proxy_only_if_behind_proxy these are the WE API values for controlling this WebRTC thing:
you can the see the prefs+values associated with each setting here.
1452713#c23 explains
The new They also mention uBlockOrigin in that bugzilla and uBO currently uses
emphasis mine. I think after 1452713 ie FF70+, @gorhill can now use |
|
re: media.peerconnection.ice.obfuscate_host_addresses 2002 already has "no_host" and thus I don't think "obfuscate_host_addresses" really matters. |
|
I'll just defer that to you, go ahead and commit it we disable WebRTC because |
Thank you. Need to learn how to do it. But first I will read all bugzillas. |
That was for earthlng, the @crssi was for the subsequent message |
|
OK, never-mind, did some tests anyway. FF 70.0.1 plan vanilla + latest user.js + The following tests: does not leak internal IP, but the deviceId stays the same for a session until restart. |
FF70 is scheduled for release Oct. 22nd
FF70 release notes [when ready]
FF70 for developers
FF70 compatibility
FF70 security advisories
misc TODO's:
2610FF70+ and ESR68.1.0+svg.disabledno longer affects extensions - - a3611b72701cookie behavior default changed it's name in the UI - 65dfad5289 diffs ( 200 new, 52 gone, 37 different )
new in v70.0:
pref("security.identityblock.show_extended_validation", false);pref("security.secure_connection_icon_color_gray", true);pref("browser.urlbar.megabar", false);removed, renamed or hidden in v70.0:
changed in v70.0:
ALL DONE- 539750d0602pref("network.dns.disablePrefetchFromHTTPS", true); no longer hidden, needs[DEFAULT]tag1003pref("browser.cache.memory.capacity", -1); no longer hidden1273pref("security.insecure_connection_icon.enabled", true); // prev: false1273pref("security.insecure_connection_icon.pbmode.enabled", true); // prev: false2608pref("devtools.webide.enabled", false); // prev: true4002pref("privacy.firstparty.isolate.block_post_message", false); no longer hiddenignore
click me for details
==NEW
==REMOVED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: