Archive for April 20, 2023

Thursday, April 20, 2023

iPhone Thieves Locking Users Out of Their Apple Accounts

Nicole Nguyen and Joanna Stern (MacRumors, Hacker News):

Greg Frasca has been locked out of his Apple account since October, and he’ll do just about anything to get back in.

He has offered to fly from Florida to Apple’s California headquarters to prove his identity in person, or write a check for $10,000 to reclaim the account. It holds the only copies of eight years of photos of his young daughters.

This is all because the thieves who stole Mr. Frasca’s iPhone 14 Pro at a bar in Chicago wanted to drain cash from his bank account and prevent him from remotely tracking down the stolen phone. They used his passcode to change the 46-year-old’s Apple ID password. They also enabled a hard-to-find Apple security setting known as the “recovery key.” In doing so, they placed an impenetrable lock on his account.

But this is not because Apple can’t restore access. It’s just their policy not to support other forms of recovery identification: driver’s license, backup e-mail, postal mail, physically appearing at an Apple Store, etc. The article cites an example where Apple did restore an account after the customer answered some verification questions, but this option does not seem to be available to most.

The article recommends enabling Screen Time protections, which may help against an unsophisticated thief, but as discussed before this seems to not be a true solution.

It’s better to have a backup of your photos, though I’m not sure there’s an automated way to do that if you don’t have a Mac.

larsnystrom:

IMHO, the crazy part is that it is possible to create a new Recovery Key with just the iPhone passcode (and the iPhone). So basically, the iPhone passcode is mightier than the Recovery Key. The only purpose of the Recovery Key is to protect against SIM swapping attacks. I didn’t know this.
So an attacker with the iPhone passcode can lock you out of your Apple account on all devices, even if they don’t have your Apple ID password or your Recovery Key.

Previously:

Update (2023-04-21): Adam Engst:

Although I haven’t been able to find a detailed explanation of how the recovery key works in Apple’s Platform Security Guide, my understanding is that it essentially acts as a second copy of a user-managed encryption key that takes over from Apple’s usual account recovery option.
[…]
When the Wall Street Journal article talks about how victims attempt to prove ownership of their accounts with various forms of identification, it’s missing the point—identification is not in question; the data is simply inaccessible because it’s encrypted with a key that Apple doesn’t control.

I’m not sure that’s the case. If it were, then what was the point of Advanced Data Protection? Anyway, I think Apple needs to document this better.

The best protection right now is to use Screen Time, as I discussed in my previous article.

[…]

Unfortunately, it does that by preventing you from even entering Settings > Your Name without first going to Settings > Screen Time > Content & Privacy Restrictions > Account Changes > Screen Time Passcode > Allow, and then setting it back to Don’t Allow once you’re done. If Apple tweaked iOS 17 to prompt for the Screen Time passcode when accessing the blocked options, it would be much easier to recommend.

Doug Miller:

It used to be you could do a certain set of actions that would allow you to change the password even with the screen time passcode block (I won’t list them.) But with 16.4 Apple now requires you to confirm a trusted phone number, and then requires you to use another trusted device to actually change the password.

Lockdown Mode in iOS 16.4 Breaks Web Forms

Jeff Johnson:

HTML button elements don’t appear in Safari in Lockdown Mode.
Most input elements don’t appear either!

A reader writes:

Since iOS 16.4 was released, HTML input elements have vanished from all sites and web views in apps, and so have attachments in Mail.app, which no longer appear at all (not even as icons).

As you can imagine, this renders most websites, as well as the Mail app itself, pretty well unusable, especially when the last remaining text labels appear in black on black when in Dark Mode.

I realise that Lockdown Mode is one of these features that Apple supports only partially, but this has gone beyond the bounds of inconvenience and will probably lead many people who do need it to disable it just to use their devices.

Previously:

Bug iOS iOS 16 iPadOS iPadOS 16 Lockdown Mode MobileMail MobileSafari WebKit

Comments

CloudSyncSession

Ryan Ashcraft (tweet):

Last week, I published CloudSyncSession, a Swift library that builds on top of the CloudKit framework to make it easier to write sync-enabled, offline-capable apps.
I started CloudSyncSession over two years ago with the goal of replicating NSPersistentCloudKitContainer’s syncing behavior, without the Core Data hard dependency. Additionally, I wanted a solution that provided harder guarantees, more control, and more diagnostic information. I didn’t find an existing solution that met all of my requirements, so I (reluctantly) set out to build my own.
After years of refining this framework and fixing various bugs in my app, I’ve learned a lot about CloudKit syncing. You can glean some of my learnings by reading the code, but there’s a lot more that I felt I could share with a proper, technical blog post.

I love posts like this that are based on experience in the field:

CloudKit implements rate limiting. It has a special CKError code for this, requestRateLimited, but I’ve actually never seen an error with this code. In practice, rate limiting is indicated by serviceUnavailable (CKError 6, HTTP code 503).
[…]
Users want to know if their data is being synced properly. And from a customer support perspective, it’s invaluable to have logs and rich diagnostic information about the sync engine. Here are some diagnostics that I’ve found to be super helpful[…]

CloudSyncSession:

In an effort to make as much of the logic and behavior testable, most CloudKit-specific code is decoupled and/or mockable via protocols.

[…]

CloudSyncSession is not intended to be a drop-in solution to integrating CloudKit into your app. You need to correctly persist metadata and records to disk. In addition, you must use the appropriate hooks to convert your data models to and from CKRecords.

It does not support assets.

Canopy

Canopy:

A library that helps you isolate CloudKit dependency and write testable code using CloudKit.

[…]

In live use of your app, you initiate and inject the live Canopy object that talks to CloudKit. When independently testing your features, you instead inject a mock Canopy object that doesn’t talk to any cloud services, but instead plays back mock responses.

Jaanus Kase:

There’s still not a whole lot written about CloudKit. It continues to be this mysterious thing and I think it’s underused.

As part of Canopy, I publish a documentation site that covers not only the library, but also some broader topics around CloudKit, such as its tradeoffs, how iCloud Advanced Data Protection affects your apps, etc.