Context:

Previous experiments to pass attribution to the MacOS DMG failed because (paste from discussion with mixedpuppy):

• Osx uses the quarantine database. The API to access the data doesn't work when launching via gui.
• We think it could work with a pkg installer but aren't sure - essentially we'd need to replicate https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/xpcom/io/CocoaFileUtils.mm#270

User story:

As a PM, I want to understand the share of MacOS users with attribution so I can size the MacOS dark funnel and address this use case accordingly.

Success criteria:

• Attribution is set on MacOS profiles with same information as currently provided on Windows after an installation.
• Install success ratio on MacOs is not affected
• File download size does not increase

Nick, I know you were doing a bit of digging here as to what is/isn't possible that we know of so far. Would you mind adding details of your findings here so we have everything related to this work in one place? If there's someone else to follow up with here, that'd be good to know as well.

(In reply to Rachel Tublitz [:rachel] from comment #1)

Nick, I know you were doing a bit of digging here as to what is/isn't possible that we know of so far. Would you mind adding details of your findings here so we have everything related to this work in one place? If there's someone else to follow up with here, that'd be good to know as well.

I did do a bit of digging. I conclude that there isn't a published/well-known "ride-along" scheme like the mutating certificates that are used to ride-along through the MS Authenticode scheme. It's challenging to experiment due to the Apple Developer process, but not impossible. But I doubt we'll be able to modify certificates just by manual inspection of the certs and the signing process.

I tried to understand the existing quarantine code, including the details about "The API to access the data doesn't work when launching via gui." I definitely see the quarantine coding failing on my local machine, but I didn't go so far as to try to duplicate the work in a non-gui macOS application.

I also noticed that Chrome/Chromium does/did things very slightly differently than we do/did and wondered if we were seeing API drifts over time. But I didn't run these things all the way down.

In the end I left this 'cuz the size of the impacted population seemed small and the technical pieces more work than was justified.

Stephen - just so we can start collecting all our ideas on this in one place - do you have any thoughts/input on approaches and/or feasibility here?

(In reply to Rachel Tublitz [:rachel] from comment #3)

Stephen - just so we can start collecting all our ideas on this in one place - do you have any thoughts/input on approaches and/or feasibility here?

I believe :nalexander summarized this very succinctly in comment 2 and I wouldn't have anything else to add at this time.

I started digging further into this. First, it's worth noting that there is a (macOS-only) xpcshell test for the relevant functionality here. What's fascinating is that copy-pasting those lines into a browser console makes it look like everything passes! And it does, but the core functionality is still broken: what seems to happen is that we can read our own write but we can't read an external (pre-existing) write (at least from the GUI App). (From the command line I can witness the write from the GUI App.) My next steps are:

1. Investigate whether an xpcshell test can read an external (pre-existing) write, verifying in another way some difference between the CLI and GUI launches;
2. Investigate where, exactly, the control flow differs in the xpcshell test from the browser console. I wish we had rr on macOS for this but there's not that much code, so I can do it manually in the debugger.

This is fascinating!

Removing assignee as we need to drop this one to take on another project right now.

I realize that before we hand this off officially, it's probably a good idea to make sure that all the details are in here. Nick, when you have some time, can you either push up what you have in progress, or link to a doc with details on where this landed?

Folks, I was looking at this actively, then I was doing other things, and now it's time to try to get this over the line. Let me link to an earlier comment (on another ticket) with some of the relevant issues, and let me expand upon them a little.

1. The general approach I propose is to run the system SQLite binary, installed by default on all relevant macOS versions, to fish the relevant information out of the per-user quarantine database.

2. The most significant security concern I see is whether we can trust this binary (in /usr/bin/sqlite3). Some discussion within the Install/Update team suggested that an attacker who could corrupt or modify that binary already had write access to the disk, which is an attack vector equal to a totally compromised Firefox. If we determine that we can't use the system SQLite binary, then we could use Firefox's compiled copy of SQLite, but we might see versioning issues. The system SQLite binary feels more robust.

3. The "relevant information" here is a URL, stored by all relevant browsers (i.e., by Safari, Chrome, and Firefox) identifying where the .dmg file and its contents were downloaded from. This URL will be fed into the existing AttributionCode.jsm mechanism (suitably generalized to more than just Windows), and the same set of URL parameters will be allowlisted and extracted.

4. I propose to generalize the existing caching mechanism form Windows to also apply to macOS. This is mostly a performance optimization, so that we sniff a single well-known location rather than launching a process at each startup, although there is a correctness argument here as well, since the quarantine database is dynamic and the attribution URL could expire.

5. One wrinkle is that the attribution URL has an arbitrary origin, whereas the Windows-specific mechanism stores the URL parameters in an unsigned portion of the stub/full installer EXE. I propose to allowlist origins from which we will collect attribution codes initially.

6. I think it will be valuable to see third-party -- i.e., non-allowlisted -- origins serving Firefox to end users; that will throw light on more of Mozilla's dark funnel. We might report full URLs, or only origins, or we might use Origin Telemetry to report origins in a privacy-preserving manner. This could be follow-up.

Clearing NI since Bug 1525076 has landed.

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:nalexander, maybe it's time to close this bug?

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #10)

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:nalexander, maybe it's time to close this bug?

Yes, I think this is correct. For the next person to read this ticket: there are known issues with attribution on macOS. First, the client-side pieces have bitrotted (yet again): I'm fairly sure that Safari, at least, is no longer writing the same data to the quarantine DB when download URLs are bounched through HTTP redirects, meaning that the download CDN bouncer interferes with this method. Second, the server-side pieces (bedrock pieces) of this were never enabled for macOS.