No TidBITS Issue 31-May-04 — After this week’s extra-long TidBITS issue, we’re taking a week off for the U.S. Memorial Day holiday, which coincides with Managing Editor Jeff Carlson’s birthday celebrations and the days I’ll be spending at the MacDesign conference. TidBITS Talk should continue unabated, and watch our home page for breaking news that can’t wait (although we’re hoping for a couple boring weeks). We’ll return with the 07-Jun-04 issue. [ACE]

<http://www.macdesignconference.com/>

<http://www.tidbits.com/>

Microsoft Office 2004 Ships — Microsoft has officially released Office 2004 for Mac OS X, a significant revision to the near-ubiquitous suite of productivity tools. We plan to look more closely at the changes in Word, Entourage, Excel, and PowerPoint once we’ve received the software and evaluated whether the new features and fixed bugs in the final versions of each program are worthwhile. For now, suffice to say that you can purchase it for $400 (list price) or $150 (educational); upgrades cost $240. Individual products are also available if you don’t want the full suite. You can also download a test drive version (186 MB) that works for 30 days, but keep in mind that Office 2004 requires Mac OS X 10.2.8 or higher. [TJE]

<http://www.microsoft.com/mac/products/ office2004/office2004.aspx>

<http://www.microsoft.com/mac/products/ office2004/howtobuy/howtobuy.aspx>

<http://www.microsoft.com/mac/default.aspx? pid=office2004td>

SubEthaEdit 2.0 Refines Collaboration — The Coding Monkeys have released version 2.0 of SubEthaEdit, their unique real-time collaborative text editor. This release adds several editing features such as regular expression-based search and replace, text auto-completion, a split-window view, conversion of line endings, and read-only access. It also enables you to invite other people on your local network to your shared document using Rendezvous. Developer-friendly features include AppleScript and ActionScript syntax highlighting, and per-mode preferences. SubEthaEdit 2.0 is not compatible with version 1.0, so each collaborator must be running the latest version to share documents. The program is a 1.2 MB download, and is free for non-commercial use; a commercial license costs $35. [JLC]

<http://www.codingmonkeys.de/subethaedit/>

Apple Creates New iPod Division — Highlighting the importance of its digital music player to Apple’s bottom line, the company has formed a separate iPod division headed up by Vice President Jon Rubinstein, who previously ran Apple’s hardware engineering. A separate Macintosh division has also been created, with Tim Cook, head of worldwide sales and operations, at its helm. Some pundits have tried to make much of this move, but to us, it sounds like standard corporate restructuring to reflect the reality of Apple’s markets. [JLC]

<http://www.reuters.com/newsArticle.jhtml? type=topNews&storyID=5198496>

Like most people who use Apple Mail, I had high hopes that its improved Junk Mail filter, a much-touted benefit of upgrading to Panther, would live up to Apple’s hype. After months of diligently training the filter, I was still less than satisfied with its results. Based on the hundreds of messages I’ve read on Apple’s discussion forums, my experience is not unique. Rather than live with the spam, though (or trade Mail for another application), I decided to look into the problem more deeply. Armed with an ever-increasing personal collection of many thousands of spam messages, I experimented with Mail’s Junk Mail settings, compared it with other filters, and tried to discover how it really works – and why it sometimes fails. I discovered that at least some of the problems I’d been having were due to a misunderstanding of the application’s design, which is not as self-explanatory as some of Apple’s applications.

I have some good news and some bad news. The good news is that Mail’s Junk Mail filter, when properly configured, can be a reliable tool for keeping spam out of your In box. The bad news is that even if the Junk Mail filter is working as well as it possibly can, you may still see more spam than you would like. Luckily, other applications and techniques can make up for the Junk Mail filter’s deficiencies. You’ll be able to make better decisions about how to use (or supplement) the Junk Mail filter when you know what happens behind the scenes.

I’ve distilled innumerable hours of research and experimentation into my latest Take Control ebook, "Take Control of Spam with Apple Mail," from which this article is excerpted.

<http://www.tidbits.com/takecontrol/spam-Apple- Mail.html>

