ToDo: diffs FF77-FF78 #959
Comments
some bugzilla tickets
|
|
@earthlng why was this pulled out for action? sorry, I haven't looked at it yet the rest: anyone who wants to do some homework, dig in how does this sound?
|
Leaving it set to 1 uses internal Firefox heuristics to determine whether the word gets resolved or not, setting it to 2 will always resolve the single word and setting to 0 will never resolve the single word. |
|
I suggest something like this: Personally I have the last line uncommented. Edit: Sorry, my bad. Should have checked it before posting. Search engine keywords work no matter what. |
|
3: Source: https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#5753 4: leave |
This comment has been minimized.
This comment has been minimized.
|
@Thorin-Oakenpants I also read the code for browser.urlbar.dnsResolveSingleWordsAfterSearch. Currently there's no heuristic at all (bug 1642623), i.e. 1=2='always resolve' for now. In the future they want to check the user's host file or if DOH is used, etc. |
|
I just mentioned DoH and host file checking because Mozilla plans including it in the heuristic they want to implement for browser.urlbar.dnsResolveSingleWordsAfterSearch in future versions. In other words, another suggestion: |
|
OMG YES! no expanding urlbar anymore in FF78 with ui.prefersReducedMotion=1! Hallelujah! Thank you black Jesus :) |
yes.
AFAIK 5 + 6 control what's used as the origin attribute for 1st-party isolation. dFPI will now use "site" whereas FPI will remain just domain. A bit weird that they use different OAs but I guess it's best to not mess with it at this point because IDK if all the things isolated by FPI will still work with "site" instead of domain. |
is that related to
|
|
|
I monitored my DNS-traffic: |
|
Thanks for testing @guser-sudo!
yeah but isn't that because it tries to access that "keyword" as a hostname? Unless you previously accessed that hostname and therefore still have it in your MAC or DNS cache, that access would necessarily require a dns lookup, right? ie, with keyword.enabled=false, when I enter "pants" in the urlbar it'll try to access http://pants/. So, as I understand it, dnsResolveSingleWordsAfterSearch=0 only makes sense with keyword.enabled=true ie you always want to search for single words and never try to resolve it as a hostname. |
they haven't decided yet. https://bugzilla.mozilla.org/show_bug.cgi?id=1642623#c8 lists some of their ideas atm:
|
|
@earthlng |
|
@Thorin-Oakenpants What happened to the |
- `0105e` - we disable AS, and clearing the default does not stop someone adding their own (it's a different pref) should they chose to use AS - otherwise, to get rid of the topsites when clicking in an empty urlbar, users have to either know about this pref or enable AS and go manually remove them all - this is cleaner than disabling topsites with `browser.newtabpage.activity-stream.default.sites` as that actually breaks the functionality (should users want to use AS and topsite suggestions) - we don't disable topsite suggestions: 0850a: 78+, `browser.urlbar.suggest.topsites` is inactive: but if a user does want to disable that - 0850a - we could elaborate that this is for suggestions when you start typing/pasting (i.e not the same as topsites) - IDK - settings (changed) - we can remove these two when ESR68 hits EOL, meanwhile I just tagged them as (FF72-) - settings (not changed) - `0517` does not seem to exist: [SETTING] Privacy & Security>Forms and Autofill>Autofill addresses (FF74+) - I tested vanilla profiles in 74+, and system addon `formautofill@mozilla.org.xpi` is present - maybe I'm doing something wrong - `0420`: ui.PRM - maybe you can word it better
|
maybe something like this for dnsResolveSingleWordsAfterSearch: /* 0811: disable location bar leaking single words to DNS provider when keywords (0801) are enabled [FF78+]
* 0=never resolve single words, 1=heuristic (default), 2=always resolve
* (For FF78 value 1 and 2 are the same and always resolve but that will change in future versions)
* [1] https://bugzilla.mozilla.org/1642623 ***/
user_pref("browser.urlbar.dnsResolveSingleWordsAfterSearch", 0);IDK if we need to explain more than that, fe that with keywords disabled all single words are treated as hostnames and could "leak" (unless you have them in your hosts file (and don't use DOH because DOH currently doesn't check hosts)). We can also add |
|
Firefox 78.0.1 with no proxy here. I tested setting network.dns.disabled to true and I wasn't surprised more than that with the effect : no connection. |
|
Did anyone noticed the DNS leak when |
|
@crssi |
|
@Thorin-Oakenpants wrote above, concerning network.dns.disabled
I linger as well to understand this setting's pertinence. No VPN here and no FF TRR, DNS is resolved with DNSCrypt-proxy (hence its own DNS servers). Maybe makes sense with FF's DoH (TRR)? I'm really looking forwards to understand why/where the setting is useful. |
|
I just turned on |
|
@guser-sudo |
I wouldn't call it the same effect: It prevents the search and does a DNS lookup because you probably want to reach a local resource. |
that's exactly how it's meant to be read :)
yeah but after it tried to resolve pants ie dns leak @crssi are you sure you didn't send the single word to your search engine ie something like "d word"? The leak only happens if you enter a single word without a search-engine keyword/letter |
|
I never use |
|
I have build a new profile from scratch. And everything is as you say and cannot reproduce. Update: Forget I have written anything, just can't reproduce anymore and I have no clue why is that. |
|
|
this is what the prompt looks like:
But the prompt only shows up if the DNS lookup actually found a host with that name. That's why I used The way I tested it was a new fresh profile with the latest user.js, (optional: change default search engine to the builtin DDG), then in about:config change This is just to illustrate the prompt though - the DNS leak doesn't really happen here because localhost is in everyone's hosts file and that's looked up prior to any remote DNS lookup. (unless you use FF's DoH!) With that test environment now in place you can test when (or not) the prompt shows up, ie search buttons etc. If it doesn't show up it most likely means the DNS lookup didn't happen but I haven't verified that with wireshark or similar. BUT just make sure you never click the "Yes, take me to ..." button because that will set a pref and mess up further testing! In my test it apparently didn't try a DNS lookup when I clicked one of the one-off search buttons to trigger the search nor when I used a search-engine keyword/letter. FYI I hope this helps |
|
Does anyone care about adding
Does anyone care about adding these as true, now we know what they do (inactive)
Does anyone care about 2200
I tried doing various tests here, and I have my own tests, and I just don't get it. I can still remove all those items: menubar, personalbar and toolbar (but I can't add them?). I also got some really whacked out results, where I loaded the test in a popup and the changes were being applied to the parent window (and I could show/hide things like the menu, toolbar etc) I just don't know if I can be fucked dealing with this mess |
/* 400x: Isolate DNS cache per first-party [FF78+] ***/
// user_pref("privacy.partition.network_state", true);
/* 400x: Isolate by site and not by domain [FF78+] ***/
// user_pref("privacy.firstparty.isolate.use_site", true); |
It is being used to isolate some things that FPI didn't. Maybe they'll even move things to use this so it's simpler from an engineering point of view. Here is the meta ticket FPI was going to isolate font cache (pretty sure this is the graphics card cache) - that was 1560580, but this has been dropped and instead is covered with "Network" being distinct from web content : "This leaves storage, permissions, cookie jars etc alone but isolates cached and network stuff by site. Nothing that should be observable to a website (except through side channels.)" We certainly don't need to add any of these for this release, but probably will at some point. And at that point when they are ready to use (bugs), they will most likely be flipped |
FF78 is scheduled for release June 30th
FF78 release notes [when ready]
FF78 for developers
FF78 compatibility
FF78 security advisories
other
ui.prefersReducedMotion=1- 3d18af12200:dom.disable_window_open_feature- see 1507375, compat100 diffs ( 63 new, 19 gone, 18 different )
new in v78.0:
sitesinstead ofdomainssitesinstead ofdomainsremoved, renamed or hidden in v78.0:
ALL DONE- 77ecef82031pref("media.autoplay.enabled.user-gestures-needed", true); - 15099335000'spref("toolkit.cosmeticAnimations.enabled", true); - 1640501changed in v78.0:
1202pref("security.tls.version.min", 3); // prev: 11263pref("security.ssl3.dhe_rsa_aes_128_sha", false); // prev: true1263pref("security.ssl3.dhe_rsa_aes_256_sha", false); // prev: true0105cpref("browser.newtabpage.activity-stream.feeds.section.topstories", true); // prev: falseignore
click me for details
==NEW
==REMOVED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: