Answering Questions about Sandboxing, Gatekeeper, and the Mac App Store
Apple is in the midst of a major transition with the Mac platform. As users flock to the Mac, it’s only natural that criminals will follow — that growing market share makes the Mac community a sufficiently lucrative target. But it’s clear Apple recognizes this risk. Taking lessons from the currently malware-free world of iOS, Apple has been enhancing the security of Mac OS X since the release of Mac OS X 10.5 Leopard, slowly at first, and more significantly of late.
Apple’s strategy relies on five technical pillars: enhancing the foundational security of Mac OS X; hardening Safari (Web browsers being the most common avenue of attack today); encouraging apps to use sandboxing techniques to limit attack vectors; keeping the Mac App Store as free of malicious applications as possible; and, with 10.8 Mountain Lion, using Gatekeeper to reduce the ability of attackers to trick users into running downloaded malicious applications.
But we shouldn’t think of this as just an ever-escalating technical battle. Apple’s real goal with these changes, especially with the combination of the Mac App Store, sandboxing, and Gatekeeper, is to disrupt the economics that keep the bad guys in business, rather than fighting a never-ending series of one-off skirmishes.
As Uncle Ben said, “With great power comes great responsibility.” Apple’s moves toward a more-controlled (by Apple) experience on Mac OS X scare some users, and they could be problematic for many developers. The challenge for Cupertino will be to strike, and maintain, the right balance between control and freedom. That is, if they want to maintain the innovative heart that has made the Mac so appealing since 1984.
Let’s take a look at sandboxing, the Mac App Store, and Gatekeeper in particular, since they offer both the most promise for preventing attacks and the most risk for the soul of the Macintosh. I’m organizing this around answers to a series of questions — if you have additional questions, please ask them in the comments.
What is sandboxing? — Practically speaking, sandboxing prevents applications from doing unexpected things to your computer. Sandboxing encompasses a set of techniques to isolate applications and minimize what they can do on your Mac. The idea is that some applications could harm your computer, either deliberately or if an attacker compromises them, and putting these apps in a “sandbox” limits the potential damage. A sandboxed application is allowed to interact with the rest of your computer only through a strict set of rules that specify what actions it can perform. Sandboxing has been around for a long time and is already in use in Mac OS X, Windows, and other
operating systems.
Here’s a simplified explanation of how it works. A normal, non-sandboxed application has full access to everything on your computer, which can include reading and writing files anywhere on the file system, sniffing and sending network traffic, watching everything you type, controlling your camera and microphone, and more. (Technically speaking, the app is limited based on which protection ring it’s running in and what user account is active, but that isn’t important for this discussion.) Even if an app isn’t programmed to use all those capabilities, there is nothing in the operating system to limit what it can do. Thus, one of the most common ways to attack a computer is to find an application with a vulnerability, exploit that
vulnerability to inject malicious code into the application, and then use the application to run the malicious code to perform further actions.
In contrast, a sandboxed application doesn’t run with full access. Instead, it executes inside a restricted container that is isolated from the rest of your Mac. Thus, if an attacker were to exploit a vulnerability in the app and inject malicious code, that code would be limited to the sandbox.
That might work for simple, standalone apps like casual games — Angry Birds could be sandboxed easily. But for more complex programs, sandboxing has some obvious problems, like saving files and accessing the network. To work around this problem, each individual application can be given a set of “entitlements” that allow the app limited access to other parts of your Mac. For example, a fully sandboxed app with no entitlements can save files only into its own directory, but with an entitlement, it can be given permission to save files anywhere in your home folder (which is still safer than the app being able to save a file anywhere on the file system).
iOS apps are heavily sandboxed, which is why apps can’t access each other’s files. iOS offers no entitlement to access shared files other than photos, so we’re forced to copy files from app to app using the Open In command.
This particular limitation in iOS, to be blunt, sacrifices usability for security. But at least most apps in iOS don’t create or manipulate documents (although that’s changing, thanks to the iPad). On the Mac, where far more applications are document-centric, and where the entire user experience revolves around the Finder, such a system would be a major disaster that would immediately drive every professional user to Windows. It would become impossible to use multiple apps to make changes to the same document without making a vast number of copies, and keeping track of which change was in which copy would be a nightmare. As a result, Apple has created more possible entitlements for Mac apps than for iOS apps, but sandboxed apps are
still far more restricted than their non-sandboxed brethren.
The overall goal is the same — to ensure an application can’t do too much damage to your system, either by design or if it’s compromised by an attacker. But since the needs of Mac users are different than the needs of iOS users, it’s hard to figure out the right balance of restrictions and entitlements.
Why is sandboxing so important? — Sandboxing is, to put it lightly, a very big deal. As operating systems have become harder to exploit (believe it or not, it’s pretty hard these days), attackers have started targeting specific applications. We see more attacks against Adobe Acrobat and Flash, Microsoft Office, Java, Web browsers, and QuickTime than we do against Mac OS X and Windows themselves. That’s why, for example, Apple now sandboxes parts of Safari and QuickTime, Google sandboxes Chrome, and Adobe sandboxes Reader and Acrobat (only on Windows).
Take Google Chrome. It is widely considered the most secure Web browser available, due to its heavy use of sandboxing. Chrome even embeds and sandboxes its own version of Adobe Flash to reduce the chance of a Flash exploit taking over a computer (Flash is notoriously problematic from the security perspective). I’ve seen very few real-world exploits that work on Chrome, and even fewer that break through Chrome’s sandbox, when Flash is the target. That’s why I uninstalled Flash from my Mac and view Flash-using sites exclusively with Chrome.
Sandboxing isn’t a panacea. Some entitlements may allow an attacker to do bad things outside the sandbox. Also, sandboxes themselves are software and may be cracked. But, at a minimum, the sandbox adds yet another layer an attacker has to get past before getting a foothold on your Mac, even if the application inside is vulnerable and exploited.
To put it bluntly, based on the nature of attacks today, sandboxing is likely the future on every computing platform.
What does sandboxing have to do with the Mac App Store? — As of 1 June 2012, all new apps and major updates in the Mac App Store must be sandboxed.
Does this mean all Mac App Store apps are now sandboxed? — No. All new apps are sandboxed, but existing apps aren’t necessarily. Apple says they will allow bug fixes to non-sandboxed apps, but not other upgrades. I also get the sense this is a fuzzy line, and some exceptions may be made (at least in the short term).
How will this affect apps? — Some apps, if they wish to use sandboxing, will lose functionality that isn’t provided by existing entitlements. To get a sense of what entitlements are available to developers, check out Apple’s “Enabling App Sandbox” documentation. Apple also offers a set of temporary
entitlements that developers may use only with permission, and that might go away in the future. Accessing the Movies folder is a regular entitlement, while accessing Apple Events (to enable AppleScript-based communication between apps) is a temporary entitlement.
The lack of certain entitlements and developer uncertainty about relying on a temporary entitlement have already affected some apps in the Mac App Store, with some developers eliminating functionality that’s impossible given current entitlement limits and others offering more-capable versions for sale outside the Mac App Store. For instance, Smile’s popular typing expansion utility TextExpander 4 isn’t for sale in the Mac App Store for this reason, while version 3.4.2 remains available there.
On the one hand, users suffer from the loss of functionality and from the confusion of multiple versions of apps, and either approach costs developers time and money. On the other hand, the sandboxing requirement enhances the security of all new and updated apps in the Mac App Store.
Why is Apple mandating sandboxing in the Mac App Store? — Apple has learned a valuable lesson from iOS. There is currently no malware on iOS and we’ve never seen a widespread attack. Contrast this to Google Play and especially the non-Google-supported Android stores, which are riddled with Android app malware. Apple’s App Store requires sandboxing and reviews all apps; Google Play (and the alternative markets) place no such requirements on developers. Apple’s strict control over the App Store provides the safest user experience out there, and while you may not think about it
consciously, the fact is that you don’t have to worry about malware in the App Store doing bad things to your iPhone or iPad.
We see Android cybercriminals using the same techniques they’ve successfully relied upon to exploit Windows users, such as hiding Trojan horses in versions of popular applications, pretending to be security apps, and drive-by downloads.
Even if someone manages to sneak a malicious app into the App Store (as some researchers have done with proofs of concept), or an app is later compromised and used in attacks, Apple could remove it and stop all new infections. (Apple doesn’t uninstall apps from iOS devices, although they could do so with a software update in a really bad situation).
Apple wants to provide this same experience to users on Macs and give us a safe place to buy and install applications. They may not market that as a benefit of the Mac App Store explicitly, but they want security to effectively disappear as a concern for users.
Can bad guys break out of the sandbox? — Probably. Then Apple will harden it again. Then the bad guys will break it again. And so on. No technology is perfect, but sandboxing most definitely raises the costs of attacks. In fact, it so significantly raises the cost of attack that it wipes out entire classes of potential bad guys who lack the technical skills or budget to target and crack the sandbox.
Is there a downside to mandating sandboxing? — Absolutely. Not every application can meet the sandboxing requirements. Macs are general-purpose computers, and by definition, that means that developers can come up with innovative applications that can do things — and need to do things — that Apple has not anticipated and for which there are no entitlements.
Some apps will never be able to be sold in the Mac App Store. This is a problem since, as more users go to the Mac App Store for their apps, it may become economically difficult for those developers to reach a large enough audience.
We don’t know how this will play out in the long term. My hope is that as the overall Mac market share increases it will create more opportunities for both Mac App Store and independently sold applications, offsetting the inability to sell non-sandboxed apps in the Mac App Store. This is clearly an optimistic view, and it’s also entirely possible that the market for smaller developers whose apps can’t be sandboxed and sold in the Mac App Store could shrink to the point of driving them out of business.
Apple also faces criticism, especially from developers, related to other Mac App Store problems (such as unpredictable and poorly supported rejections, the lack of demos, the inability to communicate with customers and respond to user reviews, and more). Mandating sandboxing without addressing these other complaints has increased developer concern and uncertainty, and connected Mac App Store policies and sandboxing in a way that I fear could hurt the perception of this valuable security technique.
Why not make sandboxing optional? — In my experience, optional security is non-existent security. Microsoft has offered sandboxing capabilities for years and practically no developers use them. Microsoft even struggles to get developers to adopt anti-exploitation technologies like ASLR or EMET, despite the fact that there is basically no cost in doing so because the technologies are built into development tools. Heck, it took Microsoft years to convince Apple to enable ASLR for its Windows applications.
Apple wants the Mac App Store to be as safe as possible. Maybe it’s for marketing, maybe it’s for altruism, but the motivation doesn’t matter if the results improve our safety. Based on past history, if Apple doesn’t mandate sandboxing, nearly no developers will likely use it. I hate to word it that way, but I’ve been in the security game for a long time and all my experience, and that of other security professionals, says that, without a stick, only a few horses will eat the carrot.
Does Apple sandbox their own apps? — Not those sold in the Mac App Store. And, to be honest, it would really help their case with developers if Apple would follow their own rules. It would also help Apple better understand developer concerns and improve entitlements if their own teams had to work within the same restrictions. Perhaps they are moving in this direction internally, but the current versions of Apple’s major applications in the Mac App Store (including Aperture, Final Cut Pro, iLife, and iWork) are not sandboxed.
Aside from the poor example this sets, you have to assume that the bad guys are also working to target Apple’s applications — after all, iTunes is nearly ubiquitous on Macs, and if it’s not sandboxed, that makes it all the more attractive as a conduit for malware. iPhoto is probably next on the target list, with GarageBand, Pages, Keynote, Numbers, and the professional apps coming in behind.
Will Apple grant exemptions to any apps or developers? — Possibly, though if this has happened so far, no one is talking. I get the impression Apple’s policy-makers are still feeling their way around, at least internally. (Developers report that any queries about exemptions that aren’t already covered by entitlements are met with resounding silence from Apple.) We’ll need to see if they grant exemptions to sandboxing for any major or innovative developers, but right now the rule is hard and fast. All I can say is that, in my discussions with Apple, I sense that the sandboxing requirement and entitlement list isn’t as final as, say, killing off floppy drives.
Where does Gatekeeper fit in? — Gatekeeper is a new feature in Mountain Lion that enables you to restrict what kind of downloaded applications will run on your Mac. While Apple has designed the Mac App Store and the sandboxing requirement to give users a safe place to buy apps, Gatekeeper is designed to strike at the economic heart of cybercrime.
By default — and most people won’t change this setting — Gatekeeper will allow only two types of downloaded apps to launch on a Mac: those from the Mac App Store, and apps that are digitally signed with an Apple-issued Developer ID.
One of the most common ways to get malicious software onto someone’s Mac is to trick them into downloading and installing it. Criminals use sophisticated techniques that often fool knowledgeable users and even security pros, not just less-experienced users. By preventing downloaded software from launching unless it comes from the Mac App Store or a known developer, Gatekeeper closes the door to this approach to infection.
Bad guys will undoubtedly try to bypass Gatekeeper by, for example, stealing a legitimate developer’s Developer ID, but once again, the addition of Gatekeeper makes it much harder to produce malware that could spread widely, and thus reduces possible profit.
How does Gatekeeper work? — I covered Gatekeeper’s features in depth in “Gatekeeper Slams the Door on Mac Malware Epidemics” (16 February 2012), but here is a quick summary:
- Gatekeeper enables you to restrict which downloaded applications can launch on your Mac. There are three possibilities: Mac App Store only, Mac App Store plus Developer ID-signed applications, and no restrictions. The default is to allow Mac App Store apps and Developer ID-signed apps.
- Gatekeeper checks only applications downloaded using programs (like Web browsers) on a list Apple maintains. Thus not every downloaded file is quarantined, nor are files transferred using cloud-storage services like Dropbox, USB flash drives, CD/DVDs, or other media.
-
You can override Gatekeeper and run any arbitrary application by Control-clicking it and choosing Open, but this command is intentionally concealed to make the process non-intuitive and, at minimum, to make the user realize something strange is going on. Apple has purposely made it more difficult than merely clicking an Open Anyway button in a dialog, since we users have a tendency to click whatever appears.
-
Gatekeeper checks downloaded applications only the first time they run. And, of course, since it checks only downloaded apps, it won’t check any already installed applications when you upgrade to Mountain Lion.
There’s a lot more to Gatekeeper, but the main thing to know is that once you upgrade to Mountain Lion you won’t be able to run newly downloaded applications that aren’t from the Mac App Store or signed with a Developer ID unless you jump through a few extra hoops.
Are most developers using Developer IDs? — Not yet, but adoption is growing quickly, according to my sources at Apple. Major publishers like Adobe are issuing updates for their applications, and I know many of the smaller apps I use regularly have been updated with a Developer ID. If you’ve been following the updates we publish in the TidBITS Watchlist, you’ll notice that we’ve been mentioning when developers are signing their apps in order to support Gatekeeper.
How does restricting where my apps come from improve security? — Most users never change the defaults on their Macs. As we’ve already discussed, limiting which applications can launch to those that come from the Mac App Store means you’re getting only apps that are vetted by Apple. Many of those are also sandboxed; eventually all will be.
But, as we’ve also discussed, not all programs can meet the Mac App Store’s sandboxing requirements. Had Gatekeeper drawn a distinction between only those apps in the Mac App Store and those not in it, a large percentage of users would have opted for no restrictions, since it would have been too frustrating to deal with applications downloaded from other sources. The beauty of allowing Developer ID-signed apps to run by default is that we can still install most legitimate apps with no fuss, but Apple maintains control at a developer level rather than an application level.
Members of the Mac Developer Program (which costs $99 per year) can use their free Developer IDs to sign whatever they want, and Apple doesn’t review signed apps. However, should a signed app be discovered to be malicious, Apple can place that developer’s certificate on a blacklist and Gatekeeper will prevent additional users from installing any apps from that developer.
This technique could dramatically reduce the spread of malware. Even if a criminal manages to get, or steal, a Developer ID, the moment they are discovered and Apple blacklists that ID, the malware is prevented from spreading on any more Gatekeeper-enabled Macs.
Gatekeeper isn’t a perfect security control, and it isn’t meant to be. By focusing on widespread attacks Apple is reducing the economic viability of Mac malware spread by tricking users into installing bad things. Combine this with the increased hardening to reduce exploits of the Mac itself, and it becomes much more expensive to attack Macs.
(And yes, developers should seriously protect their Developer IDs, since if a Developer ID is stolen and used in malware, Apple’s blacklist would also apply to all legitimate software signed with that Developer ID, causing an immediate drop in sales and a serious reputation hit. Apple has a poor track record in working with developers to address problems, so I can imagine quite some time passing before such a situation could be resolved.)
What worries users and developers about these security technologies? — In a word, iOS, which shows both the benefits and the risks. We have never before seen these sorts of restrictions on our general-purpose Macs, but we have seen them in action in iOS, where there are notable limitations on what can be done (the lack of a centralized file system is a notable example) and where Apple has regularly misused its role as gatekeeper.
The limitations imposed by sandboxing have developers worried that they either won’t be able to innovate freely and exist within the Mac App Store’s sandboxing requirements, or that they won’t be able to reach a large enough market outside the Mac App Store to justify development costs. Developers are also worried that, as we’ve seen in the iOS App Store, the rules will change or that Apple simply won’t abide by them. There are multiple cases of Apple behaving capriciously, rejecting otherwise legitimate apps without reason. For developers to invest the significant time and money into development, the marketplace has to be run in a fair and aboveboard manner. Without consistent rules, markets can’t survive.
I’ve also talked with lots of developers and power users alike who worry that Apple wants complete control over what we run on our Macs. They worry that Apple will, in the future, mandate that everything go through the Mac App Store and be sandboxed, or that so much of the market will rely on the Mac App Store that there will be no way for software to survive outside of it. The concern is that the end result may be more safety for the average user, but at the cost of freedom — and advanced capabilities — for professional users.
I may love my iPad, but I equally love all the wonderful tools and tweaks of my Macs, many of which wouldn’t be possible in a completely sandboxed world.
I can’t predict the future, but my personal feeling is that the current team at Apple recognizes the differences between a general purpose computer and an iOS device. The fact that they created the Developer ID instead of merely using Gatekeeper to force the use of the Mac App Store is a sign that they want to balance freedom and safety. Apple has also expanded sandbox entitlements, although calling them “temporary” makes any company relying on them wonder when the rug will be pulled out.
If there is one thing I hope Apple learns if they read this article, it’s that users and developers may appreciate the safety of this strategy, but they very legitimately fear where we may be headed if Apple exercises too much control. Sandboxing and the Mac App Store are so interconnected that if sandboxing is perceived as a tool to control the overall user experience versus protecting users, it will negatively affect perceptions. Apple is big enough and powerful enough to do whatever it wants, but going to the logical extreme would be a harsh blow for those users most invested in the Macintosh way, to reference Guy Kawasaki’s first book (now available as a free
download).
While I don’t personally think that Apple wants the Mac to become as locked-down as an iOS device, we all need to admit it is a legitimate concern, considering how much of iOS has made its way into Lion and how much more is coming in Mountain Lion.
As someone who lives in the security world, I think Apple is moving in the right direction, albeit with room for improvement. These security technologies and techniques have proven effective in targeting the big picture problems, and I suspect Microsoft will need to adopt similar ecosystem approaches as they move into Windows 8 (which is already inherently quite secure). But I hope Apple recognizes why so many experienced users and developers are concerned, and some clearer communication might assuage at least a few of those fears.
I'd be interested in getting more feedback for my RB App Checker Lite application (available both from the Mac App Store and from http://brockerhoff.net/RB/AppCheckerLite).
It analyzes any application and shows the exact details of the signing certificates and the sandbox entitlements, and also checks if the app has been modified after signing.
While the current (free) version is more oriented towards developers who wish to check their own applications before publishing, I'm working on a non-lite version that will try to appraise a downloaded application and state the result in non-technical language.
I look forward to the consumer-level version, Rainier - I think some people will be interested in learning what their apps are like.
Hey, this is a very useful app for my Mac app tester's toolkit; I'll gladly pay for tools like this. I do wish it ran on 10.6, though.
What does this mean to apps like Office that store documents on a file server in a business or home environment? Everything can't be sandboxed or stored on a web server.
I think you make a good point - the more professional the app, the less likely it is to be able to be sandboxed.
And more concerning, as Jim notes below, the more prevalent the app, the more likely it will be targeted by the bad guys.
Well, there isn't really a limit to using a file server. That's what the temporary entitlement is for. Sandboxing can work with that criteria.
I'm a developer who is postponing sandboxing my app (Fetch). There are a couple Fetch features that may not be possible in the sandbox, but more importantly, adopting the sandbox can be a lot of work (especially for a program like Fetch that accesses files and the network), for little user benefit.
There are thousands of Mac developers like me, but we represent a small sliver of the Mac ecosystem's vulnerable "surface area". Sensible attackers will instead target the software that runs on most or all Macs: OS X, its bundled apps (e.g. Safari, Preview, Mail) and the most popular other components and apps (Flash, iLife, MS Office, Adobe CS).
Forcing thousands of small developers to sandbox their obscure apps while iTunes and MS Word remain un-sandboxed strikes me as a wrongheaded approach. It would be more efficient, and fairer, to phase in the requirement based on installed base. For example, the sandbox requirement could initially only apply to apps installed on millions of Macs.
I think you make an excellent point, Jim, and the companies that fall into this category - Microsoft, Adobe, and so on - are also the ones that are the least likely to care about the Mac App Store (since they sell directly or largely via site licenses), so the sandboxing requirement may not improve security all that much.
But at least we'll be safe from Angry Birds Russian Mafia Edition!
If you take a look at all the security advisories at Secunia you will see that smaller apps really are targeted. The more the big apps are hardened, the more attackers have to look for other opportunities.
And sandboxing is also to protect against malicious apps that will inevitably go into the store.
I love Fetch, and I wish Apple was better at leading by example, but I think this sandboxing model is going to become the norm to participate in any curated app marketplace. Microsoft is also making moves in the same direction.
It is clearly hard on developers, especially smaller shops, but there really is a lot of overall benefit the more apps that are sandboxed. Kind of a herd immunity. Also, some of the bundled apps (like Safari, QuickTime, and Preview) already have some or all of their code sandboxed.
> Forcing thousands of small developers to sandbox their obscure apps while iTunes and MS Word remain un-sandboxed strikes me as a wrongheaded approach.
I 'd like to agree with Jim but am concerned about the mentioned Secunia data showing the bad guys might be waiting to pounce. (:-(
As with other areas, e.g. interface guidelines, it's always frustrating to see Apple not wholesale practicing what they preach (general inconsistency, laziness).
TERRIFIC article, Rich. Thank you!
Apple is becoming Big Brother of 1984 commercial fame or like "The Outer Limits": "We control the vertical, we control the horizontal"
I have absolutely no plans to use the Mac App Store for my software purchases; I will just purchase boxed or directly from the vendor. Apple's next step will probably make Gatekeeper in 10.9 (house cat) to only allow apps from the store and those with developer IDs. Then in System 11 (Lap Dog) only Mac App Store purchases would be allowed.
The Mac will no longer be the computer for the "rest of us" and Mac users will no longer be allowed to "think different".
This is the slippery slope argument, and there really isn't any way I can respond. Anything can happen in the future.
All I can say is that as a security professional, this is a positive move for user safety. And Apple is showing they see the difference between a general purpose OS and the iPhone (shown by use of the Developer ID).
My gut feel is we aren't moving in that direction. But I could be wrong, and clearly nothing I can say will assuage the fears of people who think we are moving in the other direction.
I must say that I'm somewhat disappointed when you say you have no plans to use the MAS. (And what is this "boxed" you mention...? ;-) ).
As an indie developer, I welcome the MAS as a place which takes care of distribution and updates for me; indexes the available applications; and handles payments and so forth. The first two functions are especially nice for free apps. I also welcome the Developer ID for allowing me to publish identified apps outside the MAS.
Both my MAS certificate and my Developer ID certificate have the same team code, and I use branding and the certificates to establish a consistent identity in both channels that my users can trust.
I do have software in the works that doesn't fit into the MAS guidelines, but it will expand upon my MAS apps; so users will be able to install whatever combination they need and feel comfortable with.
What Apple doesn't do well - yet - is identify the developer in detail for the casual user.
I think you missed one of the major impacts of Gatekeeper, no more open-source software. How is a sourceforge project going to use a DeveloperID? It's just another example of the Apple concept that only Big Business can write secure software. Too bad, the legacy of Mac development is filled with examples where individuals brought the most innovative products to market. Now Apple wants to lock in its "AppStore skims every transaction" business model, under the guise of security. I didn't expect TidBITS to go along with them. Giving up innovation can't be the cost of Mac popularity, or we'll all be looking for the next visionary company.
But Gatekeeper doesn't prevent users from installing those apps. You just need to command/right-click and then open. Also Gatekeeper doesn't monitor any package management systems like MacPorts... all that will install without hitting it.
I disagree with the premise that Apple is doing this to skim everything. If so, they wouldn't have come up with the Developer ID and brought in some indie developers to review it before they made it public.
Could that change? Certainly. But at this point I'm inclined to give them the benefit of the doubt based on how they've handled it so far and the conversations I've had with them.
I think open source software projects will need to figure this out, Randy. My suspicion is that every open source project has at least one and probably many programmers who are Apple developers, since it's not particularly expensive to become one ($99 per year) so it shouldn't be impossible for someone to get the necessary Developer ID.
Also, while I'm no fan of the Mac App Store and its policies, I really don't think Apple is doing it as a profit center - they make their money selling hardware and always have. Rich and I disagree a bit on this, but I think Apple really wants a lot of control over the user experience and the Mac App Store is part of that control freakiness.
Well, any profits from the Mac App Store may well be small potatos compared to profits from Apple's hardware. But I can't help but wonder why Apple provided no upgrade path to the Store for the several apps I already own; purchased directly from the developers. I was supposed to buy them at full cost a second time just to get the "benefits" of the Mac App Store. And so Apple could get its 30%.
I can't predict the future any better than anyone else, but I don't like the feeling I get from the App Store, Gatekeeper, etc. The potential is certainly there for Apple to make the Mac a closed platform, entirely (modulo jailbreaking) under Apple's control.
So I just spent a couple of months converting from OS X to Ubuntu Linux. It's actually a decent platform, the price is right(!), and likely will remain "open". I still need iTunes to sync my iPad & iTouch, but beyond that I'm on Linux and liking it just fine.
Again, I really don't think Apple has prevented the concept of reduced price upgrades so they can skim a few more cents from developers - it's simply a concept they don't seem willing to bring to the App Store or the Mac App Store. They want upgrades to be free because it's friendly for users, but that's of course untenable for most developers (who have to invest in coding the upgrades), or results in a lot of software being abandoned.
OK.
I don't mean to start a back-and-forth here. I just want to point out that, for me personally, the potential closed platform issue is much more important than the Mac App Store profits issue.
I'm not sure that open source software licenses would be compatible with the fact that the Developer ID must be kept secret.
A good question, and I'm not enough of a lawyer or familiar enough with open source release processes or how the Developer ID is integrated to know. If the Developer ID has to be integrated into the source that anyone would have access to, that would be potentially problematic, whereas if it's part of the final release package process, it could be maintained by a single person and kept out of the code.
I'm not familiar with Apple's Developer ID specifically but in the general concept of signed binaries this is not a problem. Signing doesn't so much say "I wrote this" but rather "I compiled this." If you download the source for ProgramX and compile it instead of downloading a binary of ProgramX from the project maintainers, your copy of the program will not be signed because you're not one of the heads of that project. But you could sign anything you compile with your *own* ID.
It's possible to sign anything, including source code, using programs like PGP (and GPG) but very few bother. Instead, they'll post a hash (usually MD5 or SHA1) on their web site that corresponds to a .tar or .zip file containing the source code. If you trust that only the project maintainers can change their web site content, then you can download the .zip file from anywhere and compare a hash of it with the one posted on the web site to be sure that it's safe.
Thanks for the link to the PDF version of The Macintosh Way, but it's text is so absurdly blurry it's too painful to actually read for more than a few seconds. Is there a non-broken version somewhere?
OSX 10.6.8, Preview, zero problems with other PDFs.
Why is my nick the first part of my email address, and not the name I gave in the "Name" field? :-( Not good...
You can change the name that appears. It should have been what appeared in the Name field! Just hover over your name in any of your comments, click it when it highlights in yellow, and then you can enter the correct name. Sorry!
Nope, says "Cannot change name"
Ok, works now using Camino in OSX 10.5.8, but not the other day with Opera in WinXP where I just got the "cannot change name" error.
Regarding the PDF - anyone know why only this specific PDF's text is terribly blurry?
Just tried downloading The Macintosh Way PDF on another Mac, this one running OSX 10.5.8 - same result - terribly blurry painful to read text :-( It would seem to be the PDF that is broken.
Try this one: https://dl.dropbox.com/u/1933893/The%20Macintosh%20Way.pdf
Ley us know how this one looks.
Yes, this is less blurry, but still I don't think I will be able to read it. It's as if it's still slightly out of focus, and the pale faded colour doesn't help matters. I suppose I could copy and past the text into a text editor, but it's going to still be annoying to read with all the illustrations referred to in the text.
I'm not sure why Guy released such poor versions of his old book. Perhaps this was all he had left, or it's a very poor scan and OCR or import from another format. It's a shame :-(
BTW, I asked about this ebook's blurriness here (ignore the arguing *sighs over Usenet* and focus on the few useful posts): https://groups.google.com/d/topic/comp.sys.mac.apps/Y-sOuHthwfo/discussion
I checked my print copy and it must be a bad scan, since my original has very white pages and crisp black text.
I will admit - we test nothing in Opera under Windows XP. :-)
Actually I was mistaken - I was in OSX by the time I tried posting here above. So this problem did happen under OSX, Camino and Safari.
I've seen these misconception tens, or possibly hudreds of times:
1) EDIT: Apparently app signing to target GK does indeed require a 99/yr Mac Developer acct...Oops
2) Apple has put a _ton_ of work in to make sure that GateKeeper meets the needs of non MAS apps. If they were going to turn around and require that 10.9 only allowed MAS apps, they would have put a hell of a lot less effort into this.
3) As a user of many programs (and also a researcher/programmer myself), I can say that more people appreciate extra security more than is easily quantifiable. And I really do hope that Apple adds sandboxing to as many of it's own apps as possible.
4) Open source projects CAN use Developer ID. There are already several projects using this, most prominent in my mind is Adium (adium.im) which has 1.5.1 already signed and ready to go for GateKeeper.
5) I might be crazy, but as easy as it is to see a future of MAS only apps on OSX, it's just as easy to say that GateKeeper could come to iOS.
Hey Dave, can you point me to a page that talks about getting a Developer ID without needing a $99 developer account? It seems to be implied that that's necessary at this page.
https://developer.apple.com/resources/developer-id/
It's good to hear that open source projects can use Gatekeeper - can you address the questions about the license and where in the process the Developer ID is used?
And lastly, although I'd love for you to be right about Gatekeeper coming to iOS in such a way that would enable apps to be sold or even given away for free outside the App Store, I'd be utterly shocked if Apple made that happen.
I agree that this is confusing. The link you provided only talks about getting a Developer ID from Apple by joining the Mac Developer Program (which costs $99).
In their Code Signing Guide under Code Signing Tasks > Obtaining a Signing Identity, they mention both 3rd party signing identities and generating certificates using Keychain's Certificate Assistant.
https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html
However, it doesn't say anything about Gatekeeper or the Mac App Store. I'm guessing the Mac App Store requires you to use an Apple issued Developer ID but you already have to be in the Mac Developer Program to submit, right? From what I've read, by default Gatekeeper will only recognize Apple's Developer ID signatures which implies that other signatures would require the user to change Gatekeeper, perhaps by manually adding another signing authority, not easy for the average user.
Looking further, I don't think Gatekeeper is meant to allow you to verify anything other signatures from Apple Developer IDs.
Hm. Good question. I'm uncertain as to the actual process. I would assume you sign up for a free Mac developer account, and then from there either enroll in developer ID, or perhaps it's already available (check the member center once your account is established if you cant find anything else, upper right corner)...and report back :)
As far as licenses and open source, yes it's true some open source licenses might prevent codesigning, but I think there are far fewer of those than prohibit distribution through the MAS.
GK for iOS would be a long shot...but really, so would be requiring MAS only distribution.
I have a free account on developer.apple.com. I think the information at the link Adam provided is accurate and says you have to be in the non-free Mac Developer Program to get an Apple Developer ID.
From what I've gleaned, OS X since 10.5 has had a signed code security feature (which Adium, since you mentioned it, has used). From what I can tell, if you have a signed program already installed (how it's signed isn't important) and something alters its code on your hard drive, OS X can warn you. The feature doesn't help with checking the legitimacy of a new program you've downloaded or if the entirety of a signed program is replaced.
I've heard from multiple reliable sources that the term "free" has been tossed around on a number of occasions. I'll have to look into it. Seems odd that certificates for OSX apps would be non-free, when as far as I know, the same type of certificate is given away for the safari extension developer program.
Hm. This is sad, but I may have misunderstood what a few people told me before which was that developer ID was free to mac developers...apparently they meant you can have an unlimited number of certificates free in addition to paying 99/year for a paid account. I assumed they were referring to the free mac developer account, but apparently it was with regards to the paid account. That's a little depressing.
So, apologies for saying it was free, and getting your hopes up, apparently I was mistaken on that...the rest of what I said still stands though, but that's still a pretty big error on my part :/
Yes, code signing in general was introduced in 10.5. codesigning was used to ensure that across updates, authorization to the keychain could remain in tact without constantly bugging the user. I'm not sure it was good for much else other than letting you see that an installer had been signed by someone.
Adium and a few other open source apps are already signed for GK as well though, here's the snip of the Adium 1.5.1 release notes:
Version 1.5.1 (6/7/2012):
Adium is now securely signed with an Apple Developer ID for OS X 10.8 / GateKeeper compatibility.
xquartz (xquartz.macosforge.org -- which is an apple supported open source project though) is also already signed with developer ID. I knew there was another one I had seen recently that I couldn't think of.
But I guess if it's not free to do Developer ID, maybe not as many developers will jump on this as I was hoping, but time will tell.
After reading through this whole article and the comments, I'm a bit miffed that the Developer ID is stated as being free several times. While it is free to members of the Apple Developer program, that program costs $99 per year, ergo the Developer ID is not free.
I realize Apple isn't implementing Gatekeeper for the $99 per year from developers, but it does muddy the waters somewhat..
Somewhat, perhaps, but for the level we're talking about here - innovative apps that can drive the platform forward - it's hard to see such software coming from any developer who can't or won't pay $99 to be part of the developer program.
But this puts the teenage hobbyist out a bit. I just don't like "free" being bandied about. Its factually incorrect.
Fair enough - I've tweaked the text just slightly to clarify that the Developer IDs are free only to those who are members of the Mac Developer Program. It is important to note that they're free to people who are already in the program - there's no additional charge.
But it is absolutely true that you can get Xcode completely for free, but not a Gatekeeper Developer ID completely for free.
Thanks, my inner stickler appreciates it. :-D