How Mail’s Junk Mail Filter Works — Mail’s Junk Mail filter has two modes: Training and Automatic. (You can also disable it entirely.) Exactly what happens in these two modes can confuse the uninitiated. In particular, many people wonder whether the filter continues to learn if you switch to the Automatic mode. (It does indeed, though Apple’s documentation obscures this fact.) Here are the details.

When a message arrives, Mail runs a built-in rule – a rule that does not appear in the Rules list. In order to minimize false positives, this special junk mail rule runs after all other rules. But it doesn’t run if one of your other rules includes the "Stop evaluating rules" action, and it applies only if a given message has not already been moved or deleted by some other rule.

You can see the special junk rule by opening the Junk Mail preference pane and clicking the Advanced button at the bottom of the window. Depending on the options you choose, this rule optionally checks to see whether the message’s sender is in your Previous Recipients list or your Address Book, and whether the To field of the message contains your full name – since spam often does not. (The Previous Recipients list is a useful adjunct to the Junk Mail filter, although as I explain in detail in the ebook, incorrect data can easily creep into it, rendering it counter-productive.) If the answer to any of these questions is yes, the rule stops and your message is left alone. If all three conditions are negative, though, it checks one final condition: "Message is junk mail." If this final condition is true, the filter takes the action you specify: in Training mode, it changes the color of the message subject to Brown; in Automatic mode, it moves the message to your Junk mailbox. (This action is one of only two differences between Training mode and Automatic mode. The other is that in Automatic mode, Mail consolidates the Junk mailboxes for all of your accounts under a single Junk icon in the Mailbox list.)

The "Message is junk mail" condition sounds rather mysterious, but it means that, if true, Mail’s latent semantic analysis filter (discussed just ahead) has assigned the message a value beyond its arbitrary threshold for spam. You cannot modify this threshold, but if you later mark the message as Not Junk, you decrease the probability that Mail will consider a similar message to be spam in the future.

The Panther version of Mail added yet another criterion for spam checking: headers inserted by a spam filter running on your ISP’s mail server. Many ISPs use server-based spam filters such as SpamAssassin or Brightmail. If such a filter identifies a message as potentially spam, it tags it by adding to the message a special header, such as X-Spam-Flag. (These special headers are normally hidden, but you can display them by choosing View > Message > Long Headers [Command-Shift-H].)

If a message contains this header, this means your ISP’s spam filter – which may be more advanced than the one built into Mail – suspects the message to be spam. As long as the checkbox Trust Junk Mail Headers Set by Your Internet Service Provider is selected in Junk Mail preferences, Mail marks such messages as Junk Mail (unless they were exempted for some other reason, such as being sent by someone in your Address Book). Some server-side spam filters use other headers besides X-Spam-Flag to identify spam. The only way to tell Mail to look for a different header is to edit its preference file manually; I give full instructions in the ebook.

About Statistical Filtering — Because of the constantly evolving nature of spam, tools that attempt to filter out messages based on a fixed list of keywords, patterns, or rules become less effective as time goes on. Statistical filters address this problem by making up their own rules (in a sense) as they process your mail. The most frequently used statistical spam-filtering method is Bayesian filtering (found in Eudora, SpamSieve, and SpamAssassin, among others).

Apple Mail uses a related technique known as Adaptive Latent Semantic Analysis (LSA). Both methods compute the probability of a given message being spam based on an analysis of the contents of existing spam and non-spam messages. And both methods become more accurate as they are exposed to new samples of good and bad messages. Although from a user’s perspective Bayesian and LSA filters are similar, they differ in some important ways.

Bayesian Filters — To oversimplify tremendously, think of a Bayesian filter as consisting primarily of two lists: "good" words and "bad" words. You build these lists dynamically as you use the filter. Every time you indicate that a message is spam, the filter adds all the words in that message to its Bad Words list; every time you indicate that a message is legitimate, all its words go onto the Good Words list. Of course, most words appear on both lists, so the filter determines the probability that each word is a spam indicator based on the proportion of times it appeared in bad versus good messages.

