Should OriginAttributes::EqualsIgnoringFPD look at mPartitionKey?
Categories
(Core :: Security: CAPS, task)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
It seems it's related to FPD somehow (bug 1640135), but I'd expect EqualsIgnoringFPD to only ignore the first party domain...
Comment 1•3 years ago
|
||
This bug is about the snippet at https://searchfox.org/mozilla-central/rev/a14ecd829fdb1e9780b7c100016c6a3d951cf7da/caps/OriginAttributes.h#66-69
bool operator==(const OriginAttributes& aOther) const {
return EqualsIgnoringFPD(aOther) &&
mFirstPartyDomain == aOther.mFirstPartyDomain &&
// FIXME(emilio, bug 1667440): Should this be part of
// EqualsIgnoringFPD instead?
mPartitionKey == aOther.mPartitionKey;
}
I believe that the logic is correct. The method was originally introduced in part 1 of bug 1492607, to allow for comparison of OriginAttributes between different windows (and treating them as equal despite the OA's firstPartyDomain
being different).
The partitionKey
attribute serves a similar purpose as firstPartyDomain
, i.e. allowing the creation of keys to distinguish between the same principal in different contexts. Callers who are interested in the originAttributes/principal regardless of the additional first-party key would want to exclude firstPartyDomain
and partitionKey
, hence these don't belong to OriginAttributes::EqualsIgnoringFPD
.
Tim, is my understanding correct? Can we remove the comment in OriginAttributes::operator==
and close this bug?
Comment 2•3 years ago
|
||
Yes, that's correct. The original intention of EqualsIgnoringFPD
was to allow postMessage to be able to send across windows that have different first-party domains. But, right now, it has been used for other purposes, like what you mentioned.
So, I think we can remove the comment. But we need a better name for OriginAttributes::EqualsIgnoringFPD
because it's a bit confusing right now.
Description
•