I finally got a chance to dig into this. The "console vs. GUI" discrepancy is spurious: what is really happening is that launching via the GUI requires the user to override GateKeeper by going to Security & Privacy > Open Anyway. Doing that updates the GateKeeper flags, and then the resulting quarantine data is not returned by [`CFURLCopyResourcePropertyForKey`](https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/xpcom/io/CocoaFileUtils.mm#212). That is, both the GUI App (immediately) or a console App (launched subsequently) will find the quarantine data. I assume that this is just the way that the macOS API is: once the GK flags reach some state, quarantine information is not returned. Moons ago, [somebody else on the internet witnessed the same thing](https://cocoa-dev.apple.narkive.com/kkYeAC8o/is-it-possible-to-read-your-own-quarantine-info-after-launch). Now, what is to be done? Under the hood, the quarantine information is still present -- it's just the GK flags that evolve. (At least on my system and presumably on the systems of other folks at Mozilla who have investigated. Folks would have noticed if the xattr data disappeared entirely, or the events were no longer present in the event database). In principle we can fish the GK GUID from `getxattr` and fish the quarantine event data from the database, and in practice the commit [here](https://phabricator.services.mozilla.com/D76773) achieves this. Therefore, I think there are a few things to be done: #. Test this approach a little more generally, especially on macOS 10.15 Catalina (I'm running 10.14 Mojave), with a try build. Maybe there's something special on my laptop -- lord knows I've monkeyed with SIP often enough. #. Decide if we're okay fishing a macOS system database in this way. Most of the places on the web that discuss this are at least 5 years old, so it doesn't seem to be a rapidly evolving area. But it's not exactly _supported_. #. Clean up the approach, possibly by pushing this implementation approach into native code. However, there's no other non-test caller of `getReferrerURL`, and there's only one non-test caller of [`setReferrerURL`](https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/browser/components/newtab/lib/ASRouter.jsm#1860) at this time, so my guess is that we could trim this down quite a bit if we chose to by moving more things to JS. #. Consider caching the extracted attribution codes on disk outside of the system quarantine DB, potentially in the install directory like we do on WIndows (so that this isn't profile-specific). Folks do purge their quarantine database, although presumably most don't; and querying an SQLite DB isn't cheap, so we'd be more robust and more performant with a little bit of JSON on disk.
Bug 1525076 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I finally got a chance to dig into this. The "console vs. GUI" discrepancy is spurious: what is really happening is that launching via the GUI requires the user to override GateKeeper by going to Security & Privacy > Open Anyway. Doing that updates the GateKeeper flags, and then the resulting quarantine data is not returned by [`CFURLCopyResourcePropertyForKey`](https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/xpcom/io/CocoaFileUtils.mm#212). That is, both the GUI App (immediately) or a console App (launched subsequently) will find the quarantine data. I assume that this is just the way that the macOS API is: once the GK flags reach some state, quarantine information is not returned. Moons ago, [somebody else on the internet witnessed the same thing](https://cocoa-dev.apple.narkive.com/kkYeAC8o/is-it-possible-to-read-your-own-quarantine-info-after-launch). Now, what is to be done? Under the hood, the quarantine information is still present -- it's just the GK flags that evolve. (At least on my system and presumably on the systems of other folks at Mozilla who have investigated. Folks would have noticed if the xattr data disappeared entirely, or the events were no longer present in the event database). In principle we can fish the GK GUID from `getxattr` and fish the quarantine event data from the database, and in practice the commit [here](https://phabricator.services.mozilla.com/D76773) achieves this. Therefore, I think there are a few things to be done: 1. Test this approach a little more generally, especially on macOS 10.15 Catalina (I'm running 10.14 Mojave), with a try build. Maybe there's something special on my laptop -- lord knows I've monkeyed with SIP often enough. 2. Decide if we're okay fishing a macOS system database in this way. Most of the places on the web that discuss this are at least 5 years old, so it doesn't seem to be a rapidly evolving area. But it's not exactly _supported_. 3. Clean up the approach, possibly by pushing this implementation approach into native code. However, there's no other non-test caller of `getReferrerURL`, and there's only one non-test caller of [`setReferrerURL`](https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/browser/components/newtab/lib/ASRouter.jsm#1860) at this time, so my guess is that we could trim this down quite a bit if we chose to by moving more things to JS. 4. Consider caching the extracted attribution codes on disk outside of the system quarantine DB, potentially in the install directory like we do on WIndows (so that this isn't profile-specific). Folks do purge their quarantine database, although presumably most don't; and querying an SQLite DB isn't cheap, so we'd be more robust and more performant with a little bit of JSON on disk.