Ricky Mondello

“This is not the computer for you”, I say, as someone attempts to steal my laptop from the coffee shop.

I got an iMessage from somebody for the first time in roughly ten years today.

It looks to be an OpenClaw-generated and sent “pairing code”.

iff looks could kill

This is a beautiful post that I recommend reading. https://samhenri.gold/blog/20260312-this-is-not-the-computer-for-you/

RE: @timonus@mastodon.social

I’ve noticed a good number of people saying the second bit here, that passkeys work much better in Apple Passwords. And that’s not due to any special sauce; the OS integrations are open to all Mac apps, same as iOS.

to sleep(), perchance to dream()

@mitchellh@hachyderm.io Hello! I got a report that Ghostty is erroneously offering one-time codes that users receive on their Mac while they're using Ghostty. AutoFill only offers these codes in contexts where it believes that the text input context's content is empty, which leads me to believe that Ghostty text editing system is not conforming to the NSTextInputClient properly, probably for good reason!

Anyway, I'm writing to tell you that if you get any complaints about OTCs being offered in Ghostty, this page tells you how to deal with it (you can turn AutoFill of delivered one-time codes off for the app): https://developer.apple.com/documentation/bundleresources/information-property-list/nsautofillrequirestextcontenttypeforonetimecodeonmac

My new favorite Wikipedia page. https://en.wikipedia.org/wiki/List_of_individual_trees

There are two changes in the macOS 26.4 beta that may interest makers of macOS password management apps and the users of those apps.

(1) The Safari Settings > AutoFill > “User names and passwords” switch will now only control Safari’s built-in AutoFill. It’s no longer another way to turn AutoFill off or on globally for the entire OS (which still lives in System Settings > General > AutoFill & Passwords). This change might help someone who wants native AutoFill in non-Safari apps, but wants to purely use a web extension in Safari.

(2) Bug Fixed: In some cases, even when Apple Passwords was not enabled for AutoFill, Safari’s AutoFill would offer generating a strong password that would save to Apple Passwords.

Does anyone's Flighty app resurrect friends’ flights and start live activities for them? I got “Gate Departure 80h 7m overdue” today.

An incredibly American experience: handing my drivers license over to rent a car in New Zealand and having the employee confirm which digits of my birthday are my birth month and which are my birth day.

Just this week I’ve heard people on two different podcasts talking about how in macOS Tahoe, AutoFill of verification codes received in Messages or Mail work in more Mac apps than before, including popular web browsers. The people seemed very happy about it. I just wanna say that people talking about this brings me joy, because I worked hard and did unspeakable things to get that to work.

iOS 26 (and OSes 26 in general) add an OS-facilitated way to securely migrate your passkeys, passwords, and other data saved in one password manager app to another. The details here are super interesting and are covered in the WWDC25 video “What's new in passkeys” (https://developer.apple.com/videos/play/wwdc2025/279). The rest of this post includes a summary of part of that video and other publicly-available information. (I am not breaking any kind of news here.)

- Data is sent from one app to the other without exporting any kind of file to a filesystem. This means it can’t accidentally be accidentally uploaded to an attacker attempting to compromise one or all of your accounts.
- There’s an OS API that password manager apps call to export their data. Then, securely and out-of-process, users select which app to send the data to. They are reminded of the scope of the data, and authentication with local biometrics or their passcode to confirm sending the data.
- The destination app is not revealed to the source app.
- Remember that crappy unstandardized CSV format for migrating passwords between password managers? It’s going to be a thing of the past, because…
- The data sendable via the API is explicitly based on the “Credential Exchange Format” (https://fidoalliance.org/specifications-credential-exchange-specifications/) standard. This standard is being developed in the FIDO Alliance, the standards body working on passkeys, but the spec covers far more than passwords and passkeys. In fact, it was co-developed by 1Password, Dashlane, and others. There’s a collection of Swift structs in the SDK implementing the standard, with as few modifications as possible.
- The data format part of the API is versioned so it can evolve as the Credential Exchange Format does.

I know it’s taken some time for this to come to fruition, but I hope that delivering a phishing-resistant credential migration process based on open standards (with a credential format standardized for the first time!) makes up for the delay. As I have said since day 1, your passkey data is yours. Passkeys are not a form of “vendor lock-in”.