Matt Apuzzo and Katie Benner (comments):
Apple engineers have already begun developing new security measures that would make it impossible for the government to break into a locked iPhone using methods similar to those now at the center of a court fight in California, according to people close to the company and security experts.
John Gruber:
The way the iPhone works today, when put into recovery mode you can restore the operating system without entering the device passcode. The only restriction is that the version of iOS to be installed must be properly signed by Apple.
[…]
I think what Apple is leaking here is that they’re going to change this (perhaps as soon as this year’s new iPhone 7), so that you can’t install a new version of iOS, even in recovery mode, without entering the device’s passcode. (I think they will also do the same for firmware updates to the code that executes on the Secure Enclave — it will require a passcode lock.)
If you do a full restore, you can install a new version of the OS without the passcode, but this wipes the data.
It’s understandable that Tim Cook wants the conversation to be about the FBI asking Apple to build a backdoor. But I think a more accurate description is that the backdoor already exists. Apple today could update the OS to remove security protections, without wiping the data. The dispute with the FBI is that Apple doesn’t want to use the backdoor. And now it is working to remove it.
Previously: FBI Asks Apple for Secure Golden Key.
Update (2016-02-29): Leif Ryge (via Alexis Gallagher):
So when Apple says the FBI is trying to “force us to build a backdoor into our products,” what they are really saying is that the FBI is trying to force them to use a backdoor which already exists in their products. (The fact that the FBI is also asking them to write new software is not as relevant, because they could pay somebody else to do that. The thing that Apple can provide which nobody else can is the signature.)
Is it reasonable to describe these single points of failure as backdoors? I think many people might argue that industry-standard systems for ensuring software update authenticity do not qualify as backdoors, perhaps because their existence is not secret or hidden in any way. But in the present Apple case where they are themselves using the word “backdoor,” abusing their cryptographic single point of failure is precisely what the FBI is demanding.
Update (2016-03-03): Alexis Gallagher:
Part of Apple’s defense rests on the fact that they don’t have the passcode, and the FBI is ordering them to create new software. […] What happens to Apple’s legal position if the FBI “only” orders Apple to hand over the signing keys (poor man’s passcode)?
Federal Bureau of Investigation (FBI) iOS iPhone Privacy Secure Enclave Security
Andrew Cunningham:
Privacy is definitely one reason to use local backups; if your encrypted phone backup is stored on your encrypted laptop that is itself protected with a strong password, there’s very little chance that anyone without the right credentials can get access to anything.
There are also benefits when you’re restoring that backup to your iPhone. As Apple’s page on encrypted iTunes backups outlines, encrypted local backups are the only ones that contain saved account passwords, Wi-Fi settings, browsing history, and data from the Health app. Apple doesn’t want this data on its servers for security and privacy reasons, and it’s not stored in unencrypted local backups for the same reason. Use encrypted local backups, and you get that info back if you need to do a restore.
It also helps if you’re upgrading to a new phone or using a loaner or replacement phone. When you restore an iCloud backup to a phone or tablet that’s not the phone or tablet you backed it up from, you don’t lose any of your photos or iMessage history or anything like that, but you do lose the credentials for e-mail accounts and any other apps that require authentication.
Juli Clover:
An archived iTunes backup is essential because it saves the current state of your iOS device and prevents it from being accidentally overwritten by subsequent backups. Apple recommends all public beta testers create an archived backup before installing a beta in case something goes wrong and a restore is needed.
[…]
To archive the backup, choose “Preferences” from the iTunes menu and select the “Devices” tab. Choose the fresh backup and right click to bring up the “Archive” option.
Update (2016-02-25): I have been informed that iCloud backups do include this extra data. Apple says they are encrypted, but I think this is on disk and in transit—not encrypted from Apple, who we know can access the data because it provides it to law enforcement. So it’s on the level of Dropbox’s encryption.
Update (2016-03-03): Juli Clover:
The details surrounding the case have made it clear that while Apple is unable to access information on iOS devices, the same is not true of iCloud backups. Apple can decrypt an iCloud backup and provide the information to authorities when ordered to do so via a warrant, as it did in the San Bernardino case.
In a piece posted on The Verge entitled “The iCloud Loophole,” Walt Mossberg takes a look at Apple’s iCloud backups and explains the reason why iCloud data can’t be made as secure as data stored solely on an iPhone or iPad.
Backup iCloud iOS iOS 9 iTunes Mac Mac OS X 10.11 El Capitan Privacy Security
OS X Daily:
The default iOS setting for iPhones is for message alerts to chime with the text tone twice, in a two minute interval. While the repeat text message alert sounds, notifications, and vibrations on the iPhone can be helpful for some people, those of us who are basically glued to our phones tend to experience quite the opposite and end up finding the repetitive alerts a nuisance, since it can seem like you’re being inundated with texts when you’re not.
Multiple chimes/buzzes for iMessage have been annoying me for years. I thought this was a bug, but it turns out that the notification settings for Messages are different from the settings for other apps.
iOS iOS 9 iPhone Messages.app Notification Center
Tonester:
I’m having trouble with a core data many-to-many relationship where both side’s delete rules are set to Nullify. I’m finding when I inspect the SQL database there are records left in the join table that should be deleted.
The two tables represent Playlists and Tracks. Playlist deletes don’t cascade to delete each track automatically because each track can be in multiple playlists.
Tonester:
I’ve noticed if you delete the relationship i.e. using removePlaylistTracksObject:, then save, then delete the playlist and track, then save, it works. I would expect the relationship record to be removed when deleting either the playlist or track and a single save. Also if the playlist to tracks is not ordered it works fine.
Marcus Zarra:
Thanks for the test case, that is an actual issue in Core Data. There is nothing in there that you are doing incorrectly. You really need to file a radar on this and I will file one as well.
In the interim you can either stop using ordered relationships (they are a bastardization anyway) or do the double delete.
Previously: Core Data Bugs.
Update (2016-02-25): James O’Leary:
Every year for (x) years I think “I should get rid of my ordering hack”, do research, and find CD’s is still broken :(
Bug Core Data iOS iOS 9 Mac Mac OS X 10.11 El Capitan Programming
Filip Pizlo (comments):
As of r195562, WebKit’s FTL JIT (Faster Than Light Just In Time compiler) now uses a new backend on OS X. The Bare Bones Backend, or B3 for short, replaces LLVM as the low-level optimizer in the FTL JIT. While LLVM is an excellent optimizer, it isn’t specifically designed for the optimization challenges of dynamic languages like JavaScript. We felt that we could get a bigger speed-up if we combined the best of the FTL architecture with a new compiler backend that incorporated what we learned from using LLVM but was tuned specifically for our needs.
[…]
We knew that we could get a speed-up on lots of real-world JavaScript code if we could get all of FTL’s high level optimizations without paying the full price of LLVM’s compile time. But we also knew that LLVM’s low-level optimizations were essential for benchmarks that ran long enough to hide compile time. This was a huge opportunity and a huge risk: beating LLVM’s compile times seemed easy, but it would only be a net win if the new backend could compete on throughput. […] We projected that if we could build a backend that compiled about ten times faster than LLVM while still generating comparable code, then we would get speed-ups on code that currently blocks on LLVM compilation.
Compiler iOS JavaScript Mac Optimization WebKit
