1861889 - chrome.privacy.network.networkPredictionEnabled API no longer prevents preconnecting

Status: NEW

(WebExtensions :: Compatibility, defect, P2)

Description

[gwarser]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

User noticed that despite using uBlock Origin, DNS requests are made, visible in NextDNS logs: https://github.com/uBlockOrigin/uBlock-issues/issues/2913

STR:

• with uBlock Origin installed which should block Google tracking connections and disable prefetching/preconnection by default
• go to https://my.nextdns.io/
• copy the DOH server addres and add it in about:preferences secure DNS max protection setting
• Open a tab to about:networking#dns
• Click "Clear DNS Cache"
• Click "Refresh" to be sure
• open https://twitterdownloader.co/ tab
• https://my.nextdns.io/.../logs shows DNS requests for google-analytics.com and googlesyndication.com

This is regression:

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

https://bugzilla.mozilla.org/show_bug.cgi?id=1813618
Notable discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1854782

Also, if you follow these steps:

• Go to about:config, filter using preconnect
• Toggle network.preconnect to false
• Repeat above STR

No DNS requests to google-analytics.com and googlesyndication.com will be logged in NextDNS.

Actual results:

https://my.nextdns.io/.../logs shows DNS requests for google-analytics.com and googlesyndication.com.

Expected results:

Requests to resolve these domains should not happen.

Comment 1

[gwarser]

I believe, the API was initially implemented here https://bugzilla.mozilla.org/show_bug.cgi?id=1312802

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:keeler, since you are the author of the regressor, bug 1813618, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Rob Wu [:robwu]]

Relevant API calls from uBlock Origin seems to be at https://github.com/gorhill/uBlock/blob/bc632b546464b6fdfbb25d34097b4fe8ae7da8fc/platform/common/vapi-background.js#L136-L217

• network.networkPredictionEnabled in the privacy namespace maps to network.networkPredictionEnabled pref.

Comment 4

[Dana Keeler (she/her) [:keeler]]

If fixing bug 1813618 caused this behavior, it probably means there was an issue with the original implementation of chrome.privacy (before fixing bug 1813618, preconnect was always disabled).

Comment 5

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (121.0a1/20231030164930), Beta (120.0b4/20231030091620) and Release (119.0/20231019122658) under Windows 10 x64 and Ubuntu 22.04 LTS.

Performing the STR will show DNS requests for google-analytics.com and googlesyndication.com in https://my.nextdns.io/.../logs as per Comment 0.
Performing the alternate STR (where network.preconnect is false) will not show DNS requests to google-analytics.com and googlesyndication.com in NextDNS.

Comment 6

[gwarser]

Based on the regressor tracking data, 115 (ESR) is also affected.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1813618

Comment 8

[Rob Wu [:robwu]]

I think that it would make sense to disable all preconnect-like functionality whenever the browser.privacy.network.networkPredictionEnabled extension API is set to false.

Comment 9

[Rob Wu [:robwu]]

Why did you remove the regression tag? Bug 1813618 was identified as the regressor through mozregression.

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #4)

If fixing bug 1813618 caused this behavior, it probably means there was an issue with the original implementation of chrome.privacy (before fixing bug 1813618, preconnect was always disabled).

The extension API is used to force-disable preconnect. If the feature was always disabled, then that implies that the extension API works as desired, trivially. Preconnect is an optional feature, so it not working would not be a bug.

However, preconnecting despite having set the setting to false would be a bug, at least from the perspective of a privacy-conscious extension user.

Comment 10

[mikhail]

This error does not only apply to ublock/preconnect.

For example, on rt.pornhub.com firefox in the tracking protection status panel reports that static.trafficjunky.com is blocked, but it is not.

Comment 11

[mikhail]

On www.pvsm.ru also www.acint.net is not blocked.

Comment 12

[mikhail]

The solution to the problem is to disable the DoH.

Comment 13

[mikhail]

Strange, disabling DoH only solves the problem on www.pvsm.ru

Comment 14

[mikhail]

I'm sorry, it looks like DoH had nothing to do with it.
The problem should be solved in the built-in Tracking Protection, and then deal with uBlock Origin.

Comment 15

[mikhail]

I think I got it:

network.predictor.enabled = false
OS Resolver - www.acint.net blocked
DoH - www.acint.net does not blocked

network.predictor.enabled = true
OS Resolver and DoH - built-in Tracking Protection doesn't block a trackers, simply put it doesn't work.

Comment 16

[mikhail]

DoH - www.acint.net does not blocked

DoH has no effect on this, it's just that for some reason the domain is not blocked in standard ETP mode.

Comment 17

