Archive for June 23, 2021

Wednesday, June 23, 2021 [Tweets] [Favorites]

Xcode 13 Column Breakpoints

Keith Harrison:

Command-clicking on the symbol shows the code actions menu where you can set a column breakpoint[…] Xcode shows the breakpoint as a small carat at the column in the source code[…]

[…]

In the WWDC 2021 video on breakpoints they show an example of column breakpoints working with a complex set of Swift closures. When Xcode hits the breakpoint it allows you to inspect the anonymous parameter of the closure ($0).

This looks great. I hope they can get it working as shown in the video.

Password Reset iCloud Account Vulnerability

Laxman Muthiyah (Hacker News):

Therefore, the attacker would require 28K IP addresses to send up to 1 million requests to successfully verify the 6 digit code.

28k IP addresses looks easy if you use cloud service providers[…] And it worked!!! 🎉🎉🎉 Now I can change the password of any Apple ID with just their trusted phone number 😇

[…]

As you can see in the email screenshot, [Apple’s] analysis revealed that it only works against iCloud accounts that has not been used in passcode / password protected Apple devices.

I argued that even if the device passcode (4 digit or 6 digit) is asked instead of 6 digit code sent to email, it will still share the same rate limits and would be vulnerable to race condition based brute forcing attacks. We will also be able to discover the passcode of the associated Apple device.

[…]

They concluded that the only way to brute force the passcode is through brute forcing the Apple device which is not possible due to the local system rate limits.

He doesn’t seem to believe that, but I lean towards believing Apple there.

Apple offered him a bug bounty of $18K, which I do agree seems low given the vulnerability that he did demonstrate:

They need not reward the upper cap of the iCloud account takeover ($100k) but it should at least be close to it considering the impact it has created.

After all my hard work and almost a year of waiting, I didn’t get what I deserved because of Apple’s unfair judgement.

Apple seems to be developing a reputation for being slow and stingy in responding to security bounties, which I don’t think is a good sign for the security of its platforms. Do they want to incentivize hackers to do the right thing or not?

Previously:

Update (2021-07-30): See also: Catalin Cimpanu.

Mail App Extensions

Apple:

Meet MailKit: the best way to build amazing experiences on top of Mail. MailKit enables apps to easily and securely interact with the Mail app for macOS. We’ll deep dive into the MailKit API, and show you how to create extensions for composing messages, message actions, secure email, and content blocking.

Joe Rossignol:

In the WWDC session, Apple indicated that older Mail app plug-ins will stop functioning in an unspecified future macOS release.

Plug-ins still work in Monterey, and SpamSieve’s is already in public beta.

Currently, MailKit’s functionality is very limited. Unless it’s expanded in a future version, I think a lot of plug-ins will not be able to make the transition to extensions, a loss to both their users and developers.

For SpamSieve, I’m cautiously optimistic about extensions. In theory, the current Monterey API is sufficient to implement the core SpamSieve functionality, though implementing some of the more advanced features would require API changes (FB9176051, FB9176075, FB9176097). I say, “in theory,” because MailKit in the Monterey developer beta doesn’t work as designed/documented. Extensions are supposed to be able to access the raw data of the message, but currently they receive either incomplete data (FB9175977) or none at all (FB9176011).

This takes me back to why I wrote a Mail plug-in in the first place. I had resisted doing so because I didn’t want to rely on an unsupported private API. But the reason I ended up making a plug-in is that the official API (AppleScript rule actions) was buggy. The private API ended up being more reliable and faster. And I’ve even been able to patch Mail to fix some (FB7035263) but not all (FB7145734) of Mail’s AppleScript bugs and to tweak the interface to make it more readable.

The private API has proven amazingly stable. I’ve always tried to make minimal hooks into Mail, and so the updates needed due to Mail code changes have been minor. The main hurdles have been unrelated to the API itself:

So, while I’m excited to be able to build on a public API, I’m more excited that these other issues could potentially all go away, so that installation could be as simple as checking a box in Mail’s preferences. This could get the user experience back to what it was like before sandboxing.

The main downside of extensions is that, as mentioned, they are limited to only the specific features that Apple has decided to open up. They are paving a naturally worn path, which is great, but they are also prohibiting anyone from walking off of the road. Secondly, since extensions run in an isolated process they are at the mercy of any bugs in Mail itself. Increased security rules out good patches along with bad ones.

My plan for SpamSieve is as follows:

Privacy Implications of Live Photos

Mark Hurst:

When you tap the circle on the bottom of the screen to take the photo, and you hear the artificial “click-shh” shutter sound, Apple stores a three-second video: 1.5 seconds of video before you tapped the button, and 1.5 seconds after you tapped it. That’s video and audio.

[…]

Millions of people around the world are taking videos when they think they’re taking photos. And millions more, posing for the camera, assume they’ll appear in a photo, but they’re actually in a video, including sound, before and after the shutter goes off.

At least you can now use Settings ‣ Camera ‣ Preserve Settings ‣ Live Photo so that it remembers to stay off, but:

Apple’s world-famous UI design team wants to make sure you understand: if you want Live Photos permanently turned OFF, you must have Live Photo set to ON.

He cynically connects this to revenue:

Activating (and automatically re-activating) Live Photos ensures that Apple devices will use the most possible data: videos, after all, take up a lot more space than photos.

And even if someone has turned off iCloud hosting, the extra use of data ensures that Apple will be able to issue that glorious warning message as soon as possible: “Your iPhone is running out of space.” By which Apple means: buy an even bigger overpriced device.

This could also be explained by Apple wanting users to be able to take advantage of a new feature that they may not be aware of. There is certainly some logic to recording the most data possible since otherwise the opportunity will be gone forever, whereas it can always be pruned later. As far as I know, though, Apple does not provide a way for you to see how much extra space is being used by Live Photos, nor a way to remove the video and audio data in bulk.

And there are also privacy implications because Live Photos defaults to on, most users don’t know how to turn it off, and all of this unexpected audio is stored, not end-to-end encrypted, on Apple’s iCloud servers (in iCloud Photo Library or iCloud Backup).