One of the new security measures in Leopard is a confirmation dialog that pops up anytime you attempt to open a file or executable bundle that was downloaded from the internet. You may have seen this dialog after downloading and launching a new application, for instance. It looks something like this:
Some have hailed this as a breakthrough in security standards, I'm sure, though I can't find any specific sources to cite. Most folks who notice such things are actually rather annoyed by the alerts, likening them to similar attempts at security in versions of Windows. Indeed, it's difficult to make the argument that such a warning would be very effective at preventing user-initiated security breaches. In reality it's just the sort of warning that most people click through because 99% of the time it's unwarranted. This has most SysAdmins and advanced users asking, "Why bother?" After which they promptly ask themselves, "How do I turn this shit off?"
The bad news is that there doesn't seem to be a GUI way. There is no simple System Preferences checkbox for the alert. The good news is that there appears to be at least a couple possibilities for getting this done.
The first approach involves watching whatever folder you use for downloads, either via a Folder Action or via a Launch Daemon. The basic gist is that anytime that folder gets modified a script runs that removes the flag that causes the warning to appear from all items in the downloads folder. Because, you see, that's all that's going on. Anytime something is downloaded to your computer, Leopard flags it. When you open it in the Finder, the flag triggers the alert. Confirmation of the alert removes the flag. That's the mechanism. Using the watch folder method simply disables the flag, which is akin to hitting that "Open" button in the alert, only it happens automatically in the background.
There are a couple problems with this method. First off, it's difficult to implement, and second, it breaks anytime you decide to start using a different folder for downloads. And then there's the obvious fact that it's just plain ugly: a script workaround to disable an OS feature? Bluglgh! Terrible!
A better solution would be some sort of preference file. Apple often enables — but hides from the GUI — certain advanced preferences, allowing more savvy users to set the preference either by the addition of a preference (.plist) file, or by using the defaults command. There are all sorts of mods for the Dock, for instance, that, while unavailable through the GUI can be set via defaults. It appears that Apple has provided such an invisible preference for the Leopard download alert as well. And if you know how to create and edit a .plist file, activating the preference and disabling the alerts is fairly straightforward.
Some Background The instructions I'm about to provide have been posted in numerous other spots on the Web. But when I went searching for this info there seemed to be no single place that explained not just how to perform the modification, but also what it did and how the mechanism we're defeating works in the first place. So I wanted to provide some background info about just exactly what's going on here.
Metadata The first piece of this puzzle is the basic concept of metadata. Metadata is often best described simply as "data about data." And in Leopard we (or, more particularly, developers) finally have the ability to add arbitrary metadata. That is, as a developer, you can add any sort of descriptive data you want to your files and the files your application creates. Mac OS X 10.5 and up can read that metadata, interpret it and behave accordingly. So, to follow our example, when we download Camino from the Internet, the Mac OS (specifically, the Finder) adds some metadata to our Camino application, and that metada says, "This application was downloaded from the internet and has not been flagged for approval." Now, when we go to open the application for the first time, the Mac OS also knows to behave a certain way based on this metadata, and so we see that alert pop up. Clicking the "Open" button writes new metadata to the file, and that metadata now says, "This application has been opened and flagged for approval." The OS now knows not to present the alert the next time the app is opened. Such is the power of metadata.
By the way, I should mention that you can actually tell which files have metadata associated with them by doing a long file listing:
DrMac:~systemsboy$ ls -l Movies
drwxr-xr-x 9 systemsboy staff 264 Nov 14 09:35 .
drwxr-xr-x 10 systemsboy staff 296 Nov 7 17:20 ..
-rw-r--r--@ 1 systemsboy staff 407041761 Oct 31 15:45 DownloadedMovie.mov
-rw-r--r-- 1 systemsboy staff 407041761 Oct 31 15:45 LocalMovie.movNotice the "@" symbol at the end of the permissions info for the DownloadedMovie.mov file? That means that this file has metadata associated with it.
You can look at any metadata your files contain by way of the xattr command. The command is simple to use:
DrMac:~systemsboy$ xattr -l Movies/DownloadedMovie.mov
Movies/DownloadedMovie.mov: com.apple.quarantine: 0000;48fa188d;Firefox.app;|org.mozilla.firefoxHere we can see that our DownloadedMovie.mov has an Apple-branded quarantine flag, and that it was downloaded with Firefox. Nice!
UTIs The next piece of the puzzle comes in the form of something called Universal Type Identifiers, or UTIs. UTIs are a specific kind of metadata that are meant to describe and define types of files. So, our Camino application has metadata not only that tells the OS that it came from the Big Bad Internet (BBI), but also what sort of file (or in this case bundle) it is, namely that it's an application. This particular piece of metadata is the UTI, and there are a bunch of them. The complete list can be found on Apple's Developer site. UTIs can be extremely useful, and they'll actually allow us some flexibility in defeating Apple's quarantine mechanism. Because with UTIs we can specify which sorts of files trigger the alert and which don't, which is pretty great if you need it. And even if you don't, it's something that might come in handy down the line.
The Defeat So, with that out of the way, let's step through our method for disabling the Mac OS alert for downloaded files.
- The first thing we'll need is a file in our Preferences folder called "com.apple.DownloadAssessment.plist." If you have one, great, if not make one, either with Property List Editor, TextEdit or whatever text editor you have handy.
- Next, populate the file with this data:
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LSRiskCategoryNeutral</key> <dict> <key>LSRiskCategoryContentTypes</key> <array> <string>public.item</string> </array> </dict> </dict> </plist> - Finally, restart the Finder.
From here on out, the OS will flag any item downloaded from the BBI (the UTI "public.item") as "Neutral." This should completely eliminate any sort of alert regarding downloads. Of course, there are exceptions — and I'll talk about them in a minute — but this should mostly do the trick.
Using UTIs and the Risk Categories outlined here, you can vary and specify the OS behavior for a wide range of file types. Want downloaded applications to raise the alert, but HTML files to be considered safe? Not a problem. Just specify as much in the plist file. It might look something like this:
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>LSRiskCategoryUnsafeExecutable</key> <dict> <key>LSRiskCategoryContentTypes</key> <array> <string>public.executable</string> </array> </dict> </dict><dict> <key>LSRiskCategory</key> <dict> <key>LSRiskCategoryContentTypes</key> <array> <string>public.html</string> </array> </dict> </dict></plist>
Now, applications we've downloaded from the Internet (UTI "public.executable") will be treated as "Unsafe Executables" and will prompt the quarantine alert. But downloaded HTML files (UTI "public.html") will be treated as "Safe" and be exempt from the alert. As you can probably gather, you could get really, really fine-grained here if you needed to. Most folks will be covered with the first example, but as a SysAdmin it's always good to know you have options.
Exceptions Now earlier I mentioned exceptions. And one of those exceptions is Camino itself. Remember earlier when I specified that developers could add metadata to files? It's important to understand that it's not always the Finder or even the Mac OS itself that's creating this metadata. Applications themselves can also write metadata to files, and that's exactly what Camino does. Anytime you download a file with Camino it adds it's own metadata to the download. And that metadata will trigger the Mac OS's quarantine alert. So the above hack fails for applications such as these, and there's not much to be done about it. The rationale for Camino's approach is at least partially detailed in bug report 464333 on Camino's developer site.
UPDATE: The folks at Camino are now re-examining the issue.
Further Reading Credit where due, I collected all my info on this topic from the following sources: The Folder Action Hack Arbitrarily Extensible Metadata Uniform Type Identifiers (UTIs) Download Security Assessments Creating and/or Modifying the Preference File
And inspiration and help for this post came from an excellent bunch of comments in another article right here on this very site.
In Conclusion I have to admit, I find what Apple is doing here fascinating. I'm not sure that popup alerts for every downloaded file is a great idea in practice, but I do think it's an interesting example of what's possible with metadata and highlights just how useful this addition to the OS could be if leveraged properly. Imagine if metadata were something in the hands of everyday users. Imagine if you could assign your own set of actions based on your own set of metadata tags. It could fundamentally change the way you interact with your computer, essentially allowing you to program it at will to your whims. And maybe someday it will, if Apple sees the potential here and continues to push forward with this Great Metadata Experiment in fresh and innovative ways.