Connections to blocked hosts due to Early Hints

[ElhemEnohpi]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

In Firefox with Early Hints preconnect enabled (default since 120), connections are made to hosts even when the destination hosts are fully blocked in uBlock.

A specific URL where the issue occurs.

https://medium.com

Steps to Reproduce

1. install uBlock Origin in a fresh Firefox profile
2. create a rule: * google.com * block
3. go to medium.com

Expected behavior

No connection to google.com

Actual behavior

Firewall (Little Snitch) shows a connection attempt to www.google.com (not only a DNS lookup), even though uBlock shows it as blocked. It looks like no actual data is exchanged, but there is a socket connection to Google, that exposes metadata.

If you go to about:config and toggle false: network.early-hints.preconnect.enabled and repeat the steps, there is no connection attempt detected. Workaround is to keep this disabled, though it reduces performance.

The medium.com page HTML also has <link data-rh="true" rel="preconnect" href="[https://www.google.com](view-source:https://www.google.com/)"/> but this is not the source of the issue; that can be confirmed by disabling network.preconnect, which controls HTML links. The source is "103 Early Hints" from the server.

uBO version

1.68.0

Browser name and version

Firefox Developer 146.0b9 and any other version since 120.

Operating System and version

macOS 26.1

[gorhill]

Duplciate of #2913?

[ElhemEnohpi]

I didn't think it was a duplicate. That one is only about DNS requests, and it's stopped by disablingnetwork.preconnect. That preference controls HTML <link rel="preconnect"... tags. In #2913 (comment) you said "Just to be clear, those DNS requests are not "from google analytics and other google ads related domains", they are from your browser, Google-related domains are unaware of these DNS requests."

I'm seeing actual connections to the www.google.com server. It only happens when visiting a few sites that use Google reCAPTCHA and send 103 Early Hints, like medium.com. It's only a pre-connection, and the subsequent data exchange like downloading the reCAPTCHA script is blocked as expected. Still, it would be better not to contact the Google server at all. Only disabling network.early-hints.preconnect.enabled stops it. I saw this in a log:

...Socket Thread]: V/nsHttp DnsAndConnectSocket::SetupStreams [this=347f2cd20 ent=.S........[tlsflags0x00000000]www.google.com:443^partitionKey=%28https%2Cfaun.pub%29] setup routed transport to origin www.google.com:443 via :443
...Socket Thread]: E/nsSocketTransport nsSocketTransport::Init [this=16b1d7100 host=www.google.com:443 origin=www.google.com:443 proxy=:0]

After that, there were just timeouts and the HTTP connection never happened. I have my firewall set up to notify me if anything tries to connect to Google, and this triggered it, even though uBlock says that the connection to www.google.com was blocked.

[gorhill]

uBlock says that the connection to www.google.com was blocked

uBO reports what is happening at the webRequest listeners' level, if something is happening outside webRequest API, it's out of view of uBO, and you will have to report to browser devs.

---

Do you see those connections in the browser dev tools?

[ElhemEnohpi]

I saw the connections by using about:logging with the Networking preset, that includes nsSocketTransport module. In the Profiler, you can see them by enabling the Socket Thread lane, or log to a file.

I guess I can try to file a bug with Mozilla. Maybe eventually uBO would mention it and/or include a switch to turn off network.early-hints.preconnect.enabled in the Privacy section, but not sure if that's appropriate or not.

[stephenhawk8054]

I'm seeing actual connections to the www.google.com server.

If there are no requests in the network devtools, there are no connections being made to google.com server. It's exactly what gorhill said: the browser only makes DNS resolution with your DNS server, your requests don't reach google.com server.

---

include a switch to turn off network.early-hints.preconnect.enabled in the Privacy section

In order for an extension like uBO to turn off that config, there has to be an API for uBO to turn on/off. Are there any APIs from Firefox for extension to toggle that config?

[uBlock-user]

