Export thread

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

Beware! Critical Apple bug wipes out passkeys




I'm mad at Apple. They've botched up their passkey implementation that will result in disappearing passkeys! You can imagine, if your passkeys disappear unexpectedly, you will be locked out of your account.

I was almost locked out of my Google account yesterday. It was a close call. For the less tech-savvy people, they can easily lose access to their important accounts due to Apple's screw ups.

More details of the bug is explained here: https://terencekam.substack.com/p/beware-critical-apple-bug-wipes-out I'll be interested if anyone here can reproduce this bug. I could reproduce this bug myself a few times.

How did Apple's QA process let this show-stopping bug through? 🙄




Quality Assurance is hard. Anticipating every scenario is difficult.

In this case, it could be due to how Apple operates. They expect each user to have their own Apple ID and that Apple ID is used at only a site or two. So thinking about managing multiple Apple IDs in the Passkey keychain for the same site did not cross their mind.

I can see several issues with this implementation.
When you go to a site, is it expected that Passkeys would prompt you to choose the login to use? This would break the seamless login experience, but would provide the functionality of multiple logins at one site. If you have multiple email accounts at Google and use the browser to access them, what is there in the Passkey protocol that can identify which account to use? A browser based access differentiates between the accounts with the order they were logged in. First account will have a "/1" in the URL, the second will have a "/2" and so on. The path changes based on the order logged in, so unless the Passkey protocol has a method to select which account to use.​
If you have 2 different iPhones on the same Apple ID (a scenario they don't expect) and each user has a different login to the same website, should it prompt for which ID to use or associate a particular ID with a particular device? If it does device, this breaks the seamless log in on any device scenario. If face recognition could go across devices, perhaps this could be resolved assuming you can link the face to the account.​
Storage of credentials seems to be a problem. It appears they are storing them by URL which causes the first login to be wiped out and replaced with the second.​
This is the early days of passkeys. There will be hiccups like this and more. There is a need for interoperability between Passkey implementations so the user is not locked into a particular solution. Passkeys need to be tested by more people like Terence Kam to verify it is usable by the masses before we adopt it as a primary solution to passwords. Though I would prefer SQRL.




In iCloud Keychain, each passkey entry has a user name associated with a website. Optionally, you can also include a password, notes and OAUTH verification code in that entry.

For example, when I create the passkeys at Google‘s website by scanning the QR code, I saw a prompt to create a passkey for that user name. What happened was that in my iCloud Keychain, that passkey was added to the existing password entry in the iCloud Keychain. So, in that entry, it has:
  • User name (Google email address)
  • Password
  • OAUTH verification code
  • Passkey
When I created the passkey for my second Google account, I noticed these unexpected things in the iCloud Keychain:
  • The passkey in the entry for my first Google account disappeared!
  • A new entry appeared: It only contain the passkey with the user name of my second Google account.
  • The entry (user name, password, OAUTH) for my second Google account was intact.
What I expect:
  • A new passkey to be added to the entry for my second Google account.
  • The existing passkey in my first Google account to be untouched.
That would imply that in the UI, you can choose which passkey to use for any given website. This is very similar to how passwords works.

Testing on webAuthn.io​

I went to https://WebAuthn.io, which is a test implementation of passkeys. This time, I was able to create multiple passkeys for that website.

The difference?

  • In Google‘s website, the passkey was created on the iDevice by scanning the QR code on the desktop computer. In WebAuthn.io, the passkey was created natively through the iDevice’s web-browser.
  • In WebAuthn.io, there was no existing entries in iCloud Keychain for that website.