The problem we have looking at the scope is that the strong reference is in scope until the end of the function, but we have our
repeatloop before the end of the function so we will never get to the end.[…]
You could write a unit to verify that the reference does not leak something like this.
Previously:
The import/export feature, which Apple demonstrated at this week’s Worldwide Developers Conference, will be available in the next major releases of iOS, macOS, iPadOS, and visionOS. It aims to solve one of the biggest shortcomings of passkeys as they have existed to date. Passkeys created on one operating system or credential manager are largely bound to those environments. A passkey created on a Mac, for instance, can sync easily enough with other Apple devices connected to the same iCloud account. Transferring them to a Windows device or even a dedicated credential manager installed on the same Apple device has been impossible.
[…]
The system provides a secure mechanism to move the data between apps. No insecure files are created on disk, eliminating the risk of credential leaks from exported files. It’s a modern, secure way to move credentials.
This is progress, but personally I still wish for a way to directly get at my data, so that I’m not at the mercy of the sending app being available and working properly, and the receiving app being approved, at some indeterminate time in the future.
And still I ultimately hope it fails and disappears.
The concept of so fully locking a user out of their login credential that they can never ever have any access to them. It is technologically impossible for them to login to any “unapproved” app, using any “unapproved” device. Is a goal I hope withers and dies bogged down in technical complexity.
The amount of lockdown involves is such that password managers suggesting they might give users the ability to freely import/export their credentials between password managers was met with threats of blacklisting those programs if they did so in a way that actually gave the end user their credentials.
Only “pre-approved” (by the platform vendor, not you) applications which could securely link to each other in a way to ensure you the user were never permitted access to your credentials in any way.
Previously:
The new setting is enabled by default; I’ve seen this on multiple computers.
Automatically create a passkey to sign in faster
Allow sites and apps to upgrade existing accounts to use passkeysThis new setting is not actually included on the What’s New in Chrome page (
chrome://whats-new/), which doesn’t even mention passkeys.It is mentioned by the New in Chrome 136 post on the Chrome for developers blog:
You can now upgrade existing password credentials to a passkey.“You” here apparently refers to web developers, not to users, who aren’t given a choice[…]
Microsoft has decided to push its consumer customers to dump passwords in favor of passkeys.
The software giant announced the move Thursday, May 1, traditionally known as “World Password Day,” with a declaration it had joined forces with the Fast Identity Online (FIDO) Alliance to re-name the pseudo-holiday “World Passkey Day.”
Redmond’s not just playing with words as the Windows giant has also decided that all new Microsoft accounts will use passkeys by default.
[…]
As we noted late last year, Microsoft isn’t giving its customers an option to continue using passwords, saying that opting out of passkey invitations wasn’t possible.
This is a good point to reflect on the paradox that securing your digital life presents: as we seek stronger forms of authentication, we create different risks. Losing all your forms of non-phishable 2FA, for example, creates the risk of losing access to your account. But we also have mitigating controls: your digital passkey is managed totally independently of your physical one so the chances of losing both are extremely low. Plus, best practice is usually to have two U2F keys and enrol them both (I always take one with me when I travel, and leave another one at home). New levels of security, new risks, new mitigations.
Most people are not going to do this, so it seems like the end game is that either users will lose control of their logins or that passkeys will become mainly a convenience for quickly logging in, with passwords, SMS, and e-mail as a less secure fallback.
Isaiah Inuwa (via Ricky Mondello):
With the announcements from big companies at World Password Day about passkeys, I thought I should share what I've been working on for passkey support on Linux.
Previously:
With iOS 26, Apple is adding a new AlarmKit framework for developers that offer apps with alarm clocks and timers. AlarmKit provides system-level access to alarm functionality, which was previously reserved only for Apple’s Clock app.
Developers will now be able to create apps that have the same feature set and permissions as Apple’s built-in alarm functionality, including alerts that always activate even if Silent mode or a Focus mode is enabled, full-screen snooze and stop display options, and access to the Lock Screen, Dynamic Island, and Apple Watch.
I thought AlarmKit would be more than it is, that maybe it would be something neat I could incorporate into Broadcasts (i.e. wake up to streaming radio), but the API is very barebones — it’s all handled at the system level, doesn’t wake up your app, and only local sounds can be played, I guess that one’s out for this year
Tried out AlarmKit and was really disappointed to find there’s no way to detect when a user swipes an alarm away. The stop intent doesn’t get called. Alarms are for important actions, so apps should be able to react in case of accidental dismissals.
It’s unclear whether the limitations are because this is just 1.0 or because the purpose of the new API is only to appease the EU regulators.