When a new message comes in, the filter calculates the average spam score of its words, and if that score exceeds a predetermined threshold, the message is deemed to be spam. Bayesian filters are highly dynamic, adapting themselves not only to the type of mail each individual receives (since one person’s spam is another’s ham) but also to the changing tactics of spammers. Although the system is not perfect, it means that if next month a new scam emerges for selling real estate on Mars, a Bayesian filter will learn to reject such messages after you manually mark a few examples as spam. Most Bayesian filters also take into account email headers and other message attributes in order to avoid being fooled by spam messages containing long (but often hidden) passages of ordinary prose.

Latent Semantic Analysis in Mail — Where Bayesian filters are based on a relatively straightforward computation of word frequency, LSA filters go further by identifying spam-like words, phrases, and messages based on their similarity in meaning to text you’ve already identified as spam. Instead of assigning simple weights to each word individually, an LSA filter takes into account the overall context in which a word appears. For example, the word "enlargement," when it appears in a discussion about photography, would not normally be an indicator of spam – whereas the same word in the context of cosmetic surgery or low-cost prescription medicine would be a very good indicator of spam. (Again, this is an oversimplification. For more details on latent semantic analysis, see part 2 of Francois Joseph de Kermadec’s three-part series "The Fight Against Spam" at MacDevCenter.)

<http://www.macdevcenter.com/pub/a/mac/2004/05/ 18/spam_pt2.html>

Like a Bayesian filter, an LSA filter keeps learning as you use it. This assumes, of course, that you diligently correct all its mistakes. In Mail, this means marking all spam messages the filter misses as Junk Mail, and marking all incorrectly identified legitimate messages as Not Junk Mail.

On paper, LSA seems to be a more sophisticated technique that is less likely to be foiled by clever spammers. In practice, however, Mail’s implementation of LSA leaves something to be desired. In my own tests, it learned more slowly than Bayesian filters. It also tends to err on the cautious side, with no way to adjust its threshold for what it considers spam. And because it looks for patterns of words rather than patterns of characters, lots of seemingly obvious spam messages get through undetected.

Mail stores its statistics of good and bad message characteristics in a single file: ~/Library/Mail/LSMMap2. (LSM, by the way, stands for "least square method," a mathematical algorithm used in latent semantic analysis. I could tell you were wondering about that.) If this file becomes damaged – which unfortunately can happen pretty easily – junk mail filtering stops working correctly.

You can’t repair the LSMMap2 file, but you can delete it manually or reset it by clicking a button on Mail’s Junk Mail preference pane. Doing so solves the most serious junk mail problems, but also eliminates all the training you have given your junk mail filter, so its accuracy will probably be poor until it has processed enough new legitimate and spam messages to rebuild its database.

What can damage Mail’s junk statistics file in the first place? In addition to the usual things (such as crashes while the file is open, directory errors, or shutting down improperly), LSMMap2 can occasionally suffer damage in the course of ordinary activities such as filing a message or marking it as Junk Mail, if the message itself contains certain kinds of errors. Although you can’t prevent damage from occurring, you can take steps to make recovery easier (see the ebook for more information).

Marking a Message as Junk Mail/Not Junk Mail — Because statistical filters increase their accuracy gradually as you use them (and because spammers constantly learn new tricks to thwart them), spam sometimes gets past the Junk Mail filter and appears to be ordinary mail. (This is known in the lingo as a "false negative.") You could just delete such messages, but if you do, you actually increase the probability that similar messages will sneak through in the future. Instead, you must select each unmarked spam and manually mark it as Junk Mail (choose Message > Mark > As Junk Mail [Command-Shift-J]).

Note that merely moving a message to your Junk mailbox is not enough; only if the Junk Mail flag is set, as shown by the "paper bag" icon in the message list, does Mail consider the message junk mail. When you mark a message as Junk Mail, you modify the filter’s statistical lists and remove the sender’s address from the Previous Recipients list if it was there.

Conversely, Mail may incorrectly mark a legitimate message as Junk (a "false positive"). After all, statistical filters only judge probabilities. If someone sent you, say, an article discussing the sorts of words that spammers often use, that might tip the scales. (This problem of overzealous spam filters has caused no end of problems for TidBITS and the TidBITS Talk mailing list.) So you must always mark such messages as Not Junk (choose Message > Mark > As Not Junk Mail) to tell Mail they are legitimate.

