4 ms·

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

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 http://i.imgur.com/IbUWj.png

danso 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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 14y ago
    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/RemovingSecurityFromDownloadedPowerShellScriptsWithAlternativeDataStreams.aspx http://www.hanselman.com/blog/RemovingSecurityFromDownloaded...).
0x0 14y ago
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 14y ago
  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 http://i.imgur.com/Ks03r.png
- TheCapn 14y ago
  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 14y ago
    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 14y ago
  Correct. There's a quarantine attribute.
- mistercow 14y ago
  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 14y ago
    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 14y ago
You, or whomever did the screencap, must have a retina macbook. That dialog in the screencap looks huge on my computer.
- sk5t 14y ago
  Since we're OT, "whom" only works in objective case.
  - hythloday 14y ago
    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..."
vicaya 14y ago
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 14y ago
  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.
  - Zr40 14y ago
    UUID, not UDID. The latter is an unique identifier for iOS devices.
    - eridius 14y ago
      Oops, typo. Too bad I can't edit my post anymore.
  - szc 14y ago
    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.
- pretoriusB 14y ago
  NAH, the warning is merely initiated by the extended attributed. The information in it comes from elsewhere (presumably the database).

danso 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
  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/RemovingSecurityFromDownloadedPowerShellScriptsWithAlternativeDataStreams.aspx http://www.hanselman.com/blog/RemovingSecurityFromDownloaded...).

0x0 14y ago

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 14y ago
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 http://i.imgur.com/Ks03r.png
TheCapn 14y ago
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 14y ago
  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 14y ago
Correct. There's a quarantine attribute.
mistercow 14y ago
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 14y ago
  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 14y ago

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

sk5t 14y ago
Since we're OT, "whom" only works in objective case.
- hythloday 14y ago
  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..."

vicaya 14y ago

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 14y ago
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.
- Zr40 14y ago
  UUID, not UDID. The latter is an unique identifier for iOS devices.
  - eridius 14y ago
    Oops, typo. Too bad I can't edit my post anymore.
- szc 14y ago
  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.
pretoriusB 14y ago
NAH, the warning is merely initiated by the extended attributed. The information in it comes from elsewhere (presumably the database).