It used to be Apple rarely highlighted security and privacy in its developer-focused WWDC keynote presentation. But over the past few years Apple has consistently highlighted new options to keep users safe from attackers and snooping eyes alike. Still, with a mere two hours to cover a wealth of advances in multiple operating systems and the corresponding developer tools, the security details in Monday’s keynote were sparse.
Still, if you’re a bit (OK, very) familiar with Apple’s platforms, the future of Mac and iOS security becomes a little clearer. And it’s clear that for the next generation of products, “extension” is the name of the (security) game.
iOS 8: Prying open Touch ID and the sandbox
The inclusion of the Touch ID fingerprint reader in the iPhone 5s enabled users to have strong passwords with the convenience of nearly no password at all. According to Apple, less than half of iPhone users enabled a passcode before Touch ID. On the iPhone 5s, fully 83% now use this crucial safety belt.
Touch ID uses an interesting architecture. Currently, when you first turn on your iPhone, or after rebooting it, you enter your password, which is then stored in the special Secure Enclave portion of the A7 processor. Your fingerprint then unlocks and releases this password to the rest of the operating system. It doesn’t remove the need for a password, but makes using one nearly effortless.
Extending Touch ID to third-party apps could help users to use strong passwords in more settings.
In iOS 8, Apple is extending this model to cover third-party application credentials. Apps that store their credentials in the iOS keychain will be able to use Touch ID to authenticate the user. This will likely be widely misunderstood as allowing banks and retailers to use your password for authentication instead of a password. Instead, Touch ID allows an application to keep your password locked away in the keychain until you release it with a fingerprint registered with the device.
The difference is subtle. You still need a password, you just won’t have to enter it all the time. I also suspect the API will allow app developers to set certain restrictions on when Touch ID will be acceptable, and when it might require the user to re-enter the password. This improves application security by improving usability—Touch ID-enabled apps effectively ask users to authenticate (with a fingerprint) every time, without requiring them to always enter a password.
This won’t improve the security of apps that currently require passwords every time you use them (such as my bank apps), aside from potentially inspiring users to enable better passwords if they know they won’t have to constantly type them in. It could be a real boon for other apps that currently cache your password since they won’t be afraid to authenticate users every time, because a fingerprint is so convenient.
It might also inspire more than a few parents to delete their children’s fingerprints from their devices.
Extensions to where?
The details of the other major security enhancement are a bit murkier. Apple is opening up direct communications between iOS apps through something called extensions. Apple has long restricted inter-app communications to maintain the security and integrity of app sandboxes. While this has frustrated some developers, sandboxes are a powerful security tool to limit the risks that one compromised app could compromise other areas of your device.
Based on the limited information available in the keynote, it appears that iOS 8 developers will now be able to open up their apps to external communications. This extension is like a little receptor on the edge of the sandbox that receives a message and acts on it. Extensions register themselves with iOS, which mediates communications between apps.
Rather than opening up communications willy nilly, it appears that extensions still obey the rules of the sandbox. Any requests to do something new on your device, such as communicate over the network, will still require user approval (such as those prompts to access your camera or microphone currently in iOS). The fuzzy part is where that line will be, exactly. One option would be to require approval for every first-time request between two different applications. Based on the keynote demonstrations, I suspect it won’t be quite that granular, but this is one area I also expect to evolve considerably during beta testing.
What is clear is that iOS is the broker between application extensions, which likely keeps a fair bit of security in the process since apps won’t be communicating and (potentially) attacking each other directly. Maintaining the iOS privacy controls also means that nifty new keyboard replacements won’t be sending all your keystrokes to a black-masked attacker (as has happened on Android).
iOS 8 does opens up a host of other security questions that I simply don’t have anything to base an informed judgement on. Shared file storage with iOS or third-party cloud services, the security model of Continuity, any details on the new enterprise features like Extended Data Protection, and the usual under the hood enhancements—they’re all TBD.
Swiftly climbing in Yosemite
Apple said less about any security changes in OS X 10.10. In large part, this is due to the fundamental differences between a full desktop operating system and iOS. Apps can already talk to each other, even when sandboxed, and hook into the operating system at a deeper level. I suspect most of the security improvements are inside the OS X internals.
Swift, Apple’s brand-new programming language, could help security, but we won’t know until its apps meet the wide-open Internet.
One advance with significant long-term implications is the introduction of the Swift programming language. As a part-time coder (okay, dabbler) myself, I never underestimate the challenge of building a secure language that wipes out all the little errors that could inadvertently open the doors to attackers. Apple stated Swift wipes out buffer overflows and a series of other security issues that plague most languages. This is a tough challenge, and while we’ve seen success with such efforts in other modern languages, we’ve also seen plenty of failures.
Only open combat on the Internet will let us know how well Swift’s security model works, but it is likely an improvement over Objective-C and could, over time, help harden app security in both OS X and iOS.
Safari gains more usable privacy by allowing users to open a private browsing window without flipping the entire browser into private mode. This is the same as Google Chrome’s Incognito model, which is much easier to use than Safari’s current on-or-off model. I’m also curious as to how deep the privacy restrictions run; those pesky Web advertisers are quite devious at circumventing most privacy controls.
On a lesser note, I’m thrilled that we will soon be able to use the privacy-conscious DuckDuckGo search engine right from within the address bar. It’s a nice touch for the privacy-minded.
Apple didn’t mention anything more on OS X security and privacy, but every other version of the Mac OS has added a variety of unpublicized security and privacy controls. With months to hunt them out, I expect to find more.
iOS 8 and Yosemite appear to be less about adding new security and privacy features, and more about opening and extending them deeper into the app ecosystem. The more Apple enables security for developers—not just for the operating systems themselves—the better our devices will be able to withstand the dark side of the Internet.