Surprisingly, though, marking a message as Not Junk also adds the message’s Sender to your Previous Recipients list! This guarantees that no message from that sender will be marked as spam in the future (assuming you use the default settings), which may or may not be what you want. This is just one of many surprises I encountered with the design of the Previous Recipients list.

Take Control of Spam with Apple Mail — I’ve tried to explain the basics of how Mail’s Junk Mail filter works here, but in my full 59-page "Take Control of Spam with Apple Mail" ebook, I go much further, providing detailed, practical steps Mail users can take to eliminate spam, prevent false positives, and solve problems with the Junk Mail filter. The ebook includes a great deal of additional background information, plus extensive discussions of add-on filters and other techniques that go beyond Mail’s built-in anti-spam capabilities. If you’ve been suffering from spam in Mail, I’m confident my advice will reduce your frustration level and help you avoid wasting so much time dealing with junk mail. "Take Control of Spam with Apple Mail" costs $5, and as with all Take Control ebooks, purchasers are entitled to receive all minor updates for free.

<http://www.tidbits.com/takecontrol/spam-Apple- Mail.html>

[Joe Kissell is a San Francisco-based writer, consultant, and Mac developer who kicked off the Take Control series with the best-selling "Take Control of Upgrading to Panther." His Interesting Thing of the Day Web site returns with daily articles beginning 01-Jun-04.]

<http://www.tidbits.com/takecontrol/panther/ upgrading.html>

<http://itotd.com/>

A year or so ago, I realized that LCD monitors were coming down in price sufficiently that it would be feasible to mount one on a wall and use it to display photos and other digital art. It turns out I wasn’t alone in this, and Alan Oppenheimer of Open Door Networks had wanted to do much the same thing. Alan was responsible for the creation of AppleTalk while at Apple, and since leaving the company, Open Door has released a variety of network-related programs including ShareWay IP (which enabled Personal File Sharing to work over IP instead of just AppleTalk), a personal firewall called DoorStop that Symantec bought and turned into Norton Personal Firewall, another utility for better understanding and reacting to access attempts detected by your firewall, and several server log analysis programs.

I say all that by way of showing how Open Door’s latest program – currently available for free as a public beta – is a bit of a departure from the world of geeky network and security software. Envision is essentially an Internet-based slideshow program that Alan and his team started writing to display images from the Astronomy Picture of the Day archive on an old iBook. You point Envision at a Web site that offers public access to its images, and the program goes out, finds the image URLs, and downloads the pictures that meet your criteria for size, name, and so on. (Envision comes with a selection of pre-defined slideshows for museums, currency, comics, and much more.) As soon as it has downloaded images that match, it starts displaying them in a simple slideshow, moving from image to image on user-defined timing.

<http://www.opendoor.com/envision/>

<http://antwrp.gsfc.nasa.gov/apod/astropix.html>

Envision is an intriguing program for browsing the Web visually without constant clicking, and I felt it was worth covering even in its public beta phase because Open Door is extremely interested in feedback from users about how Envision should be focused and what it needs to do better. There’s no question that Envision’s current capabilities are somewhat limited, sometimes intentionally so: it won’t crawl past the top level of sites other than the one it starts on, and it fails with sites that use tricks like weird redirects or JavaScript pop-up windows to prevent people from viewing images too quickly. I also prefer Mac OS X’s photo screen saver, with its panning and zooming effects, for displaying photos; luckily you can drag photos out of Envision’s thumbnail view to save them to disk if you want to feed them to Mac OS X’s screen saver. It’s likely a future version of Envision will have an option to save images to specific folders for immediate use with Mac OS X’s screen saver.

