E.g. BrowserChild::RecvLoadURL() sets the TriggeringPrincipal equal to the SystemPrincipal, which was fine initially, but now that code is also used for same origin frame navigations in fission (see Bug 1639195).

We should audit all usages of nsContentUtils::GetSystemPrincipal() to ensure that does not happen anywhere else where it's potentially more critical.

ckerschb says this bug doesn't necessarily need to block shipping Fission, but is a task critical to do. For now, let's track this bug for Fission riding the trains to Beta (M7).

Freddy, can you please re-prioritize this auditing so we know how much work there's left to do here?

Are we still going to need this with the principal vetting work in bug 1670242?

(In reply to Frederik Braun [:freddy] from comment #3)

Are we still going to need this with the principal vetting work in bug 1670242?

Yes, we still need to perform this audit in addition to the vetting we introduce in bug 1670242. Does it need to be a M7 Fission blocker? That I am not sure and we can talk about that.

I think this is largely hardening work and doesn't need to block M7.

Christoph, is Freddy still the correct assignee for this? We should audit and review all uses so we can flag and fix any issues as soon as possible. Fission is already in Beta experiments and we need to get it ready for Release experiments now.

Hey Neha, this audit bug was filed predating the hardening work we are performing within Bug 1670242 and hence used to block the general dom:security and fission compatibiliy bug to make sure it does not fall off our radar. However, the time has come to perform some bug hygiene and rather mark this bug blocking the IPC based principal vetting work within Bug 1670242.

FWIW, even Bug 1670242 is not a hard Fission blocker (that would need to block the M8 milestone), it's mostly to ensure our mental model matches our implementation and as such the hardening work can happen in parallel.