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.
Debugging Mac macOS 11.0 Big Sur Programming Swift Programming Language Xcode
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.
Apple ID Apple Security Bounty Bug Exploit iCloud iOS iOS 14 Passwords Security Web
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:
When Apple sandboxed Mail, which meant that the plug-in could no longer communicate with the SpamSieve app via AppleScript. This required developing a new communication mechanism, making it zombie-proof, and making a new way to launch the app when needed.
The compatibility UUID policy, where instead of developers testing with new versions of Mail and updating their plug-ins as necessary, each new version of Mail requires each plug-in to be updated, even though most plug-ins don’t actually break due to minor Mail updates.
All the privacy changes in macOS 10.14 and later. Each subsequent version has added more hurdles to installing and using plug-ins, making installation and updates more complicated, and various system bugs can get in the way and require obscure reset procedures.
Issues related to code signing and notarization. Some versions of Mail require that plug-ins be signed. Some require that they not be signed. In some cases, the signing and installation location depend on where the user’s home folder is located.
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:
Keep supporting the current plug-in, since some users will remain on Big Sur and earlier releases for a long time. It will also offer the most extensive feature set, at least on Monterey.
Develop a Mail extension to be ready for the day when plug-ins stop functioning, and to identify any (additional) issues so that they can be reported to Apple well before then.
Develop a migration path from the plug-in to the extension.
Investigate other ways of potentially integrating with Mail in case Apple removes plug-ins before the extensions API is working. I don’t expect this to happen, but I’ve learned not to assume that any bug will get fixed.
Apple Mail AppleScript Bug E-mail Extensions Mac macOS 12 Monterey Private API Sandboxing SpamSieve
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).
Audio Backup Camera iCloud iCloud Photo Library iOS iOS 14 Live Photos Privacy