There’s also no question that Envision will be controversial. The prurient will undoubtedly use it to download and display naughty pictures, but of course, that was equally as possible with a normal Web browser. Some webmasters will be upset that their banner ads aren’t displayed along with the images, but again, there are Web browsers and other utilities that can prevent banner ads from loading. And designers and site authors will likely express dismay that users won’t see their images in context and with any supporting text. That said, double-clicking a photo immediately takes you to its original Web page, and Envision can optionally show each picture’s URL, a link to the original site, and its caption in an Info pane. (The caption – created from the image’s ALT tag – can optionally appear over the image itself in Envision.) Who knows, perhaps someday webmasters will even start to make slight coding changes for Envision so their sites can more easily be displayed on what’s essentially a large digital picture frame.

<http://www.opendoor.com/envision/ envisionWebmaster.html>

Despite Envision’s somewhat rough status, I’ve started watching the dealnews postings for cheap LCD monitors and thinking about where and how I’d mount such a monitor for displaying not just the thousands of digital photos I’ve taken, but also images from Envision. I think I’ll start with some of those amazing space pictures from NASA.

<http://www.dealnews.com/>

It’s not a Trojan horse, but a recently revealed security vulnerability does appear to be a very real concern. The exploit relies on unsafe actions that Apple allows for certain URL schemes (such as the http, ftp, or mailto bit at the beginning of a URL) and makes it possible for a malicious code to be delivered and executed silently, without the user realizing anything has happened.

The problem was initially thought to revolve around only two of these URL schemes: disk and help. When you combine the capability to download and automatically mount a disk image (which could contain a malicious AppleScript script) and the capability to run that AppleScript (because it’s in a known location) via Help Viewer, you end up with a recipe for trouble. Turning off Safari’s Open "Safe" Files After Downloading option in its General preference pane isn’t sufficient protection (and the vulnerability is even present if you use some other Web browsers).

<http://secunia.com/advisories/11622/>

Apple responded within days, issuing Security Update 2004-05-24. Although Apple’s description was terse, as always, it appears that the security update installs a new version of Help Viewer that presumably eliminates that program’s capability to execute AppleScripts sent via help URLs. (The security update also included a fix to URL processing within Terminal for users of Mac OS X 10.2 Jaguar; again, Apple provided no details.)

Unfortunately for everyone involved, Apple’s fix was merely a band-aid on what now seems like a much more involved and deep-seated problem, which I’ll let Matt Neuburg explain separately elsewhere in this issue. Suffice to say, the concern over Help Viewer was merely a special case of the overall vulnerability, which revolves around an attacker being able to post a disk image containing a malicious application that registers a special URL scheme. When a user clicks the link (which would of course be obscured to look like something else), the disk image is downloaded, mounted, and the special URL scheme is registered with Mac OS X. The server providing the URL waits a short while (until the disk image is mounted and URL scheme registered) and then automatically redirects the user to another URL that uses the just-registered scheme. That subsequent URL tells Mac OS X to launch the malicious application. To quote from Maurice Sendak, "’And now,’ cried Max, ‘let the wild rumpus start!’" Kudos to TidBITS Talk reader Sander Tekelenburg for a coherent page explaining this process.

<http://secunia.com/advisories/11689/>

<http://www.euronet.nl/~tekelenb/playground/ security/URLschemes/>

<https://tidbits.com/getbits.acgi?tlkthrd=2233>

Without in any way detracting from the serious nature of this vulnerability, it’s important to clarify a few things. This is not a Trojan horse, it’s not a virus, and although several people have posted proofs-of-concept, I’m not aware of any reports of any actual malicious software that uses this technique.

I’m certain Apple is working furiously to come up with a fix; until they do, the best advice for normal users (other than to keep good backups!) seems to be to download and install Paranoid Android, a free utility developed by Unsanity. Once installed, Paranoid Android watches for unknown URL schemes and displays a warning dialog that lets you cancel the action before your Mac can be compromised. Unsanity and Jason Harris deserve significant credit for developing Paranoid Android and releasing it for free. To learn a bit more about how Paranoid Android works, read Jason’s white paper at the second link below.

<http://www.unsanity.com/haxies/pa/>

<http://www.unsanity.com/haxies/pa/whitepaper/>

