It says “identity”, not cookies. Maybe it means cookies are partitioned. Maybe it means some new form of identity token is created (Googles have proposed them at various times) and is partitioned, but cookies are blocked. Maybe it means new token plus cookies remain as they are based on the “fingerprinting is even worse” argument. Maybe there are different settings. Who knows?

Anyway, the reason we moved away from cookie partitioning is that many third party embeds got confused when presented with non-empty cookies, but ones that weren’t the user’s canonical cookie for that site. Bugs were reported to us by embed providers, including Google web properties. This is a bummer because partitioning is elegant and has been WebKit’s go to approach since 2013, when we partitioned all storage besides cookies (LocalStorage, the HTTP cache, etc). A move that, incidentally was opposed by Chrime Engineers back when we shared an engine code base, though they are coming around now.

(I should mention also that partitioning cookies made many social embeds stop working at all until we provided Storage Access API and got embed providers to adopt them, which is why ITP originally had a 24 hour user interaction exception. Fortunately the web has adapted now.)

I should also mention, WebKit ML solution is deterministic. It’s trained offline. And it doesn’t substitute for enforcement actions, it substitutes for a block list of known trackers, which other tracking prevention systems use. One downside of strict rule based systems is that it may allow malicious players to game the system. So there has to be an out for changing the rules or ratcheting up enforcement.