1576291 - (etp-fission) [meta] Make the Anti-Tracking backend Fission compatible

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, task, P3)

Description

[(no longer active)]

We need to be able to apply ETP to trackers no matter which process they're hiding in.

Comment 1

[(inactive) Nihanth Subramanya [:nhnt11]]

I was debugging some tests in browser/base/content/test/trackingUI, and I wanted to share a couple of findings. These are relevant to when we load a simple page that contains a third-party iframe [1], with privacy.trackingprotection.enabled=true.

1. We show the usual console message indicating that the tracker was indeed blocked, but getContentBlockingLog returns an empty object. Seems like it isn't fission compatible yet, but I need to look into that tomorrow.
2. The frontend doesn't seem to receive any content blocking events - our UI doesn't react at all, and we show "No Trackers Detected". We're hitting [2] only for a tracker page (not for a "benign page" [3]) but I didn't manage to successfully attach a debugger to the child without the parent crashing, so I need to dig into that further too.

Are these known issues? I'm going to be filing bugs tomorrow - just wanted to log my findings here before going to bed.

[1] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/browser/base/content/test/trackingUI/trackingPage.html
[2] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/netwerk/ipc/DocumentChannelChild.cpp#39
[3] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/browser/base/content/test/trackingUI/benignPage.html

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to Nihanth Subramanya [:nhnt11] from comment #1)

I was debugging some tests in browser/base/content/test/trackingUI, and I wanted to share a couple of findings. These are relevant to when we load a simple page that contains a third-party iframe [1], with privacy.trackingprotection.enabled=true.

1. We show the usual console message indicating that the tracker was indeed blocked, but getContentBlockingLog returns an empty object. Seems like it isn't fission compatible yet, but I need to look into that tomorrow.
2. The frontend doesn't seem to receive any content blocking events - our UI doesn't react at all, and we show "No Trackers Detected". We're hitting [2] only for a tracker page (not for a "benign page" [3]) but I didn't manage to successfully attach a debugger to the child without the parent crashing, so I need to dig into that further too.

Are these known issues? I'm going to be filing bugs tomorrow - just wanted to log my findings here before going to bed.

[1] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/browser/base/content/test/trackingUI/trackingPage.html
[2] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/netwerk/ipc/DocumentChannelChild.cpp#39
[3] https://searchfox.org/mozilla-central/rev/5e830ac8f56fe191cb58a264e01cdbf6b6e847bd/browser/base/content/test/trackingUI/benignPage.html

OK! I spent some more time on this and, I can only reproduce this in a mochitest. In a normal run with fission enabled, having a third party tracker in an iframe is blocked as expected, the content blocking log looks good, and the UI responds properly too. I'm not sure what to make of this, but basically the issues I mentioned in comment 1 are probably not really issues.

Comment 3

[(no longer active)]

You're right, the content blocking log doesn't work in Fission mode, and that is one of the problems we'd need to fix here...

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

FWIW, I'm seeing an empty content blocking log only when we're blocking loads, and not just cookies. So for blocked tracking content, fingerprinters, cryptominers.

Comment 5

[Chris Peterson [:cpeterson]]

Moving anti-tracking from milestone M5 (dogfooding) to M6 (enable in Nightly) because ETP does not block dogfooding.

Comment 6

[Steven Englehardt [:englehardt]]

Tim, Dimi: Can we close out this meta bug now that we've finished our work?

Comment 7

[Dimi Lee [:dimi]]

(In reply to Steven Englehardt [:englehardt] from comment #6)

Tim, Dimi: Can we close out this meta bug now that we've finished our work?

yes, i think we can close this one :)