Open Bug 1619353 Opened 1 year ago Updated 5 months ago

[meta] Support attribution on MacOS

Categories

(Firefox :: Installer, enhancement, P2)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: RT, Assigned: nalexander)

References

(Blocks 1 open bug, )

Details

(Keywords: feature-testing-meta, meta, Whiteboard: [iu_tracking])

Context:

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

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.

Flags: needinfo?(nalexander)

(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.

Flags: needinfo?(nalexander)

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?

Flags: needinfo?(spohl.mozilla.bugs)

(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.

Flags: needinfo?(spohl.mozilla.bugs)
See Also: → 1344771
Keywords: meta
Priority: -- → P3
See Also: → 1525076, 1511071
Summary: Support attribution on MacOS → [meta] Support attribution on MacOS
Whiteboard: [iu_tracking]
Severity: normal → N/A

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!

Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Priority: P3 → P2

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

Assignee: nalexander → nobody
Status: ASSIGNED → NEW

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?

Flags: needinfo?(nalexander)
Assignee: nobody → nalexander
Status: NEW → ASSIGNED

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.

Flags: needinfo?(nalexander)
Blocks: 1671458
Whiteboard: [iu_tracking] → [iu_tracking], [feature-testing-meta]
Whiteboard: [iu_tracking], [feature-testing-meta] → [iu_tracking]
You need to log in before you can comment on or make changes to this bug.