(In reply to Tomislav Jovanovic :zombie from comment #11)
Does reusing the
firstPartyDomain key name for a (related but still) different purpose
partitionKey risk confusion? Would we benefit if we decided to deprecate it and introduce a more generic name?
Although the internals are different, they are conceptually similar, as in they are used for partitioning cookies. I aimed for re-using the two to allow extensions that were designed for FPI to still work with dFPI. After all, it doesn't matter how the internal representation is, as long as an extension reads the "firstPartyDomain" property and passed it back when creating/updating a cookie.
This change affects backwards-compatibility. Previously we used originAttributes.firstPartyDomain instead.
This would also potentially break backward compatibility again if we ever swtich to FPI (by default, or in some specific mode)?
FPI is the default of Tor, and since FPI is stricter than dFPI, it's probably not likely for it to switch to dFPI. FPI has been around for a while, so with the efforts spent on dFPI I don't expect the switch from dFPI to FPI. Even if that did happen, then cookies have to be migrated by the browser to avoid loss of sessions. And after that, to an extension it shouldn't matter whether dFPI or FPI is used.
The only situation where the difference is significant is when an extension wants to be aware of FPI and dFPI, for example when a user has used both in one profile. I am consciously in favor of supporting only FPI xor dFPI for API simplicity. After all, when (d)FPI is used, the cookies from the other setting are never used, and an extension doesn't really have to worry about it.
The latter is not that bad of an idea, and since firstPartyDomain has been supported for a long while in Firefox, extensions will still be backwards-compatible.
I don't understand what you're saying here.
Firefox recognizes the
firstPartyDomain property in the API already. In the default configuration, it's just an empty string. An extension that (unconditionally) passes the firstPartyDomain property to
cookies.remove is compatible with Firefox versions without a patch for this bug.
In any case, cross-browser compatibility and MV3 are also considerations for making the key required.
I'd aim for cross-browser compatibility where possible. If the key is not required when dFPI is enabled, then extensions without awareness of (d)FPI will inadvertently mix third-party cookies with first-party cookies. As either approach does not only have advantages, I'm not fully decided on whether this should be optional or required (slightly favoring required).
I don't see the relevance of MV3 here though.