Open Bug 1788225 Opened 1 month ago Updated 16 days ago

Add a per-site preference for cookie banner handling


(Core :: Privacy: Anti-Tracking, enhancement, P2)






(Reporter: pbz, Assigned: timhuang)


(Blocks 1 open bug)



(4 files)

A per-site preference for cookie banner handling allows users to disable the mechanism for a specific site. We could also support changing the behavior (MODE_REJECT, MODE_REJECT_OR_ACCEPT).

We can use the content pref service to store a flag per domain:

The flag can be checked in the rule getters of nsICookieBannerService. Then consumers don't have to care about these preferences.

Some questions that came up in today's meeting:

Getter is async, that doesn’t work for the cookie injector
Can we warm up the cache beforehand?
Can we import all exceptions on cookie banner service init?
HashSet of origins? domains?
Cache reads in-memory in cookie banner service
Write changes directly to nsIContentPrefService
Use an observer / listener to subscribe to content pref type “cookiehandling” and keep in-memory cache up to date
Alternative? Key value storage
What should be the key for exceptions?
This should somehow match our rule keying.
Base domain matches the behavior of our existing toggles better

Assignee: nobody → tihuang
Priority: P3 → P2

This patch implements the CookieBannerDomainPrefService which manage
the per domain pref setting for cookie banner handling. The service uses
the nsIContentPrefService2 to store the per site pref value.

This patches adds functions to nsCookieBannerService that allow
get, set and remove cookie banner domain preference.

Depends on D157866

The site preference will take precedence over the pref setting when we
getting the cookie rule and the clicking rule. We will use the top-level
uri to check the site preference which aligns with the behavior of ETP

Depends on D157867

You need to log in before you can comment on or make changes to this bug.