Some people are bothered by the technique Paranoid Android (like Unsanity’s other Haxies) uses; my take is that you can either follow John Gruber’s advice on his Daring Fireball for eliminating the need for Paranoid Android or consider it a temporary solution until Apple releases a fix. John recommends using Rubicode’s RCDefaultApp utility to disable potentially dangerous default URL handlers. Others have also recommended using Objective Development’s Little Snitch to alert you to potentially harmful network behavior.

<http://daringfireball.net/2004/05/help_viewer_ security_update/>

<http://www.rubicode.com/Software/RCDefaultApp/>

<http://www.obdev.at/products/littlesnitch/>

It’s worth keeping in mind that any action you take with your computer is potentially unsafe; a bug in a totally legitimate program could cause as much havoc as malicious software. Although there’s no reason to become entirely paranoid, we recommend that you exercise reasonable caution when evaluating the sources of files you download and links you click. And the most important thing to remember is that regular backups that maintain multiple versions of changed files will help you recover from almost any disaster with minimal effort.

Lastly, although Apple is undoubtedly aware of the seriousness of the situation, it’s still a test by fire. After a somewhat rocky start, Apple’s security group seems to have done a good job of dealing with the relatively minor exploits so far, most of which revolved around the Unix tools bundled with Mac OS X. This, however, is a new thing, a Mac OS X-specific vulnerability that exists purely because of Apple’s design decisions. More concerning is that it wasn’t discovered inside Apple and fixed before anyone had a chance to discover it. That implies that Apple’s security group may be more reactive than proactive; I would have hoped that at least part of the job description of the security team would be to probe constantly at Mac OS X and Apple’s bundled applications for potential vulnerabilities.

Exactly what is it about Mac OS X that is responsible for the security vulnerability currently being discussed? The situation is a little confusing, and I may be muddling some of the details, but here’s my current understanding of the situation.

As you know, when you double-click a document in the Finder, the application that "owns" that document starts up and opens the document. For example, if you double-click a Word document, Word starts up. This requires that your computer have a notion of "types of document," and that it draw an ownership association between a particular document type and a particular application. Before Mac OS X, this association was performed by means of four-letter creator codes hidden in the meta-information for a file (the "desktop database"). But on Mac OS X, it’s done in a new way, by a part of the system called Launch Services. Apple documents the entire situation on this page of the developer documentation about Launch Services.

<http://developer.apple.com/documentation/Carbon /Conceptual/LaunchServicesConcepts/ LSCConcepts/chapter_2_section_4.html>

Here’s what to notice about what that Web page is saying. In addition to the old system of four-letter codes, Apple, in an attempt to improve cross-platform compatibility, added to the mix the notion of the file extension, a several-character code at the end of every filename that provides the clue as to what sort of document the file is. At the same time, Apple also introduced yet a third way of signifying a "document" type, namely by means of a URL scheme. An application can specify that it responds to certain schemes; it is then eligible to be messaged by the system when such a scheme is encountered.

I don’t quite know why Apple did this. Part of the reason may be that Apple seems to have a great deal of trouble making up its mind how to specify a file in general. In Cocoa, for example, a file may be specified either as a pathname or as a URL; on the whole, Mac OS X seems to be trying to break down the distinction between a file and a URL-in-general. This works nicely from one point of view, because it means that for the programmer the command to open a remote file via http is exactly the same as the command to open a text file on the same machine. In any case, though, the thing to understand is that under Mac OS X, a URL becomes a file specifier possessing the same status as a pathname.

There are various ways in which the system can become aware of an application, and of the fact that an application can respond to a scheme. As noted in the first paragraph of that document, this does not require that you launch the application; merely copying the file to your hard disk is sufficient. This seems like a sensible design decision, because after all, when you first receive a new application (Microsoft Word, for instance), you would not want there to be an arcane rule that says you must first open Word itself for the operating system to know what to do with the various .doc files included with the installation. You would prefer the user to be able to double-click a .doc file in the Finder and have Word open the file, even though Word has never run before on this machine.

