What is network.dns.disablePrefetch ?

[hackerman1]

In about:config...
What is network.dns.disablePrefetch ?
And why is it set to true ?

[ron_1]

It's a privacy issue, I believe.

https://www.pinkbike.com/news/DNS-Prefetching-implications.html
https://en.wikipedia.org/wiki/Link_prefetching#Issues_and_criticisms

[Moonchild]

As the pref's name suggests, it disables prefetching of IP addresses for host names that are in the page's content.
It's disabled for a few reasons. One is potential privacy issues, indeed. Another is to not generate unnecessary network traffic from the browser (best practice). The potential "performance win" by having an IP address ready before a user navigates (debatable, at best) that has driven this decision @Mozilla really doesn't outweigh multiplying DNS traffic by as many foreign links as there are in content.

EDIT: by the way, helloimustbegoing -- link prefetching isn't the same thing as DNS prefetching. Link prefetching is actually worse because it makes actual server requests, not just DNS lookups.

[hackerman1]

The potential "performance win" by having an IP address ready before a user navigates (debatable, at best) that has driven this decision @Mozilla really doesn't outweigh multiplying DNS traffic by as many foreign links as there are in content.

Can you please clarify this ?
I´m confused by your grammar...

Personally i noticed a real difference many years ago when DNS-prefetching was introduced in Firefox.
But, it might depend on how fast your internet-connection is...

[Andrew Gilbertson]

Can you please clarify this ?
I´m confused by your grammar...

Seemed perfectly clear to me... but let me paraphrase:

Although there is sometimes a small performance increase by setting this to false, it is relatively small; and setting it to false considerably multiplies the traffic to DNS servers, as a single page may contain links to many other servers. Therefore, Moonchild has made the decision to leave it set to true by default (while leaving the preference in place for power users who wish to flip it to false) in order to keep the browser in line with best practices of not sending unneeded requests to servers that the user is not likely to visit (as this increases network overhead in a number of ways, including recursive lookups to get DNS information for not-currently-cached items and making collision avoidance more difficult).

Moonchild: Feel free to correct anything I've said above that is incorrect. Or even insufficiently nuanced.

[Moonchild]

in order to keep the browser, in its default state, useful to those who run it on low-resource computers or in a limited-bandwidth setting.

This wasn't even a primary concern. More important is reducing what I call "digital waste". Even if it's just digital, every bit (pun intended) of digital waste still has to be processed by one or more devices. It adds up quickly.

If you load one page that has links to 10 other sites, with prefetching on, the browser will make 10 requests to the DNS server for places you're likely never going to visit. All these queries have to be recursively looked up on the Internet for no benefit at all to anyone.
In addition, not just limited bandwidth concerns, but if you are on high-latency or "collision-avoidance" networks like on wireless, this also slows things down considerably.

It is best practice from a networking point of view to only make those requests to servers that you are actually going to need (whether they are web servers or other servers like DNS).

[hackerman1]

Although there is sometimes a small performance increase by setting this to false, it is relatively small; and setting it to false considerably multiplies the traffic to DNS servers, as a single page may contain links to many other servers. Therefore, Moonchild has made the decision to leave it set to true by default (while leaving the preference in place for power users who wish to flip it to false) in order to keep the browser in line with best practices of not sending unneeded requests to servers that the user is not likely to visit (as this increases network overhead in a number of ways, including recursive lookups to get DNS information for not-currently-cached items and making collision avoidance more difficult).

Thanks, but now i´m even more confused...

network.dns.disablePrefetch = true means that DNS-prefeching is disabled.
False means that DNS-prefetching is enabled
The default setting is true, not false.

Or am i missing something...?
I understand that enabling DNS-prefetching means "extra" network-traffic, but I think you meant the opposite of what you said....

[Moonchild]

Correct. The default for the pref in Pale Moon is true, meaning prefetching is disabled, meaning Pale Moon doesn't generate this kind of superfluous traffic and as such follows best practices.

[hackerman1]

Thanks Moonchild.
I was starting to wonder if i was dumb...

[hackerman1]

This setting is "inverted", which is why it is confusing.
Usually true means enabling something...

Suggestion: rename the setting to enable.dns-prefetch, and then accordingly change the default to false.

If i remember correctly that is how it was in Firefox when it was introduced years ago.

[Moonchild]

enable.dns-prefetch

If renamed, it should certainly not be renamed to this -- sticking to the proper hierarchy to keep things logical is important.

[hackerman1]

You are absolutely right.
dns-prefetch.enable would of course be more logical, and more "proper hierarchy"...

But what i meant was: rename it to something with enable and dns-prefetch in the name,
so it is clear that setting it to true enables dns-prefetching.

[Moonchild]

It's certainly not the only boolean that is a disabling pref. As long as it's properly named, there is no issue IMHO.

But if it really bugs you that much, feel free to write a patch to invert the name and function compared to what we have now.

[hackerman1]

It was confusing when i first looked at it.
I had to think...
It doesn´t bother me now.

As you can see above (Andrew´s post), i´m obviously not the only one getting confused,
which i why i suggested that it should be renamed, and as consequence "non-inverted".

Any setting which is "inverted", where true means enabling a disabling-function is likely to cause confusion....
"Double negation" is confusing, which is why it usually is a good idea to avoid it when programming.

[Pallid Planetoid]

The key is simply whether the preference description includes the term "enable" or "disable".

If the preference description includes "enable" and the value is "true" then the setting is enabled as opposed to a value of "false" in which case the preference is NOT enabled hence "disabled".

If the preference description includes "disable" and value is "true" then the setting is disabled as opposed to a value of "false" in which case the preference is NOT disabled hence "enabled".

The confusion is understandable on the basis that "false" is intuitively interpreted as disabled and "true" as enabled, but that is only the case when a preference does not include a qualifier of either "enable" or "disable" in the description.

Clear as mud, huh?

[hackerman1]

Clear as mud, huh?

Exactly....