Dominic Preston (Hacker News, MacRumors):
Apple has reportedly been ordered by the UK government to create a backdoor that would give security officials access to users’ encrypted iCloud backups. If implemented, British security services would have access to the backups of any user worldwide, not just Brits, and Apple would not be permitted to alert users that their encryption was compromised.
The Washington Post reports that the secret order, issued last month, is based on rights given under the UK’s Investigatory Powers Act of 2016, also known as the Snoopers’ Charter. Officials have apparently demanded blanket access to end-to-end encrypted files uploaded by any user worldwide, rather than access to a specific account.
[…]
The UK has reportedly served Apple a document called a technical capability notice. It’s a criminal offense to even reveal that the government has made a demand. Similarly, if Apple did accede to the UK’s demands then it apparently would not be allowed to warn users that its encrypted service is no longer fully secure.
Dan Moren:
While law enforcement has long been able to access encrypted data for which Apple holds the keys, this move would reportedly apply to end-to-end data in which the user holds the keys, such as Apple’s Advanced Data Protection. This law would target end-to-end encrypted data from Google and Meta as well.
This is red alert, five-alarm-fire kind of stuff. Providing a backdoor would be worrying enough for reasons that should be obvious to anybody who knows the barest inkling about technology—to wit, that there exists no mechanism to keep such a tool out of the hands of malicious actors—but the fact that it would apply beyond the UK borders to other countries is a staggering breach of sovereignty. And, moreover, as Menn points out, such a move would no doubt embolden other powers to ask for access to the same capabilities—such as China.
[…]
Ironically, the biggest impediment might come in the form of the European Union, as Apple apparently argued that the implementation would undermine the European right to privacy.
Nick Heer:
In any case, the reported demands by the U.K. government are an extraordinary abuse of their own. It has global implications for both U.K. access and, I would venture, access by its allies. As a reminder, U.S. and U.K. spy agencies routinely shared collected data while avoiding domestic legal protections. This order explicitly revives the bad old days of constant access.
Tim Hardwick:
According to sources that spoke to the publication, Apple is likely to stop offering encrypted storage in the UK as a result of the demand. Specifically, Apple could withdraw Advanced Data Protection, an opt-in feature that provides end-to-end encryption (E2EE) for iCloud backups, such as Photos, Notes, Voice Memos, Messages backups, and device backups.
In this scenario, UK users would still have access to basic iCloud services, but their data would lack the additional layer of security that prevents even Apple from accessing it.
Previously:
Backup iCloud iOS iOS 18 Legal Mac macOS 15 Sequoia Privacy United Kingdom
SpamSieve 3.1.1 improves the filtering accuracy of my Mac e-mail spam filter, amongst other enhancements and fixes.
The update was held up because the Developer ID Notary Service was down for most of the business day yesterday.
Some interesting issues were:
I don’t know whether something changed with a Sequoia update, but several customers reported crashes due to Core Data throwing fault handling exceptions when SpamSieve tried to do something with the Contacts database. Since exceptions can’t be caught in Swift, I wrapped all the Contacts API calls with Objective-C @try blocks.
SpamSieve uses Core Data external binary data storage to keep message data and other large blobs out of the SQLite databases, and this also suddenly became the cause of crashes for some customers. When there’s an error saving the database, SpamSieve logs it, and as recently discussed, this calls description on the related managed objects. Normally, this would be good because it would give an idea of what the app was doing at the time and perhaps provide a way to recover any unsaved changes, since the descriptions of the property values get logged as well.
However, blobs that are backed by files are handled using the _PFExternalReferenceData subclass of NSData, and it turns out that when it’s unable to load the data it just throws an exception. As above, this can’t be caught in Swift, so it crashes the whole app. I would prefer that invalid objects describe themselves as such rather than crashing, but I guess Apple didn’t think of this edge case. Objective-C wrapper to the rescue again.
Swift did help in another area, though. I was able to make some custom collections to optimize handling of large selections in table views. SpamSieve already fetched NSManagedObjectIDs so that tables with millions of rows only have to bring into memory the small number of objects that are actually being displayed at any one time. I previously discussed making a custom collection that uses Core Data’s built-in batching. However, in this case we do something different because that’s too slow when it might block the user interface. So I have another collection type that will fetch the IDs on a background queue, so that the table can reload asynchronously, and then realize the objects on the main queue, so they can be used in the table. This much was already in SpamSieve 3.0.
What’s new in 3.1.1 is that it uses a similar mechanism to handle the selected objects using IDs instead of objects. Previously, as soon as you made a selection, those objects would be fetched and used for menu validation and for restoring the selection if the database changed in the background. Now, this is all done using IDs, and if full objects are needed for validation or to do something with the selection, it only brings them into memory in batches. The most common case is saving/comparing/restoring the selection, and this can be done entirely using IDs. It also transparently skips objects that were selected but that got deleted between then and when it was time to actually process that object. So it’s conceptually a collection of optional objects, but there’s a lazy filter to make them appear non-optional.
It’s all hidden behind the Collection protocol so that tables that are backed by Core Data get the optimization, but the same code also works for other tables. However, though the result works well, I don’t give Swift full points because the implementation was unsatisfying. I couldn’t figure out how to express exactly what I wanted to the type system without adding a lot of boilerplate that, in my view, would be more likely to cause bugs in the future than would the invalid code that it was trying to protect me from.
The issue is that I want the collection to be generic over T (the type of the row object). Sometimes it will store a plain ArraySlice<T>, and other times it will store a lazy collection that fetches Ts. The latter is only legal if T is an NSManagedObject, but there doesn’t seem to be a way to tell Swift that the outer collection only uses the Core Data backing collection in that case. Thus, it will refuse to compile because it (correctly) can’t prove that T is always an NSManagedObject. It seemed like there were several potential solutions:
- The collection could have different subclasses, with one of them requiring
T to be a managed object. This seemed like it would create a mess with all the operations that take two collections, which might then be of different types. Currently, the backing is an enum, so the compiler will check that all the combinations are handled everywhere.
- The backings within the collection could be hidden behind protocols. I didn’t quite figure out whether this would actually solve the problem because it seemed to be unworkable for other reasons: it seems to require either an existential property (not supported by all the macOS versions I’m deploying to) or giving the collection another generic parameter that would then spread throughout the app.
- I went with the much simpler solution of bypassing the type system by making the backing collection only officially store plain
NSManagedObjects and then casting them to T on the way out.
Previously:
Contacts Core Data Mac macOS 15 Sequoia Notarization Optimization Programming SpamSieve Swift Programming Language
Dan Goodin:
On Thursday, mobile security company NowSecure reported that the app sends sensitive data over unencrypted channels, making the data readable to anyone who can monitor the traffic. More sophisticated attackers could also tamper with the data while it’s in transit. Apple strongly encourages iPhone and iPad developers to enforce encryption of data sent over the wire using ATS (App Transport Security). For unknown reasons, that protection is globally disabled in the app, NowSecure said.
[…]
What’s more, the data is sent to servers that are controlled by ByteDance, the Chinese company that owns TikTok. While some of that data is properly encrypted using transport layer security, once it’s decrypted on the ByteDance-controlled servers, it can be cross-referenced with user data collected elsewhere to identify specific users and potentially track queries and other usage.
Ben Lovejoy:
The latest findings are far worse than the previous security failure which exposed chat history and other sensitive information in a database requiring no authentication …
Brian Krebs:
Beyond security concerns tied to the DeepSeek iOS app, there are indications the Chinese AI company may be playing fast and loose with the data that it collects from and about users. On January 29, researchers at Wiz said they discovered a publicly accessible database linked to DeepSeek that exposed “a significant volume of chat history, backend data and sensitive information, including log streams, API secrets, and operational details.”
“More critically, the exposure allowed for full database control and potential privilege escalation within the DeepSeek environment, without any authentication or defense mechanism to the outside world,” Wiz wrote.
William Gallagher:
NowSecure says it is continuing to research DeepSeek. It notes that the Android version is even less secure than the iOS one.
Previously:
DeepSeek iOS iOS 18 iOS App Privacy
Wes Davis:
Apps distributed through both Apple and Google’s app stores are hiding malicious screenshot-reading code that’s being used to steal cryptocurrency, the cybersecurity software firm Kaspersky reported today. It’s the “first known case” of apps infected with malware that uses OCR tech to extract text from images making it into Apple’s App Store, according to a blog post detailing the company’s findings.
Kaspersky says it discovered the code from this particular malware campaign, which it calls “SparkCat,” in late 2024 and that the frameworks for it appear to have been created in March of the same year.
Via Guy English:
This is the kind of thing that makes tech so annoying these days. What’s a platform to do? At the scale of adoption of these devices (both Apple and Android) there are countless people who’d not think twice about agreeing to photo access without thinking for a moment of the screenshot with their credentials they saved off a long time ago. The only solution I can think of is only using system UI to pick what apps see. Which we have now. But that’s kind of annoying too.
Bruce Schneier:
That’s a tactic I have not heard of before.
Juli Clover:
Kaspersky located several App Store apps with OCR spyware, including ComeCome, WeTink, and AnyGPT, but it is not clear if the infection was a “deliberate action by the developers” or the “result of a supply chain attack.”
[…]
Apple checks over every app in the App Store , and a malicious app marks a failure of Apple’s app review process. In this case, there does not appear to be an obvious indication of a trojan in the app, and the permissions that it requests appear to be needed for core functionality.
Juli Clover:
Apple pulled the apps from the App Store.
Android Android App App Store Bitcoin and Cryptocurrency Google Play Store iOS iOS 18 iOS App Malware Optical Character Recognition (OCR) Privacy Screenshots
