ToDo: diffs FF54-FF55 #144
Comments
|
432 diffs!! man this is gonna suck!! I think I'm gonna be MIA until you and hopefully an army of contributors are done with this. |
new in v55.0b1:
All the crap after |
|
|
... money, money, money. They realized they miss out on "credits" for "follow-on" searches.
at least they are transparent about it |
/* 12xx: disable TLS1.3 0-RTT (round-trip time)
[1] https://github.com/tlswg/tls13-spec/issues/1001
[2] https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ ***/
user_pref("security.tls.enable_0rtt_data", false); // false in FF51+, true in FF55+ |
|
from new ... pref("plugins.http_https_only", true);
pref("plugins.remember_infobar_dismissal", true);
pref("plugins.show_infobar", true);
pref("urlclassifier.flashInfobarTable", "except-flashinfobar-digest256");IMO can all be ignored because it's Flash stuff
|
|
edit: WTF! this shit even includes google-analytics! [ 💩 💩 💩 💩 💩 - edit, Thorin, 5-turd award] |
|
IMO...
|
When I installed nightly 56 I also created a quick diff and this pref showed up under
|
DXR nightly - they are not in any of the default preferences files = hidden prefs for sure. In 56nightly: 551x751 = 400x700, 549x749 = 400x700 https://dxr.mozilla.org/mozilla-central/source/dom/base/nsContentUtils.cpp#2447 400 = 551 - (551 % 200) = 551 - 151 |
|
width needs to be a multiple of 200 (1x200,2x200,etc), height can be any round hundred. It just can't be higher than your real screen resolutions width/height. fe with a 1920x1080 screen resolution you can use width: 200,400,600,800,1000,1200,1400,1600,1800 together with any round hundred height between and including 100 to 1000. No 2:1 ratio at all as long as what you set fits on your screen |
|
What's up with Do you know how Tor Browser reacted to this ? It wouldn't make sense that nothing else happened because both Firefox and Tor teams are in sync for such things. Like, is |
|
Well the User Timing API now can't be disabled. The Tor team already added time wobble in their patches, and at the same time they disabled the API, so I'm not sure that this kind of imprecision reaching Firefox as opposed to just being a Tor patch is compensating anything regarding the loss of I'm kind of mixed on this, I'd be more open if not for Tor team's decision which I trust. I'm a little surprised that this sounds like a non event to you though :) |
|
I'm sold for the time. But is it the name + scope thing mentioned here covered too ? Damn API provides more information than neat timestamps unfortunately. I trust your pinky, it's actually the reason I'm asking this to you. For some reason you and earthlng appear to be better at searching Bugzilla and Firefox innards than I am, when things get obscure, which drives me crazy. |
|
but
we can add it as ESR doesn't have this pref yet and the only alternative there is to change |
|
|
[Edit: Agreed, besides it totally looks like a spec/web-compat thing and has no privacy/tracking implications IMO - Thorin ] |
Security and Privacy Considerations section for WebVTT: |
|
Thanks for your help here @2glops
👎 - https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API#CSS_pseudo-classes there's IMO it's useless to include this pref. If you want to "disable"/block WebVTT there are other ways, fe with uBO: |
|
Thanks for the invitation ! |
Edit: Yup, that seems pretty harmless - Thorin |
Because it's the one major flaw in TLS1.3
They've since implemented some anti-replay mechanisms @ https://bugzilla.mozilla.org/show_bug.cgi?id=1295163 - no idea how effective that is though or when that landed. We can ignore this pref if we disable TLS1.3 again instead. Or not give a shit, idc tbh, I know what I will do. |
Edit: Thorin - Yup, see my comment a few posts up with exploit link and bugzilla link. Was wondering what effect adding it and ramping up to 2 would have, but yeah, ignore for now. It is a good security fix though, so at least its documented and can be easily found in the repo |
|
Add a passive (detection only) mode for Tracking Protection
Lower priority of HTTP requests for resources on the Tracking Protection list
The network tab should flag resources on the tracking protection list
|
The annotations themselves are a purely internal thing. It means every time we're about to load a URL, we check it against the TP list. If it's on the TP list, we mark that URL as a tracker. It's just a mark though: by itself, it doesn't do anything. Therefore, there's not really any point in disabling that. The other pref, There's also another pref, I think it's |
That's adding an API to let extensions (e.g. Lightbeam) toggle TP on and off. |
Well, the existence of the annotation feature and its intended uses implies that turning TP off may not completely disable all tracking protection related mechanisms. So I quickly searched, and found this from a Francois Marier (@fmarier ?): https://bugzilla.mozilla.org/show_bug.cgi?id=1345158#c7 If enabling the annotation feature will cause TP list related client<->server communications, we then have to determine what the risks of those are. Is it a pure download which never involves passing hashes, urls, identifiers, or other significant info to the server? Is the list a list and form that multiple people can download and easily compare to verify they are getting the same exact version? Or are we talking about a Safe Browsing protocol that isn't as clean as that? Plus, there is another potential issue. Which is Firefox messing around with the priority of things which are on Mozilla's list. A list that may contain entries that users do NOT want deprioritized or whatever. Maybe not a problem unless someone does the "it has be enabled for awhile, time to remove the prefs" thing. |
Exactly. That's why I suggested to include it in the user.js. IMO we should include the 2 "passive TP" prefs, active and both set to false. They are ignored anyway if "active" TP is enabled. |
Oh yeah, I didn't think about that. So I guess that means that once both of the passive TP prefs default to true then TP blocks requests in PB windows, and in normal windows the passive TP kicks in and lowers priority. |
|
https://bug1357835.bmoattachments.org/attachment.cgi?id=8859667 Honestly, would any of you have entered your bugzilla account credentials into that prompt? 🤦♂️ xD |
|
^^ Hmmm... my parents would fall to trickery. ;) |
|
Apple doesn't fall far from tree. So you know now from where your beer-jar is filling up. :) |
Lol, yeah I guess that's a valid concern. Let's include it then. Where do we put it? 0900 Passwords? or 2600? /* xxxx: prevent cross-origin images from triggering an HTTP-Authentication prompt (FF55+)
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1357835 ***/
user_pref("network.auth.subresource-img-cross-origin-http-auth-allow", false);IMO the bugzilla link is enough info |
|
|
|
How about this for the passive TP? /* 04xx: disable passive Tracking Protection
* Passive TP annotates channels to lower the priority of network loads for resources on the tracking protection list
* [NOTE] It has no effect if TP is enabled, but keep in mind that by default TP is only enabled in Private Windows
* This is included for people who want to completely disable Tracking Protection.
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1170190
* [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1141814 ***/
// user_pref("privacy.trackingprotection.annotate_channels", false);
// user_pref("privacy.trackingprotection.lower_network_priority", false); |
Yes to both of these. More details can be found here: https://feeding.cloud.geek.nz/posts/how-tracking-protection-works-in-firefox/
s/Mozilla's/Disconnect's/ Not sure why a user would want to avoid de-prioritizing trackers given that this feature doesn't break anything (otherwise it's considered a bug). This is purely a performance improvement. |
You don't need to disable that second one. If annotations are disabled, the network prioritization code will not do anything. |
I put it in for informational purposes so that people know there's a 2nd pref that can be toggled independently. Later on the annotations will be used for other things as well and maybe someone wants those other things but not the network throttling for example. Or someone on FF55 wants to use the prioritization and doesn't realize that the 2nd pref is still defaulting to false. Can you comment on this:
is that the desired effect and how it will work for the foreseeable future? Are you putting that into the release-notes or something because how else are "normal" people gonna know about this stuff otherwise? |
I think it's scheduled to ship in 57, so I'd look for those release notes when it comes out. |
|
Given the issue closure I'll keep this to a minimum. @fmarier: How to stop Firefox from making automatic connections suggests that disabling tracking protection will stop the tracking protection list update connections. Will that page be updated to inform people that they also have to disable privacy.trackingprotection.annotate_channels? |
|
@Atavic: I asked because of https://bugzilla.mozilla.org/show_bug.cgi?id=1345158#c7 and there is code in https://dxr.mozilla.org/mozilla-release/source/toolkit/components/url-classifier/SafeBrowsing.jsm which appears consistent with that (superficially): mozilla-central has the same. |
After a glance, I see you are right. |
Yes, that needs to be updated. Feel free to submit a change there. It's a wiki that anybody can edit, though changes are reviewed to prevent spam. |
v54.0 vs v55.0
432 diffs ( 207 new, 66 gone, 159 different )
new in v55.0:
2699- no longer hidden - 1345322, 6ef86fbremoved, renamed or hidden in v55.0:
All DONE - see 48511d1
13643341361220135206912413901361578browser.selfsupport.enabled1352069134466913529491072859changed in v55.0:
11040201030404130850e080824262415b250426290608ignore
==NEW
53 font.name* prefs
==REMOVED or HIDDEN
==CHANGED
114 font.name* prefs
The text was updated successfully, but these errors were encountered: