1873519 - ContentParent::RecvStoreUserInteractionAsPermission receives unexpected principals that don't match the process's stated principal

Status: NEW

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

Description

[Tom Ritter [:tjr]]

Background

In the meta Bug 1670242 (really its children) we landed code that ensures the principals we receive from a Fission content process match the expected principal for that process. example.com shouldn't be sending principals claiming to be google.com. To better understand ContentParent's principal for the process it was added in this commit.

This validation occurs in ValidatePrincipal and is called case-by-case in Recv messages. (I think this is because things like a triggeringPrincipal wouldn't be subjected to this check - I don't remember the explicit reason this isn't checked deeper in the IPC code during deserialization, but that's orthoganal to this bug and something we can dig back into later.)

If the pref is enabled (which it is on Release) and we fail validation, we will send telemetry and crash a debug build. We do not crash or otherwise return an error on Release - just telemetry. (So the 'enforce' pref name is not that accurate.)

This bug is about one specific method we are seeing in the telemetry.

Bug

RecvStoreUserInteractionAsPermission have reports in Telemetry for the received principal not matching the process's principal. There are 23 reports from 17 unique users with a https:// ContentPrincipal, 10 reports from 9 users with a moz-extension ContentPrincipal, and 44 reports from 32 users with a view-source ContentPrincipal.

We'd like to better understand why we're getting these reports in via telemetry, so we can improve the validation code and eventually move it to real enforcement on release. This bug is on file to try and investigate that.