If there are no requests in the network devtools, there are no connections being made to google.com server.

unknown tab(0,1) type connections are not reported in Firefox dev-tools but uBO sees them in the logger, very strange.

[ElhemEnohpi]

If there are no requests in the network devtools, there are no connections being made to google.com server. It's exactly what gorhill said: the browser only makes DNS resolution with your DNS server, your requests don't reach google.com server.

DNS resolution doesn't trigger my firewall, only a connection attempt to the host does, like this:

And if I allow it, tcpdump shows an actual connection to www.google.com (aka fra24s11-in-f4.1e100.net) is made:

IP mac.52785 > fra24s11-in-f4.1e100.net.https: Flags [SEW], seq 2502424998, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3450630289 ecr 0,sackOK,eol], length 0
IP fra24s11-in-f4.1e100.net.https > mac.52785: Flags [S.], seq 2211163157, ack 2502424999, win 65535, options [mss 1412,sackOK,TS val 3710931116 ecr 3450630289,nop,wscale 8], length 0
IP mac.52785 > fra24s11-in-f4.1e100.net.https: Flags [.], ack 1, win 2057, options [nop,nop,TS val 3450630313 ecr 3710931116], length 0
...

If I turn off network.early-hints.preconnect.enabled this doesn't happen. Please test the steps to reproduce yourself, if you think I'm mistaken.

I don't think there is currently an API to turn it off. This bug report is intended in part to open discussion of whether that might be desirable.

[stephenhawk8054]

Does the connection appear in the network devtools in your browser?

---

Also, as we said, if Firefox provides no APIs, there's no ways for uBO to toggle that config.

[stephenhawk8054]

Ok, looks like Early Hints would trigger responses from the target server as well: https://www.rfc-editor.org/rfc/rfc8297#page-3 , so it's more than sending DNS resolution requests.

If I'm not wrong, currently this is out of webRequest scope so uBO can't block it. I don't know if there are any APIs for extensions related to Early Hints or not.

[stephenhawk8054]

I saw the connections by using about:logging with the Networking preset, that includes nsSocketTransport module. In the Profiler, you can see them by enabling the Socket Thread lane, or log to a file.

However, when I use Firefox about:logging tool, the results in Socket Thread lane for google.com when turning on/off network.early-hints.preconnect.enabled look the same for me.

[ElhemEnohpi]

You can try logging to a file. I see e.g. [Parent 24386: Socket Thread]: E/nsSocketTransport nsSocketTransport::Init [this=14a824100 host=www.google.com:443 origin=www.google.com:443 proxy=:0], as well as a firewall notification and connection in tcpdump while opening medium.com, only with network.early-hints.preconnect.enabled, and not when it's off. The Web Developer Tools don't show the TCP preconnection, only the blocked HTTP request.

The webRequest docs say something about speculative requests, but I don't know the details. I wouldn't be surprised if it's something uBO can't block currently. Not sure if it's worthwhile to pursue changes. Since no payload data is exchanged, it's kind of a minor issue, but some of the more privacy-minded people might not want even pointless connections made to blocked hosts, and may feel it's unexpected to see them happening with uBO installed.

[stephenhawk8054]

The point is if there are no APIs for extensions, there would be no changes to "pursue". It's impossible. Extensions work by using the APIs provided by the browsers. If there are no supported APIs, we can't "pursue" any changes.

[ElhemEnohpi]

I understand that. I meant to pursue changes in the browser and APIs, if uBO can't block these. I'm not certain whether it can or not. If not, I could file a bug with Mozilla, if people think it's worth the effort. Or I could just forget about it. The only difference for me is that Early Hints does seem to give quite a performance boost, so I'd rather not turn it off altogether, but I'd also rather not be sending pings to Google if I can avoid it.

[gorhill]

These requests are not going through the webRequest API, there is nothing which can be done in uBO.

You can add comment regarding this at existing related bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1861889