1617784 - ContentBlockingAllowListPrincipal lookup doesn't handle ancestors in a different process

Status: RESOLVED DUPLICATE of bug 1612378

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

Description

[Matt Woodrow (:mattwoodrow)]

ContentBlockingAllowListPrincipal lookup for document loading uses ThirdPartyUtil::GetTopWindowForChannel, which walks up the nsGlobalWindowOuter chain, and can only see Windows that in the current process. With fission, this will frequently not be the full ancestor chain.

As part of bug 1615966, I'm moving the computation of topWindowURI/contentBlockingAllowListPrincipal to the parent-process, when using DocumentChannel for a document load.

This means we should have access to all ancestor WindowGlobalParent's, not just Windows that exist in the current process.

I've had to manually add back support for restricting the lookup to within the current process, because we fail a bunch of tests otherwise: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=290284305&revision=16cf0f7019aa7c7e381e29c13a147140461ca414

It would be good to figure out why this, because I suspect we need it in the long term.

Comment 1

[Chris Peterson [:cpeterson]]

It would be good to figure out why this, because I suspect we need it in the long term.

Is this bug a Fission blocker? It blocks the etp-fission meta bug 1576291.

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #0)

I've had to manually add back support for restricting the lookup to within the current process, because we fail a bunch of tests otherwise: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=290284305&revision=16cf0f7019aa7c7e381e29c13a147140461ca414

It would be good to figure out why this, because I suspect we need it in the long term.

Matt, is this bug only about investigating why those tests fail when the ContentBlockingAllowListPrincipal lookup is not restricted to the current process? Can this bug affect users?

Does this bug need to block Fission Nightly?

Comment 3

[Matt Woodrow (:mattwoodrow)]

(In reply to Chris Peterson [:cpeterson] from comment #2)

Matt, is this bug only about investigating why those tests fail when the ContentBlockingAllowListPrincipal lookup is not restricted to the current process?

Yes!

Can this bug affect users?

Does this bug need to block Fission Nightly?

I don't know the answer to either of these sorry, and I think we need someone from the privacy team to look at this.

It's clearly a behaviour change between fission/non-fission (since the tree walk doesn't cross process boundaries), but I don't know what the actual user-facing outcome of that change is.

Comment 4

[Chris Peterson [:cpeterson]]

Steven, can someone on the Anti-Tracking team please determine the side effects of this bug and whether it should block shipping Fission?

Tentatively tracking as a blocker for enabling Fission in Nightly.

Anny says IsThirdPartyWindow bug 1641905 is related.

Comment 5

[Dimi Lee [:dimi]]

Sorry I didn't notice there was conversation onging in this bug.

We have changed how we did that in the recent architecture changes. Right now, top window lookup is no longer used because we only calculate IsInContentBlockingAllowList in top-level loads, and then we propagate the permission via CookieJarSetting.
So I think we can close this bug now.

Comment 6

[Chris Peterson [:cpeterson]]

Clearing Fission Milestone for bugs resolved as duplicates. We don't need to track duplicates.