Closed Bug 1617784 Opened 3 years ago Closed 3 years ago

ContentBlockingAllowListPrincipal lookup doesn't handle ancestors in a different process

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1612378

People

(Reporter: mattwoodrow, Unassigned)

References

Details

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.

Priority: -- → P3

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.

Fission Milestone: --- → ?

(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?

Flags: needinfo?(matt.woodrow)

(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.

Flags: needinfo?(matt.woodrow)

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.

Fission Milestone: ? → M6c
Flags: needinfo?(senglehardt)
See Also: → 1641905

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(senglehardt)

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

Fission Milestone: M6c → ---
You need to log in before you can comment on or make changes to this bug.