Constant leakeages, dns requests still reach domains that suposedly are blocked.

[B1u3l1ght]

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 an issue with YouTube, Facebook or Twitch.
• 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

Hello, there are requests that reach dns even if those are specifically blocked so an eventual exception should not pass thru.

A specific URL where the issue occurs.

https://twsaver.com/

Steps to Reproduce

Check next dns log. (there's no need to create an account, just use nextdns as resolver)
Visit the mentioned link above.
After website loads there are requests toward dns from google analytics and other google ads related domains that breach thru uBO 'shields'.

There are many other ads that sneak under uBO from many other domains it's a general issue. uBO shows red marks as if those requests were blocked but dns has other results suggesting there is a uBO leakage.

Expected behavior

Ad related domains should be blocked and not reach dns at all.

Actual behavior

Some or many if not all requests bypass uBO.

uBO version

1.52.2

Browser name and version

Firefox 119.0

Operating System and version

Arch Linux

Something is wrong.

• I see redirection for pagead2.googlesyndication.com but nothing for (ssl./www.)google-analytics.com in uBO logger.
• nothing in browser console for both
• nothing in about:networking#dns

Yet I see these both (and (ssl./www.)google-analytics.com) logged from about:logging by nsHostResolver:5 setting.

Internal: https://github.com/uBlockOrigin/uBlock-discussions/discussions/828

[gorhill]

Probably duplicate of #1710.

So maybe a regression in Firefox?

https://bugzilla.mozilla.org/show_bug.cgi?id=1730418

[gorhill]

First, the issue goes away when using that filter:

twitterdownloader.co##^link[rel="preconnect"]

This rules out that NextDNS is simulating blocking the requests.

I investigated about:config, and it appears that setting is the culprit:

network.preconnect

It was true on my side (default), and toggling it to false made the issue go away.

So it appears Firefox is now in line with Chromium regarding <link rel="preconnect" ...>, I would have expected that toggling browser.privacy.networkPredictionEnabled to false would have taken care of this, and I am pretty sure it used to.

Source code of offending page contains:

<link rel="preconnect" href="//www.google-analytics.com">
<link rel="preconnect" href="//ssl.google-analytics.com">
<link rel="preconnect" href="//pagead2.googlesyndication.com">

---

Easy steps to reproduce by the way:

• Open a tab to about:networking#dns
• Click "Clear DNS Cache"
• Click "Refresh" to be sure
• Shift-click reload button for the https://twitterdownloader.co/ tab
• https://my.nextdns.io/.../logs shows DNS requests to google-analytics.com and googlesyndication.com
• Go to about:config, filter using preconnect
• Toggle network.preconnect to false
• Repeat above steps
• No DNS requests to google-analytics.com and googlesyndication.com

app_name: firefox
build_date: 2023-04-18 18:09:57.629000
build_file: /home/rdk/.mozilla/mozregression/persist/0cae6ecbc398-pgo--autoland--target.tar.bz2
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/L6z0NMXPRWiJ0H_bHyJZjw/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.bz2
changeset: 0cae6ecbc3984ca8f45c8ae5a0bec250392a22c1
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0cae6ecbc3984ca8f45c8ae5a0bec250392a22c1&tochange=3155d983a779ff98645129c066353f3204786f4c
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: L6z0NMXPRWiJ0H_bHyJZjw

[gothic-bum]

I'm not sure if it is directly related to this particular issue, but Early Hints Preconnect is scheduled to be enabled with Firefox 120:

https://www.mozilla.org/en-US/firefox/120.0a1/releasenotes/#note-789822

https://bugzilla.mozilla.org/show_bug.cgi?id=1858712

Hmmm https://bugzilla.mozilla.org/show_bug.cgi?id=1854782#c7 and following comments.

network.preconnect was not touched by privacy api https://hg.mozilla.org/mozilla-central/rev/5627b59436db

[gorhill]

requests toward dns from google analytics and other google ads related domains

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1861889

[B1u3l1ght]

Just to be clear, those DNS requests are not "from google analytics and other google ads related domains", they are from your browser

'From' in the sense they belong to google analytics and other, not that they originate from there. Requests are made by the user of course and if some browser or extension feature doesn't work as expected those will eventually reach dns and from there the handshake or whatever comes next. Think client hello is first though before handshake.

Leakage seems to only occur with FF DoH, can somebody confirm?

Use STR from above but leave FF DoH off and use OS DoH instead.