Closed Bug 1748503 Opened 11 months ago Closed 10 months ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
98 Branch
Tracking Status
firefox-esr91 97+ verified
firefox96 --- wontfix
firefox97 + verified
firefox98 + verified

People

(Reporter: dveditz, Assigned: jkrause)

References

Details

(Keywords: csectype-disclosure, privacy, sec-other, Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97-][adv-esr91.6-])

Attachments

(1 file)

+++ 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.

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

Summary: Detecting whether the content-type of a cross-origin resource is application/javascript through importScripts → Detecting whether a URL is blocked (by Tracking Protection or an extension) or not through importScripts

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.

Assignee: nobody → jkrause

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

Keywords: privacy, sec-other
Whiteboard: [fingerprinting] → [keep hidden until bug 1740985 is public][fingerprinting]

(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)

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

Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch

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
Attachment #9260014 - Flags: approval-mozilla-esr91?
Attachment #9260014 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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

Approved for 97.0b9.

Attachment #9260014 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting] → [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage]
QA Whiteboard: [qa-triaged]

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

Approved for 91.6esr.

Attachment #9260014 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
No longer depends on: CVE-2022-22760

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage] → [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+]
Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+] → [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+r]
Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+r] → [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+r][adv-esr91.6+r]
Whiteboard: [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97+r][adv-esr91.6+r] → [keep hidden until bug 1740985 is public][fingerprinting][post-critsmash-triage][adv-main97-][adv-esr91.6-]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.