Open Bug 1596935 Opened 22 days ago Updated 9 days ago

Firefox doesn’t resolve <link rel=dns-prefetch> on HTTPS

Categories

(Core :: DOM: Networking, defect, P3)

70 Branch
defect

Tracking

()

People

(Reporter: code, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Steps to reproduce:

  1. Add <link rel="dns-prefetch" href="https://mozilla.org/"> to a document loaded over HTTPS

Actual results:

Nothing. The preference network.dns.disablePrefetchFromHTTPS defaults to true and blocks this from working. It works as expected on HTTP, but HTTPS is kind of the default now.

Expected results:

The DNS for mozilla.org should be resolved early. <link rel="preconnect" href="https://mozilla.org/"> works on HTTPS and it “leaks” DNS resolution just the same as rel="dns-prefetch". The policy is inconsistent. The preference for network.dns.disablePrefetchFromHTTPS should be changed to false by default.

Chrome (Android, desktop) and Safari (macOS only) supports <link rel="dns-prefetch"> on HTTPS origins by default. (Safari on iOS doesn’t support it at all.)

This was a regression, introduced by bug 1572505.
smaug, was this overseen in the review or we really wanted to disable dns-prefetch?

Flags: needinfo?(bugs)

This is not a regression.

I’ve tested versions all the way back to 30 (my PC won’t run older versions) and dns-prefetch doesn’t work in any version on HTTPS. Works fine on HTTP in all versions.

In Chrome and Safari, explicit lookups with <link rel="dns-prefetch"> works for both HTTPS and HTTP documents. In Firefox, it only works on HTTP. This bug is a request to change Firefox behavior so explicit lookups also works on HTTPS.

I believed “network.dns.disablePrefetchFromHTTPS” controlled that behavior, as setting it to TRUE makes that change happen. I’m sorry for the confusion if that setting also controls other behavior.

I presume there was a reason Chrome didn't prefetch https back then (and we followed them); what changed or what did people find out that changed the analysis? Perhaps a privacy issue?

I presume there was a reason Chrome didn't prefetch https back then

I can’t find any evidence there has ever been a test for the protocol when resolving <link rel="dns-prefetch"> in either WebKit or Chromium sources. I’ve dug through different versions of their source code all the way back to 2008. It was unintentionally broken on protocols other than HTTP in WebKit for a few months in 2010 (this was after Firefox had implemented the feature).

If I was a betting man, I’d guess that this document is the source of the confusion. It was referenced in bug #453403 (tracking the feature implementation in Firefox). The document can be read in a way that suggests that Chrome doesn’t resolve <link rel="dns-prefetch"> hints on HTTPS websites. (It doesn’t say anything about it, though.) Comments in that bug reference this behaviour. The feature implementer wrote a blog post about his work at the time. It also references this document and behavior.
https://dev.chromium.org/developers/design-documents/dns-prefetching
https://bitsup.blogspot.com/2008/11/dns-prefetching-for-firefox.html

Firefox not resolving dns-prefetch on HTTPS origins seems to just have been a misunderstanding.

Summary: Switch network.dns.disablePrefetchFromHTTPS default to false → Firefox doesn’t resolve <link rel=dns-prefetch> on HTTPS
Priority: -- → P2

This came out of bug 492196 comment 16 I suspect. It seems there were tracking concerns at the time, but I'm not sure how those are different from <link rel=stylesheet> or some such for HTTPS.

Flags: needinfo?(bzbarsky)

No, that just refactored some code. The origin of this pref and its default value is bug 453403, which is the original landing of DNS prefetch.

Bug 453403 comment 17 mentions "Do we want something akin to chromium's https thing here" but I don't see in that bug what that thing was, nor do I recall what I was talking about there; sorry, it's been 11 years. :)

The tail end of bug 453403 comment 18 does sound like at the time Chromium did not do DNS prefetch for https.

I guess all that is summarized in comment 7.

In terms of what we should do now... Martin, do you have any opinions here?

Flags: needinfo?(bzbarsky) → needinfo?(mt)
Status: UNCONFIRMED → NEW
Ever confirmed: true

How about enabling dns-prefetch and preconnect only if DoH is used?

How about enabling dns-prefetch and preconnect only if DoH is used?

Well, you can resolve DNS (and open a TCP connection and perform a TLS handshake) using <link rel="preconnect">. This is supported in Firefox on HTTP and HTTPS websites. I don’t see why <link rel="dns-prefetch"> would be any more of a privacy problem on a HTTPS page than preconnect, prefetch, preload, stylesheet, or any other link relationship that lets website load external content. <img src> would also let you resolve an arbitrary domain name from a HTTPS page.

It seems there were tracking concerns at the time […]

The (notably ten years old and possibly out of date) Chrome design document talks about disabling DNS-prefetching of domains for <a href> on hover. I can’t find anything on the web with anyone talking about privacy issues with the <link rel="dns-prefetch"> mechanism.

I'd have to do some analysis to determine what the privacy consequences of prefetching would look like. Those are not completely obvious. My intuition is that Daniel's assertion in comment 11 is probably correct, but we should do due diligence.

Flags: needinfo?(mt)

Note: knowing now (I thought it was on by default all this time) that dns-prefetch has not been used by default, it would be worth going through the code and checking if we do all security checks properly, if principals are correct, etc. before turning it on by default. Also making sure we have tests. (Maybe we do, I do not know, but there are probably people that knows)

Component: DOM: Core & HTML → DOM: Networking
Priority: P2 → P3
Whiteboard: [necko-triaged]

I don't have any evidence that it's related to dns-prefetch, but in Bug 1583298 I did collect some results where spend more time in DNS lookup than Chrome.

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #14)

I don't have any evidence that it's related to dns-prefetch, but in Bug 1583298 I did collect some results where spend more time in DNS lookup than Chrome.

How mush work would it be to retest, maybe just a part, with pref turn on?
Probably it would be faster to look at web sites and see if they send rel=dns-prefetch

You need to log in before you can comment on or make changes to this bug.