Closed Bug 2088634 Opened 11 days ago Closed 9 days ago

Small FPP Bugs

Categories

(Core :: Privacy: Anti-Tracking, defect)

defect

Tracking

()

RESOLVED FIXED
162 Branch
Tracking Status
firefox162 --- fixed

People

(Reporter: tjr, Assigned: tjr)

References

(Blocks 1 open bug)

Details

Attachments

(4 external files)

While doing an audit over FPP's code, claude identified several small bugs/inconsistencies.

FingerprintingWebCompatService imports the baseline and the FPP granular
override prefs in one loop. If the first of them failed to parse, or was not
an array, the loop returned early and the second pref was silently ignored.
Skip only the malformed pref instead.

Assignee: nobody → tom
Status: NEW → ASSIGNED

CreateOverridesFromText split the overrides on ',' and required each entry to
start with '+' or '-', so a hand-written value such as "+A, -B" silently
dropped every entry after the first. Trim whitespace around each entry and
skip empty entries. This applies to the global overrides prefs as well as to
granular overrides, which share the parser.

The schema was passed to JsonSchema.Validator as a JSON string rather than an
object. The validator then sees no constraints, so every entry in the
granular overrides prefs was accepted, including malformed ones.

Pass the schema as an object. Doing that alone would have rejected valid
entries, because the domain pattern did not accept the bare '*' wildcard,
TLDs longer than six characters, or IDN TLDs in punycode form, so fix the
pattern as well. An empty thirdPartyDomain is accepted, since it is treated
the same as an absent one.

Each granular override is applied on top of the global set of enabled targets
(FPP or baseline), which already includes the global overrides pref. That
result was computed once, when the granular overrides were imported, so a
later change to privacy.fingerprintingProtection.overrides or
privacy.baselineFingerprintingProtection.overrides (by the user, or by a Nimbus
enrollment mid-session) left the granular overrides based on the old global
set until the next Remote Settings sync or granular pref change.

FingerprintingWebCompatService already retains all the overrides it imported,
so when either global overrides pref changes, have nsRFPService ask it to send
them again after the global sets are updated. nsRFPService drives this, rather
than the service observing the prefs itself, so that the global sets are
guaranteed to be updated first. This adds no new state to nsRFPService.

While here, read the overrides out of the JS-implemented
nsIFingerprintingOverride objects before taking
sEnabledFingerprintingProtectionsMutex, so we no longer call into JS while
holding it.

Pushed by tritter@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/b2850a6df28f https://hg.mozilla.org/integration/autoland/rev/49e6e7a98c1d Don't let a malformed granular override pref prevent the other one from being imported. r=timhuang https://github.com/mozilla-firefox/firefox/commit/1920fd3badea https://hg.mozilla.org/integration/autoland/rev/7300500bc900 Ignore whitespace around entries in the fingerprinting protection overrides. r=timhuang https://github.com/mozilla-firefox/firefox/commit/9906cd6e2aaf https://hg.mozilla.org/integration/autoland/rev/fc2b20e1253e Actually validate granular fingerprinting overrides against their schema. r=timhuang https://github.com/mozilla-firefox/firefox/commit/0e7807a13aec https://hg.mozilla.org/integration/autoland/rev/8fe6d0eb02ba Recompute granular fingerprinting overrides when the global overrides change. r=timhuang
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: