1748503 - Detecting whether a URL is blocked (by Tracking Protection or an extension) or not through importScripts

Status: VERIFIED FIXED

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

Description

[Daniel Veditz [:dveditz]]

+++ This bug was initially created as a clone of Bug #1740985 +++

The original testcase of bug 1740985 (attachment 9250556 [details]) is fixed WRT the original XSLeak of determining the difference between script and non-script files. Now both return the same error, as well as non-existing files. But it still can be used to potentially fingerprint the user: if a file load is blocked entirely by tracking protection or an extention (e.g. uBlock Origin) then that case can be distinguished.

STR:

1. Enable "Strict" tracking protection in prefs, or install uBlock Origin
2. Open attachment 9250556 [details] and try to load the default google-analytics URL
3. compare to trying to load something that exists (https://www.mozilla.org/favicon.ico) or trying to load that same URL with tracking protection disabled.

This error loading difference is probably not restricted to just worker files. I'm not sure how important a fingerprinting vector this is -- there are probably more direct ways to check whether tracking protection is enabled, or which of several standard ad-blocker lists are enabled.

Comment 1

[Frederik Braun [:freddy]]

To clarify, this can be fixed relatively easily by aligning the error messages for the different kinds of NetworkErrors.

Comment 2

[Jan Rio Krause]

As Ryan commented in Bug 1740985 comment 9, we already shortly discussed about this. After some testing in Nightly, I can confirm that the cases can be distinguished when having an extension like uBlock Origin installed. I'm already on it. Thanks for reporting the bug, Daniel!

However, having the Enhanced Tracking Protection in about:preferences#privacy set to "Strict" without any extensions installed, the message always is NetworkError: WorkerGlobalScope.importScripts: Failed to load worker script at "<url>" no matter if the file is existing or non-existing. So at least I cannot confirm a possible distinction in this case.

Comment 3

[Daniel Veditz [:dveditz]]

Hm, that doesn't seem right... I was getting a different error for google-analytics as for the mozilla.org favicon. Will have to investigate more I guess.

Not really a "security" bug at this point, more of a privacy one that doesn't need to be hidden. But it talks about the other bu

Comment 4

[Frederik Braun [:freddy]]

(In reply to Daniel Veditz [:dveditz] from comment #3)

Hm, that doesn't seem right... I was getting a different error for google-analytics as for the mozilla.org favicon. Will have to investigate more I guess.

I think we had noticed a difference where a real network error (e.g., hostname does not exists) behaves differently than the cases of correct & incorrect mime-type (which are reporting the same network error)

Comment 5

[Jan Rio Krause]

Thanks for the hint, Daniel, I could confirm it now, too. And thanks for pointing out about the non-existent hostname, Frederik.

Comment 6

[Jan Rio Krause]

Attachment: Bug 1748503 - Consistent error messages for blocked scripts. r=#dom-storage-reviewers

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Consistent error messages for blocked scripts. r=dom-storage-reviewers,edenchuang
https://hg.mozilla.org/integration/autoland/rev/e123d784d09e5a42be93d4348c2fc9205ec9048f
https://hg.mozilla.org/mozilla-central/rev/e123d784d09e

Comment 8

[Jan Rio Krause]

Comment on attachment 9260014 [details]
Bug 1748503 - Consistent error messages for blocked scripts. r=#dom-storage-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Related and follow-up of Bug 1740985. It is possible to potentially fingerprint a user by distinguishing between a load blocked by Enhanced Tracking Protection or an extension (e.g. uBlock Origin).
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See Bug 1740985 Comment 10 and my following one.
• List of other uplifts needed: Bug 1740985
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just a few lines changing in a switch/case control structure. Thus, I consider the risk of uplifting as low.
• String changes made/needed: none

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: see Beta/Release Uplift Approval Request
• User impact if declined: see Beta/Release Uplift Approval Request
• Fix Landed on Version: 98
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): see Beta/Release Uplift Approval Request

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9260014 [details]
Bug 1748503 - Consistent error messages for blocked scripts. r=#dom-storage-reviewers

Approved for 97.0b9.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0fcf1e9fcde3

Comment 11

[Jan Rio Krause]

As said in Bug 1740985 Comment 6, I will also write a common test case for this bug and land it later.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9260014 [details]
Bug 1748503 - Consistent error messages for blocked scripts. r=#dom-storage-reviewers

Approved for 91.6esr.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/de8c6a1ba2c7

Comment 14

[Hani Yacoub, Desktop QA]

Verified as fixed on Windows 10 x64, Ubuntu 20.04 x64 and on macOS 11.6.