Identifier use in Browsers

Full Title or Meme

The ways that browsers interact with the user's Identifiers is tracked here.

Generally these are blink-dev issues either proposed or in development.

Same-site policy has been added and slowly enhanced to block cross-site scripting attacks (CSRF or XSRF) by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain. This site describes the varying impact that this policy has on users on the various browsers. The challenge for [Single Sign On]] efforts with a Identifier or Attribute Provider at a different site than the Relying Party is that they rely on cross-site cookies to pass user credentials from one site to another. The problem introduced with iOS 12 from Apple is described on this site.
First-Party Sets and 'SameParty' cookie attribute has two "explainers" as GitHub pages First Party sets and same party. Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. (A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set.) Allow sites to indicate which cookies are intended to be set or sent in contexts where all ancestor frames belong to the same First-Party Set.

See the wiki on Trusted Browser for ideas on creating a User Agent that is responsive user security concerns.