So far, so good. But now, keeping all of that in mind, consider what happens when you’re browsing the Web in Safari and you click on a link. For example, when you click a mailto URL in a Web page, something needs to happen. Therefore, something needs to associate the mailto URL scheme with your default email client. Way back in the bad old days, Apple had no solution to this problem. But eventually a third-party solution called Internet Config appeared, and Apple later adopted it and built it into the Mac OS.

<https://tidbits.com/getbits.acgi?tbart=01718>

But a moment ago, you may recall, I said that any application can now simply declare that it "owns" a certain URL scheme, just as it can claim to "own" a certain document type. That point is reinforced by this page from Apple’s developer documentation.

<http://developer.apple.com/documentation/Carbon /Conceptual/LaunchServicesConcepts/ LSCIntro/chapter_1_section_1.html>

In other words, Apple has folded together in Mac OS X’s Launch Services two very different mechanisms from the classic Mac OS: the Desktop Manager (which pairs documents with applications) and Internet Config (which pairs URL schemes with applications). All of that sounds reasonable enough, since in both cases we are using something (a document or a URL scheme) to launch an application, but the two notions are arguably not parallel. One does not expect the set of URL schemes to be infinitely extensible. It’s one thing to click on an email address that’s a mailto link and have Mail open; it’s another to click on a link and have Help Viewer open, or to have Script Editor open, or to have a hidden application you’ve never heard of download and mount a disk image.

The upshot, if I’m an evildoer, is that if I can get you to download my evil application and make Mac OS X aware of it, then I may be able to get you, through a mere Web page, to send that application a message that causes it to launch and do its evil deed. My malicious application declares to the system that it responds to the "evil://" URL scheme, so if I can get you to click on an "evil://" link, my application will launch. Furthermore, as Adam explains in his article elsewhere in this issue, the real trickery comes about if I can manage to deliver a one-two punch without your realizing what has happened. Using a page containing a redirect or even frames, I can effectively make your browser visit two URLs one after the other: the first uses a technique like the disk URL scheme to download the application to your hard disk and to make the operating system aware of it, the second uses my "evil://" protocol to cause Mac OS X to launch it.

If the overall thrust of the above discussion is right, then the problem we’re facing is rather deep-seated. Part of the trouble, of course, is that URL schemes (such as disk) can cause an application to appear on your machine before you know what is happening; but another part of the trouble is that a mere URL in a Web browser can be sufficient to launch that application. Therefore it is impossible to defend against this mode of attack merely by defeating certain individual schemes, because the number of possible schemes is infinite. That’s why Unsanity’s Paranoid Android is an effective patch: it warns the user about all unknown schemes that might have been registered by a malicious application, rather than focusing on any known schemes. But if I’m right in suggesting that the root of the trouble is the folding of Internet Config’s functionality into Launch Services, then plugging this hole completely might require Apple to adjust the architecture of Mac OS X at a level so fundamental that doing so could break some capability to which we’ve become accustomed.

<http://www.unsanity.com/haxies/pa/>

The second URL below each thread description points to the discussion on our Web Crossing server, which will be much faster, though it doesn’t yet use our preferred design.

<http://emperor.tidbits.com/TidBITS/Talk/>

Mac Browser Security Hole — Readers discuss the reality of the recently reported Mac OS X security hole and what should be done about it. (4 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2233>

<http://emperor.tidbits.com/TidBITS/Talk/99/>

New AppleScript Trojan Horse — Does fault lie with the person who writes a Trojan horse, or with the outlets that publicize the fact and thereby encourage others to do so? (8 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2236>

<http://emperor.tidbits.com/TidBITS/Talk/98/>

Thoughts about WriteRight — Readers contribute their ideas and opinions about an ideal Mac word processor. (31 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2235>

<http://emperor.tidbits.com/TidBITS/Talk/101/>

Discussing Mellel — Tune in on a conversation about Mellel between Adam and the CEO of the company that makes the word processor. (5 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2237>

<http://emperor.tidbits.com/TidBITS/Talk/102/>

Problems with Disc Labeling — After we wrote about the release of disclabel 2.0, a reader points out the problems that applying disc labels to CDs and DVDs can cause. (4 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=2234>

<http://emperor.tidbits.com/TidBITS/Talk/100/>