[lolinder]

This title is highly editorialized so as to be very misleading. The video doesn't mention Safari at all, it describes new APIs in iOS and in the web standards that allow developers to transition users to passkeys. Notably, these APIs work on iOS for whichever password manager the user has configured, not just the built in one. To the extent Safari is implicated in this at all it's that Safari implements CredentialsContainer.create [0], but that's a web standard that every major browser is implementing.

I'm all for scrutinizing the rollout of passkeys to make sure it doesn't turn into a lock in situation, but editorializing a video title is particularly egregious because, as we see in this comment thread, people are even more likely than usual to read only the title.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Credentials...

[sakjur]

Yeah, it seems bad enough that Apple are seemingly encouraging developers to push their users into using passkeys without asking the user. It’ll still be the website or app that instructs the browser to create a passkey if possible, and Safari will oblige (other browsers might have the courtesy of asking which the demo didn’t seem to do for Safari on iPhone).

I really hope that developers ask their users before installing a passkey on their behalf. The assumption that whatever happens to log in now should be trusted for future logins seems dangerous, and I’d hate for passkeys to get a reputation for something people use to hijack their exes accounts or whatnot.

[hedora]

Assuming the Apple side of the API doesn't prompt the user before setting a passkey, sites will inevitably start using passkeys as tracking cookie replacements.

I can't believe they'd be that shortsighted when designing up the APIs for this.

[sakjur]

That’s an interesting aspect. I’m not sure that’d be practical, but I’m not sufficiently read up on passkeys to say for sure. I don’t think passkeys are passed automatically and I really hope they’re not available via CORS? That should limit the utility of passkeys as tracking cookies. I also believe it informs the user when it’s used, based on the demo.

And if that’s an attempt at circumventing the EU ePrivacy directive (“the cookie law”) it’s unlikely to work based on my reading (IANAL) of the paragraph in question:

> Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

from https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...

[TheNewsIsHere]

The idea of using passkeys as a tracking mechanism is intellectually interesting but I am dubious that it's technically feasible with the current design.

Passkeys, be they platform or roaming authenticators, are generally bound to a public key and/or a public key + domain name. My understanding of the design is that the specification doesn't contemplate the idea of passing around passkeys via CORS or similar mechanisms. Part of the security design rests on mutual authentication by means of asymmetric cryptography.

As long as passkeys require user interaction there is a lot of friction to attempting that. And even if you could get over that hurdle, you still have all manner of other browser based hurdles.

What you could do is bind a passkey authenticated user to some kind of session/cookie tracking, but ITP/per-domain cookie restrictions would still block that.