1625585 - Sites added to ContentBlockingAllowList still appear to show blocked content in ContentBlockingLog

Status: REOPENED

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

Description

[Arturo Mejia [:amejia]]

If we add a session to the exception list, after reloading this session has the same tracking protection settings and it shouldn't.

For example if you apply the below settings, this is the equivalent to strict settings in Fenix, with them many ads doesn't show.

        fun setStrict() {
            geckoSession.settings.useTrackingProtection = true

            val etpLevel = ContentBlocking.EtpLevel.STRICT
            val getAntiTrackingPolicy =
                    AD + ANALYTIC + SOCIAL + TEST + CRYPTOMINING + FINGERPRINTING + STP

            runtime!!.settings.contentBlocking.setEnhancedTrackingProtectionLevel(etpLevel)
            runtime!!.settings.contentBlocking.setStrictSocialTrackingProtection(true)
            runtime!!.settings.contentBlocking.setAntiTracking(getAntiTrackingPolicy)
            runtime!!.settings.contentBlocking.setCookieBehavior(ACCEPT_NON_TRACKERS)
            geckoSession.reload()
        }

But if you apply this settings to a session that is already in the exception, after reloading ads should start showing, but they aren't. For testing you can use this website, it has an ad banner at the bottom of the page, when the strict setting is applied the banner is hidden, but when we add its session to the exception list the banner should show again.

Global settings shouldn't affect sessions on exception list.

Comment 1

[Randall Barker [:rbarker]]

We see something similar in FxR where any session created before an exception is added does not seem to be affected by the exception.

Comment 2

[Emily Kager [:ekager]]

We are experiencing this in Fenix and it's creating some user confusion, this is a top priority bug for us.
https://github.com/mozilla-mobile/fenix/issues/9980

Comment 3

[Randall Barker [:rbarker]]

A work around we are using in FxR is to recreate the session instead of reloading it. You do need to be careful with Private Browsing sessions if you only have one and re-create it, the Private Browsing exceptions get cleared.

Comment 4

[Arturo Mejia [:amejia]]

I noticed some strange behavior in the content blocking log on an isolated geckoView app that seems to reproduce on desktop as well; can you take a look at the logs.

Using gBrowser.selectedBrowser.getContentBlockingLog(); with this website
I can see in the log COOKIES_BLOCKED_TRACKER -> 536870912 even if the site is added as an exception

Domains that shouldn't be blocked

"{
 \"https://www.google.com\": [  [536870912, true, 1]],
 \"https://googleads.g.doubleclick.net\": [ [536870912, true, 9]],
 \"https://googleads4.g.doubleclick.net\": , [536870912, true, 4]],
}

The full log

"{
 \"https://remolacha.net\": [[32768, true, 1]],
 \"https://www.googletagservices.com\": [[8192, true, 1]],
 \"https://connect.facebook.net\": [[8192, true, 1], [131072, true, 2]],
 \"https://ssl.google-analytics.com\": [[8192, true, 1]],
 \"https://secure.gaug.es\": [[8192, true, 1]],
 \"https://certify.alexametrics.com\": [[8192, true, 1]],
 \"https://onesignal.com\": [[32768, true, 1]],
 \"https://adservice.google.ca\": [[8192, true, 1], [32768, true, 1]],
 \"https://adservice.google.com\": [[8192, true, 1], [32768, true, 1]],
 \"https://securepubads.g.doubleclick.net\": [[8192, true, 1], [32768, true, 1]],
 \"https://stats.g.doubleclick.net\": [[8192, true, 1], [32768, true, 1]],
 \"https://www.google.com\": [[1048576, true, 1], [32768, true, 1], [536870912, true, 1]],
 \"https://www.google.ca\": [[1048576, true, 1], [32768, true, 1]],
 \"https://www.facebook.com\": [[8192, true, 1], [32768, true, 1], [131072, true, 6]],
 \"https://static.xx.fbcdn.net\": [[1048576, true, 1], [131072, true, 23]],
 \"https://scontent.fyyz1-2.fna.fbcdn.net\": [[1048576, true, 1], [131072, true, 2]],
 \"https://2059f6022e93da4cfe3e48d19eeb185e.safeframe.googlesyndication.com\": [[8192, true, 1], [32768, true, 1]],
 \"https://pagead2.googlesyndication.com\": [[8192, true, 1]],
 \"https://tpc.googlesyndication.com\": [[8192, true, 1], [32768, true, 1]],
 \"https://googleads.g.doubleclick.net\": [[8192, true, 1], [32768, true, 1], [536870912, true, 9]],
 \"https://s0.2mdn.net\": [[8192, true, 1], [32768, true, 1]],
 \"https://googleads4.g.doubleclick.net\": [[8192, true, 1], [32768, true, 1], [536870912, true, 4]],
 \"https://choices.truste.com\": [[1048576, true, 1]],
 \"https://ad.doubleclick.net\": [[8192, true, 1], [32768, true, 1]],
 \"null\": [[32768, true, 1]],
 \"https://ade.googlesyndication.com\": [[8192, true, 1]]
}

Comment 5

[Dylan Roeh (:droeh) (he/him)]

De-prioritizing this and moving to anti-tracking, since it seems like GeckoView is getting/passing the ContentBlockingLog correctly -- Johann/Ehsan, is this a bug in ContentBlockingLog or are we misunderstanding what to expect?

Comment 6

[Chenxia Liu [:liuche]]

Turns out we were testing against an out-of-date testing site - closing this bug because this feature works when tested against the correct testing site.

Comment 7

[Arturo Mejia [:amejia]]

The issue mentioned above on comment 4 is still present.

Comment 8

[Dylan Roeh (:droeh) (he/him)]

(Re-adding NI. Johann, see comment 4 & comment 5.)

Comment 9

[Johann Hofmann [:johannh]]

I can't reproduce the issue in comment 4 and I don't really have the bandwidth to investigate further :)

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Arturo Mejia from comment #4)

I noticed some strange behavior in the content blocking log on an isolated geckoView app that seems to reproduce on desktop as well; can you take a look at the logs.

Using gBrowser.selectedBrowser.getContentBlockingLog(); with this website
I can see in the log COOKIES_BLOCKED_TRACKER -> 536870912 even if the site is added as an exception

Since Arturo said (in comment 4 two years ago) that this bug was reproducible on both Android and desktop, I'm removing the Android whiteboard tags. I don't know if this bug is still reproducible on Android or desktop.