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.
Apologies, you're farther along than I was giving credit for. Storage Access API looks very much like the last 10% I was envisioning.
I do still wish the ML stuff weren't there, though. As a developer for a small company that's trying to become a big company (and develops on these boundaries), I fear we'll build something that works one day, but the next will be classified and the rules will change.
I'd rather have a policy that forces big and small sites to follow the same rules. Between storage access and link decoration detection, WebKit seems quite close to being able to detect cross-site tracking as it happens rather than via classifier, and I'd hope that could one day replace the ML component.
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.