On Phil Schiller’s credibility

John Gruber today posts a letter from Phil Schiller, senior vice president at Apple, regarding the company’s recent decision to reject a dictionary app from the App Store because it contained “vulgar” words. Gruber has been understandably indignant about the matter, and the resulting publicity is making Apple look bad, so the company is (also understandably) out to do some damage control.

Without getting into the whole thing, Schiller says Apple did not ask the developers of the dictionary application (based on Wiktionary, which Schiller consistently misspelled) to censor their product; Apple only said that until parental ratings were available so such vulgar words could be restricted to “17+” purchasers, the app could not contain the vulgar words. The developers had no idea when iPhone OS 3.0 with Parental Controls would ship, so their choice was “wait for an unknown amount of time or censor the dictionary and ship it now.” They chose the latter. They might have chosen the former if Apple had provided any specifics about release dates before WWDC, but that’s another story.

Gruber writes that “after going back to Ninjawords’s developers and conferring with some trusted sources within Apple, I believe what Schiller says here is genuinely the case,” and later adds, “I believe Phil Schiller that Apple’s policy is not to reject App Store dictionaries for containing swear words.” Gruber then goes on to point out several clear examples of how “this policy has not been consistently enforced.”

We would take one further step back and remind readers that, in MDJ‘s view, Schiller does not deserve the benefit of the doubt because in the past, when Apple faced embarrassing press coverage over its own stupid actions, Schiller went to the press and said things that he either knew were not true, or should have known were not true.

We last reviewed this story in MDJ 2008.10.14, from whence the following excerpt originates:

To understand what’s going on, you should restart the WABAC machine and travel to the previous leap year. Until mid-2004, Apple’s security update policy was even worse than it is now. Security Updates included huge numbers of components not even mentioned in the release notes. For example, from reading the notes for Security Update 2004-05-03, you’d never know that this update included changes to Mail for the then-current Mac OS X 10.3.3, or that the Mac OS X 10.2.8 version included undocumented changes to Safari, Directory Access, Classic, the ISO 9660 filesystem, Web Kit, OpenSSL, Rendezvous (now known as Bonjour), and more. (MDJ 2004.05.05) Some of these were probably part of previous security updates that Apple “incorporated,” but it didn’t say so.

That 2004 release was just the latest of a long line of poorly documented Security Updates, but the fortress around security information rapidly crumbled. Security Update 2004-05-03 included a fix for an AppleShare problem, credited to “Dave G. from @stake,” that Apple said only “improve[d] the handling of long passwords.” However, @stake itself (purchased last year by Symantec) advised the world that this “long password” issue was in fact a buffer overflow concerning password handling, one that allowed attackers to execute code with root permissions. It wasn’t theoretical, either: @stake told MDJ that the firm had developed an exploit that allowed them to run code as root on any system with the buggy version of AppleShare. Apple, for its part, refused to admit there were any root exploits.

Shortly before this, Apple released QuickTime 6.5.1, fixing a bug that Apple described as a simple crasher: “Playing a malformed .mov (movie) file could cause QuickTime to terminate.” The company that originally reported the vulnerability to Apple, eEye Digital Security, then told CNET News that the bug was more serious and allowed attackers to hide executable code in a movie file.

Later in May, everything fell apart for Apple. Vulnerabilities in URL scheme mapping allowed malicious Web sites to remotely mount a disk image on your computer, so an attacker that induced you to visit a bad Web page could mount a disk on your computer, either by mounting it directly from a remote server or by forcing Safari to download a “.dmg“ file that, using Safari’s default settings, would then mount locally. A companion vulnerability in Help Viewer allowed the attacker to use a URL to force Help Viewer to open a system AppleScript that could then open any file—including an application on the malicious disk image. Just like that, attackers could make Safari launch a malicious program on your system (MDJ 2004.05.21).

Apple closed the Help Viewer vulnerability a few days later (MDJ 2004.05.24), but as people examined the custom URL scheme handling, it became more and more clear that it was just far too easy for attackers to use malicious URL schemes to open programs without your permission, or mount disk images, or execute command-line programs, or worse.

But if Apple’s dishonest documentation was unnerving, the next round of revelations was infuriating. The URL scheme bug and the Help Viewer bug had been reported to Apple three months beforehand, in February 2004. The German developer who reported the issues had Web server logs showing that Apple-owned IP addresses visited his test site to reproduce the issue in February, and then Apple buried it. The company released three separate Security Updates after the vulnerability was reported and before the developer went public with it—a move he had told Apple well in advance he would make if the company had not fixed the vulnerability within three months. Not only did Apple not fix the bugs, Apple did not even respond to the developer, despite his repeated urgent messages about the problem.

After he went public, the very next Security Update fixed the Help Viewer bug (MDJ 2005.05.25), but the next week saw Mac OS X 10.3.4 released without the Help Viewer fix included. Apple’s earlier fix in Security Update 2004-05-25 strongly suggested that Apple had no intention of fixing the Help Viewer vulnerability until it went public, because the fixed version was not baked into the OS update. (MDJ 2004.06.02) It took another week, with Security Update 2004-06-07, for Apple to rush out the beginning of “Download Validation” and quarantining that introduced the concept of “safe” files and warning you when opening newly downloaded files. (MDJ 2004.06.08)

By this point, the mess in the technical and business press about Apple’s huge security holes had real consequences. Security Update 2004-06-07 was the first one documented in the “modern” style, where every top-level component is mentioned with specific (and accurate, to the best of anyone’s knowledge) descriptions—no more including mystery fixes to components that weren’t even supposed to be in the update. In the next calendar year, Apple adopted the sequential yearly numbering of Security Updates, starting with Security Update 2005-001.

But Apple saw that there had been damage done, and rather than fess up to it, the company sent executives to the press to speak falsely about the issues. Phil Schiller, then as now a senior vice-president of Apple, told Macworld on 2004.06.07 that the risks of these vulnerabilities “are still in the realm of potential risks, not actual risks.” As MDJ said at the time, Schiller’s remark is the same as saying that a bomb is not a weapon until it explodes—transparently ridiculous.

Schiller also told CNET News that week that the February bug report “was only a small piece of the picture and didn’t present as great a threat,” and that “the complete picture of this current threat has actually been very recent. That, too, was demonstrably false: the developer explained the entire vulnerability in his February bug report, as he said in his public online warning and later confirmed to Wired’s Leander Kahney. MDJ has cautioned readers ever since about trusting any technical pronouncement from Schiller: the chronology makes it quite likely that Schiller knew at the time that his statements were false (MDJ 2004.06.08).

We do not offer an opinion as to whether Schiller is being truthful in the App Store censorship matter. We only point out that his past statements when Apple was under fire mean that he does not get the benefit of our doubt. If Apple’s policy truly is not to censor applications for “including references to common swear words” (or ask their developers to do so to gain approval, either explicitly or implicitly), we’ll see the results in the App Store, and Schiller will have won back some credibility.

If he is dissembling, we’ll continue to hear stories from developers whose software was rejected because of such references, and it will be clear to anyone paying attention that Schiller’s press statements about how Apple didn’t do awful or stupid things simply cannot be trusted.

We’re willing to entertain the idea that Schiller’s telling the truth. We’re just not assuming he is.