Thursday’s surprise announcement of the next version of Mac OS X had developers across the Mac community perking up their ears, thanks in no small part to a new feature in Mountain Lion called Gatekeeper.
“My takeaway on Gatekeeper is it’s a lightweight introduction of the notion of registered developers outside the App Store,” Daniel Jalkut, proprietor of Red Sweater Software, explained toMacworld.
Gatekeeper relies on a technique called code-signing, in which software developers are provided with a cryptographic certificate from an authority—in this case, Apple—which they can then use to digitally “sign” their applications. It’s similar to the process that consumers encounter when they buy things via the Web, in which they’ve been trained to look for the padlock icon that indicates a secure transaction.
“Security based on digital signatures has been a long time coming, so it shouldn’t be much of a surprise to developers,” said Ecamm Network co-owner Glen Aspeslagh. “As the Mac gains in popularity, Apple’s approach will be a powerful and much needed weapon against malware.”
While our Windows-using compatriots have been plagued by malware of all shapes and flavors, Mac users have remained largely unscathed, although the debate continues to rage over whether that’s because of innate superiority in the Mac operating system or the Mac’s smaller market share presenting a less tempting target for writers of malicious software.
Certificate of authenticity
Apple’s new approach relies on the idea of what it calls “identified developers,” which is to say developers to whom the company has issued a digital certificate. That certificate becomes linked with the developer’s identity and subsequently with their applications. If Apple finds that a software maker is distributing an application that contains some sort of malicious code, it can revoke the certificate, which—depending on how a user has Mountain Lion set up—may prevent the app from launching. Presumably, Apple could even revoke all the apps from a single developer with the flip of a switch.
This isn’t really a new concept for Apple; code-signing as an option has been around since 2007, when it was introduced as part of Mac OS X 10.5 Leopard. And the company has employed it as a requirement for programs distributed in both the App Store for iOS and the Mac App Store.
“We’ve been in the Mac App Store for a while (since the very beginning),” Bare Bones Software’s Rich Siegel told Macworld, “and as far as I can tell, if you’re shipping a Mac App Store product today, you’re an ‘identified developer.’”
But, of course, not all Mac developers participate in the Mac App Store. So while developers can sign their own code to certify, for example, that the contents of their apps have not been altered since distribution, they can’t reap all the potential benefits that code-signing has to offer. In order to do that, the certificates would need to be issued by a trusted authority—to wit, Apple.
So last November, Delicious Monster chief executive Wil Shipley
proposed in a blog post that Apple issue certificates that would allow developers to release self-signed apps outside of the app store environments as a way to help combat malware without going to the complexity of other proposed solutions, like sandboxing (more on which later).
“My suggestion,” Shipley wrote on his blog, “is for Apple to provide certificates directly to developers and allow the developers to sign their own code. And, by doing this, Apple can then reasonably say, ‘Ok, now we’re going to, by default, not allow the user to run any code whose certificate wasn’t issued by us and signed by a real third-party developer (except the stuff the user checks in the control panel).’”
That seems to be more or less the approach that Apple has embraced with Mountain Lion, which allows users to choose which applications they’d like to run: any apps at all, only apps from the Mac App Storeand identified developers, or just apps from the Mac App Store.
“What’s most exciting for us as non-App Store developers is this new de-coupling of app signing security and the Mac App Store,” said Ecamm's Glen Aspeslagh. “The message I’m getting here from Apple is ‘Non-MAS apps are alive and well for the time being. But we know where you live.’”
“I think this is a fantastic approach,” added Ken Aspeslagh, Ecamm’s other co-owner. “Apple could have gone all or none, so this middle of the road option is great news.”
Indeed, the introduction of Gatekeeper would seem to assuage one popular concern, that Apple would eventually go the same route with Mac apps as it has with iOS apps, mandating that only those purchased from its storefronts can run on the platform.
“That is a reassuring message, given recent fears that [Apple] may have an eye on locking things down,” said Jalkut. Of course, he adds, it may be nothing more then an intermediary step in bringing those identified developers into the fold as full Mac App Store citizens.
In fact, some developers would like to see that very same approach expanded to Apple’s other platform.
“Having the option to install signed apps from outside iOS App Store wouldn’t make it any less secure, especially if the signing process still acted as a kill switch,” said Paul Kafasis, CEO of Rogue Amoeba.
That’s an approach that Google has long taken with its Android mobile operating system, which allows users to check a box to install apps from outside of the Android Market. But Apple has stuck to its guns, only allowing users to download apps through the App Store.
And that precedent still makes some worry about the future of the Mac OS, as Bare Bones Software’s Siegel pointed out. “In a larger sense, though, I think we may be watching an inexorable move toward a Mac OS X that is locked down by default, such that you won’t be able to run software that wasn’t purchased from the Mac App Store.”
It depends, he says, on which of Mountain Lion’s three settings ends up as the default option. “A default which allows App Store apps or Apple-signed products would certainly strike a good balance for today’s developers and customers. However, the Gatekeeper default setting might easily end up allowing only Mac App Store applications. If so, that would lock out entire classes of useful product that cannot currently (or ever) be shipped through the Mac App Store.”
That’s a matter of concern, Siegel points out, and should be for everybody. “If Mountain Lion ships and the factory setting is such that only App Store apps can be run by default, then customers are denied access to the sort of ‘power tools’ that empower them to create content and craft solutions (including software products) using Macs. I believe that would undermine the fundamental core character of what the Mac has always been.”
Sandbox rules
The Mac App Store represents an even higher level of security than just becoming an identified developer. Most recently, there’s been much discussion over a security technique called “sandboxing,” which will, as of March 1, become a requirement for apps submitted to the Mac App Store.
Sandboxing, which has been a part of iOS since its release, restricts apps from interacting with other apps, their data, and certain parts of the OS itself. While few deny the security benefits of a sandboxed system, many developers have been concerned that it will make certain features impossible to implement—and may even render entire classes of applications persona non grata.
“What I’m most curious about is whether Gatekeeper, as a new tool in Apple’s security belt, changes their attitude at all about app sandboxing,” said Jalkut, “and whether the planned March 1 App Store sandboxing deadline will be revised.”
While sandboxing and certificates have similar aims, to keep the user safe, they accomplish that goal in different ways. Sandboxing is an implementation intended to prevent an app from doing anything that it shouldn’t—certificates, on the other hand, are more just a matter of accountability; those apps can still violate the rules, but if they do, they’ll have their authority revoked.
“If an application is signed by an Apple-issued developer certificate, this creates a chain of accountability,” explained Siegel. “If your product misbehaves or proves to be malware, Apple can find you (as the developer) and revoke your certificate; at that point, your product will no longer function when the OS is locked down. That’s certainly not a bad thing for consumers.”
But although sandboxing has garnered most of the criticism from developers about its potential handcuffing of app’s capabilities, the use of certificates is not without its own concerns.
For one thing, certificates aren’t a panacea for security issues. While they do allow Apple to rapidly react to cases of malware by revoking certificates, the Gatekeeper system has its limitations. It doesn’t check apps loaded on from a disk or USB drive, only those downloaded from the Internet. And it can still be overriden by users manually. So, there’s a concern that it could lead users to a sense of infallible security that isn’t realistic.
“If the OS refuses to run software with a missing or invalid code signature, that provides a measure of tamper resistance,” said Siegel. “On the other hand, code signing is no guarantee of reliability or quality: that still has to come from the developer; so there’s a chance that an enforced code signing requirement can create a false expectation in the customer’s mind.”
Another concern that might not be apparent to most users is that certificates of this sort usually have an expiration date, after which they must be renewed. For the most part, that’s not an issue, but it can conceivably cause problems.
“What [users] may not realize is it also means that if a developer decides to move on, their ‘signed’ apps may stop working a year later, since their certificate won’t be valid any more,” said Dave Nanian, owner of Shirt Pocket Software. “It won’t be a matter of ‘OK-ing’ them—they’ll just stop working.”
Mac App Store front
There’s also a slippery slope argument, Nanian points out, in terms of the kind of authority that Apple wields over developers’ applications: “In addition to the ‘your software expires’ problem, it also hands ‘veto power’ over to Apple, who can revoke your certificate at will.”
Siegel concurs, calling the identified developer system a “two-edged sword.”
“As the issuing authority for your developer certificate, Apple may revoke your certificate at any time, for any reason, and there won’t be anything that you can do about it,” he said. “If that happens, customers will be denied the use of your product.”
“Down the road we could see the basic concept of registered developers being extended to support more fine-grained, or more draconian security measures,” said Red Sweater’s Jalkut.
“Even that middle option [of only allowing apps from the Mac App Store and identified developers] is providing Apple with more control than they have now—that may not work out badly, but it’s something to consider,” added Rogue Amoeba’s Kafasis.
While Apple has, to date, not demonstrated a tendency to capriciously revoke certificates of this sort, concerns about the increasingly locked-down nature of software have been widespread among developers, and some users, since the debut of iOS.
That said, Apple is trying to make the process of embracing its new security procedures something that developers want to do, especially when it comes to the Mac App Store. Currently, it appears that certain features—such as the ability to add full-fledged support for iCloud, or support for Mountain Lion’s Notification Center—are only available to those who go the distance and submit their apps to the Mac App Store.
“The App Store-only APIs [application programming interfaces] continue to proliferate, which means we’re being marched, slowly-but-surely, to a future that’s increasingly locked down,” said Shirt Pocket’s Nanian.
“On the one hand, this may be seen as ‘encouragement’ to go App Store-only,” says Siegel. “On the other hand, it has a clear ‘offer you can’t refuse’ feel to it. Today, those APIs could reasonably be considered nonessential to certain products; but there’s absolutely nothing to stop Apple from introducing core-functional APIs that require App Store participation.”
Of course, some developers, such as Red Sweater’s Jalkut, have hopes that Apple might expand things: “What would be really interesting is if Apple decided to let identified developer certificates entitle apps to access things like iCloud that are currently limited to App Store apps.”
The devil is in the details
Developers do seem inclined to embrace Apple’s new certificate system, largely because it’s not a particularly onerous task on their part, and it can benefit users.
“Indeed, even as a developer I’m reassured to know that I won’t be accidentally running things from sources that are not at least somewhat vetted,” said Jalkut.
And many developers have been code-signing their own applications for years now, ever since the tools to do so have been available.
“We adopted code-signing pretty quickly back when it was first supported by the OS, back in 2007,” commented Siegel. “At the time it seemed pretty clear to us that some day, code signing was going to be a requirement for Mac software.
“From a developer’s perspective, signing isn’t a big deal, and the tools for that have improved over the years,” Nanian added.
“Hopefully, this program is specifically made for companies like us—to show we’re not malware, but not squeeze out any apps that Apple won’t approve for the Mac App Store,” said Kafasis. “We’ve been code-signing our software for years. We have no problem with that. But it will all depend on the terms required for the ‘identified developer’ program. Until we see those, we can’t know for sure what our next step will be. Provided those are not onerous, we’ll certainly sign up for it.”
As to whether or not it will actually improve things for users, many developers seem to be adopting a wait-and-see approach.
“It certainly seems to have good intentions. Security is obviously a good thing,” said Kafasis. “Time will tell if it actually enhances security, or just provides the illusion of security.”
“The bottom line is that security and accountability are always a good thing for consumers,” said Siegel. “Our concerns arise around how the mechanisms could be misused to the detriment of the developer community; or worse, to disempower the computing capabilities of mutually shared customers. The potential is clearly there; how it will all play out between now and when Mountain Lion ships remains to be seen.”
Shirt Pocket’s Dave Nanian agreed. “Do I think it’s a good thing for users? It may give them a false sense of security. We’ll have to see if that future is all puppies and kittens or whether, like the frog-in-the-pan, everything seemed reasonable until we got to the end of the process.”
0
comments
