[ehamberg]

This is used to show where a program came from the first time you run it. For example, if I download iTerm 2 and then run it, I get the following warning:

http://i.imgur.com/IbUWj.png

[vicaya]

Nah, the warning comes from the extended attribute on the application folder/zip. It has nothing to do with the log.

You can disable the warning by a command line:

xattr -d com.apple.quarantine <path_to_your_program>

[eridius]

The extended attribute records that the file is quarantined, but it doesn't contain the detailed information about where the file came from. It just has an identifier that's used to look up in the database. For example, here's the quarantine info for a file in my Downloads folder: 0002;50e77ce1;Safari.app;BF047C49-2539-4536-A584-E69FDE328A2C. I don't know what the first two fields are, but the third is the app that downloaded it, and the forth is a UDID, which is presumably the identifier for the quarantine event.

Furthermore, even once a file is out of quarantine, the Get Info dialog can still tell you where it was downloaded from, precisely because of this database.

[szc]

There is a reason why the marking of the file and the database containing the download information are separate. It is for personal privacy! If you copy or move the file or someone else runs whatever it is, the "quarantineness" is still there, but the personal information about where and when you downloaded it will not be accessible. The "taint" associated with the downloaded object will remain with the file, but the personal and potentially private information does not.

[Zr40]

UUID, not UDID. The latter is an unique identifier for iOS devices.

[eridius]

Oops, typo. Too bad I can't edit my post anymore.

[pretoriusB]

NAH, the warning is merely initiated by the extended attributed. The information in it comes from elsewhere (presumably the database).

[0x0]

Actually I think that warning comes from data stored in the xattr com.apple.metadata:kMDItemWhereFroms on the file itself. So this sqlite database must be for something else.

[ehamberg]

Hmm, it seems that the URL is taken from the database. If I delete the relevant row, the URL is no longer shown:

http://i.imgur.com/Ks03r.png

[TheCapn]

I'm not a Mac user but wouldn't the test therefore be to clear the DB entries and re-open the file. No prompt implies the link to the sqlite db and not the file attr.

[mitchty]

The dialog only shows up when that xattr is set, the sqlite db has nothing to do with this security prompt. In fact all the prompt does is unset the xattr if you deem it ok.

[mikec3k]

Correct. There's a quarantine attribute.

[mistercow]

The design decision of storing the application a file came from in file metadata, but the URL it came from in an sqlite database ... makes my head hurt.

[pretoriusB]

So, I assume you have considered all the aspects of the problem to come to that conclusion right?

Not merely pondered upon it for 2 minutes and decided that Apple programmers were idiots for doing so, right?

[DigitalJack]

You, or whomever did the screencap, must have a retina macbook. That dialog in the screencap looks huge on my computer.

[sk5t]

Since we're OT, "whom" only works in objective case.

[hythloday]

Which is to say, where you'd say him or her, rather than he or she.

"He, or whoever took that screenshot..." "Her, or whomever that screenshot was sent to..."

[danso]

Kind of brilliant, actually. Not the fix or the tracking method...just that I knew subconsciously that if OSX could know to warn me that I'm trying to open up a file downloaded from the internet (and which webpage it came from), then it must have some way of tracking it that supersedes the standard browser wipe. But I just never thought to look around for it.

[axusgrad]

Windows will warn you about files downloaded from the internet, too. It uses "Alternate Data Streams" feature of NTFS to mark the file. I suppose once you delete the file, the alternate data stream is gone as well. From what I read, alternate data streams were made for compatibility with a Mac filesystem!

[mhurron]

And OS X could do the same thing with the resource fork if they wanted to instead of never forgetting.

Seems to me this would be a better way to do it, you're reading the resource fork for the file anyway, why also make a sqlite query as well?

[klodolph]

No, the resource fork is dead for good reasons. (1) The resource fork is fragile and easily corrupted, like the Windows registry in the bad old days. (2) Four-character namespaces suck. (3) 24 MB limits suck. (4) Extended attributes and bundles are better in every conceivable way.

The resource fork was designed for a different world. (A) In the old days, there was a blurry line between OS and app, so there was no reason to make the resource fork "opaque". Without opacity, there is no graceful way to use it in a preemptive multitasking environment. (B) In the old days, pointers were 24 bits. The high 8 bits didn't go anywhere, so people used these high bits to store extra data. Resource forks make use of 24-bit quantities for this reason — which went out of favor when Macs with the 68020 were introduced in 1987. (C) The real feature of resource forks was to reduce the disk space usage and load times when you have lots of small pieces of data, but — data is bigger and we have better archive formats.

So yeah, extended attributes are the way to go.

[hosay123]

There is also a maximum of one officially supported fork per file (i.e. in a single format), and even a single stored byte will occupy a full block. On HFS+ attributes are written as individual records directly to a per-filesystem b-tree, so wastage is no worse than any other metadata. HFS+ also has named forks but they were never a supported feature AFAIK

[ashmud]

Deleting the file also deletes the stream (in as much as deleting a file marks it as OK to overwite). Scott Hanselman blogged several ways to remove streams in 2007 (http://www.hanselman.com/blog/RemovingSecurityFromDownloaded...).