[mikhail]

network.predictor.enabled = true
on www.pvsm.ru - mc.yandex.ru is not blocked in strict mode.

Comment 18

[mikhail]

network.predictor.enabled = true
on www.pvsm.ru - mc.yandex.ru is not blocked in strict mode.

I don't know if it has anything to do with this bug.
To block it, have to:
network.predictor.enabled = false
urlclassifier.trackingTable.testEntries = yandex.ru

Comment 19

[Rob Wu [:robwu]]

I needinfo'd myself with the intent to get to a resolution quicker. I did however not get to this because of the sheer amount of work I have, so I will instead mark this bug with P2 so it can be triaged and scheduled as part of the regular planning in the team.

(In reply to Rob Wu [:robwu] from comment #8)

I think that it would make sense to disable all preconnect-like functionality whenever the browser.privacy.network.networkPredictionEnabled extension API is set to false.

If there are preferences connected to the feature here, we should also set them when an extension sets networkPredictionEnabled to false.

Comment 20

[mikhail]

(In reply to Rob Wu [:robwu] from comment #19)

I needinfo'd myself with the intent to get to a resolution quicker.

I tested v113, it doesn't have the predictor/preconnect issues described above.

Comment 22

[Rob Wu [:robwu]]

Copying needinfo from https://bugzilla.mozilla.org/show_bug.cgi?id=1900730#c12

"ni? me to look into the difference between the prefs and whether webext should flip both"

Comment 23

[Valentin Gosu [:valentin]]

network.networkPredictionEnabled controls predictor (or more generally browser) initiated preconnects and DNS prefetches
"network.predictor.enabled",
"network.prefetch-next",
"network.http.speculative-parallel-limit",
"network.dns.disablePrefetch",
This matches the description of Chrome's API

The network.dns.disablePrefetchFromHTTPS pref controls whether we are doing DNS prefetches in response to a rel="dns-prefetch" on a HTTPS page.
While the dns prefetch can be considered initiated by the page, I see that enterprise policies does merge the two of them together.

I haven't checked what Chrome actually does here, but I expect it's up to us on whether we want to either:

• match Chrome's behaviour and/or documentation
• align with enterprise policy
• introduce a new webextension setting

Comment 24

[mikhail]

Tracking Protection test result without uBlock Origin:

1. Visit the test page https://jsbin.com/vawosokapa/edit?html,output
2. Make sure that domains analytics.google.com, pixel.facebook.com, identify.hotjar.com are blocked.
3. Refresh the page using the F5 key and check about:networking to make sure that connections to blocked domains are established.

Disabling network.predictor.enabled=false solves this issue.
Should I create a new bug?

Comment 25

[sasc]

This is still an issue in Firefox 140.0.4 (with uBlock 1.65).

Toggle network.preconnect to false is the only way I found so far to reliably prevent unexpected DNS requests. Since this probaly affects many people, is not so easy to spot unless you actively watch DNS queries and the issue is somewhat privacy related, I feel it deserves a little more visibility.

Comment 26

[mikhail]

Test case for preconnect:
https://jsbin.com/nelunezode/1/edit?html,output

Despite the domains being present in the classifier tables, the browser fails to recognize them as trackers.
Checking these domains in about:url-classifier yields the following:

tracking-protection	
URI: https://analytics.google.com/
List of tables: analytics-track-digest256

tracking-protection	
URI: https://pixel.facebook.com/
List of tables: social-track-digest256

tracking-protection	
URI: https://identify.hotjar.com/
List of tables: analytics-track-digest256

Comment 27

[Valentin Gosu [:valentin]]

(In reply to mikhail from comment #24)

Disabling network.predictor.enabled=false solves this issue.

The predictor was removed, so this is no longer an issue.

(In reply to sasc from comment #25)

Toggle network.preconnect to false is the only way I found so far to reliably prevent unexpected DNS requests. Since this probaly affects many people, is not so easy to spot unless you actively watch DNS queries and the issue is somewhat privacy related, I feel it deserves a little more visibility.

An option would be to do classification for rel=preconnect (we already do that in the channel), but that would waste even more resources when the preconnected connection doesn't end up being used.
So instead it's probably better if network.networkPredictionEnabled also includes network.preconnect

Comment 28

[shaft-very-ducky]

This issue still exists in Firefox 150 on Linux.

1. Disable custom DNS in Firefox
2. (Disable any prefetching in Firefox)
3. Set NextDNS (or any provider) as your DNS in the System Settings
4. Block any website of your choice on ublock origin and visit it (e.g example.com)
5. Ublock origin is showing the blocked screen
6. URL still appears in the NextDNS logs