1616355 - Attribution postSigningData should be per installation

Status: RESOLVED FIXED

(Firefox :: Installer, defect, P3)

Description

[Nick Alexander :nalexander [he/him]]

Right now, the postSigningData written by an attributed stub installer is written to a single global location. That means that multiple installers will compete for the global location, and in the event that a second Firefox version is installed an existing profile will report varying attribution, which of course should not be possible. This ticket tracks making postSigningData per installation.

Comment 1

[Nick Alexander :nalexander [he/him]]

mhowell: in person you suggested this was merely oversight when initially implemented. Can you confirm? Is there any reason not to do this? Is there any migration needed? My guess is that no migration is needed: new apps will know to look in the per-installation directory and actively should not look for out-dated postSigningData in the single global location.

Comment 2

[Nick Alexander :nalexander [he/him]]

This should probably block attribution for the full installer: Bug 1316136, although it is technically independent of that work.

Comment 3

[Molly Howell (she/her) (mostly inactive)]

Yeah, I can't think of a good reason not to do this. I feel like the main reason it's the way it is probably comes down to my thinking about when and how to do things on a per-install basis being less well developed in 2016 vs. now.

Not doing any migration would mean losing the attribution data for all installs created prior to this patch; my guess is that would be worth avoiding. The obvious tactic would be to have the first install that finds an old-style file just take possession of it and move it into its install-specific location. That risks associating it with the wrong installation, but that would mean that we're already sending the wrong attribution for all but one installation on that machine now.

Comment 4

[Nick Alexander :nalexander [he/him]]

Getting this into the Desktop Integrations backlog. It was an enhancement at the time but we're now possibly witnessing MSIX installations pulling attribution data from existing Firefox installations, which is a defect.

Comment 5

[[e-mail] (:bhearsum)]

Since this bug was opened Mac support for attribution was added. It appears to store the attribution data in a folder that includes the full path to the install directory (eg: ~/Library/Caches/Mozilla/updates/Application/Firefox) - so it doesn't appear to suffer from this bug.

Comment 6

[Nick Alexander :nalexander [he/him]]

(In reply to [e-mail] (:bhearsum) from comment #5)

Since this bug was opened Mac support for attribution was added. It appears to store the attribution data in a folder that includes the full path to the install directory (eg: ~/Library/Caches/Mozilla/updates/Application/Firefox) - so it doesn't appear to suffer from this bug.

It's true that macOS caches the data in a per-installation location, but Windows is definitely not doing a per-installation thing here: see where i t's written and where it's read. I wonder why we're not just leaving it in the executable directory?

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Nick Alexander :nalexander [he/him] from comment #6)

(In reply to [e-mail] (:bhearsum) from comment #5)

Since this bug was opened Mac support for attribution was added. It appears to store the attribution data in a folder that includes the full path to the install directory (eg: ~/Library/Caches/Mozilla/updates/Application/Firefox) - so it doesn't appear to suffer from this bug.

It's true that macOS caches the data in a per-installation location

Yes, sorry -- I was mainly making a note that we definitely don't have to touch Mac here.

I wonder why we're not just leaving it in the executable directory?

My first thought was to move it to a directory named after the install dir -- but seeing as we have write access to the actual install dir this seems cleaner. I see in earlier comments that we want to move the existing postSigningData to the new location -- but I believe that should be fine, since PostUpdate has write access to the install dir anyways.

Comment 8

[[e-mail] (:bhearsum)]

edit: this became invalid before I posted it - forget to remove it before updating the bug.

Comment 9

[[e-mail] (:bhearsum)]

Attachment: Bug 1616355: attribution postSigningData should be per installation r?nalexander!,mardak!

about:newtab#asrouter actually depends on the ability to be able to write to postSigningData at the moment, so this will break that in any circumstance where the running Firefox cannot write to the installation directory. This code is only used for dev & qa testing though, and I've been told this is OK (and we may change how it works to avoid writing the file at all).

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8264be10e203
attribution postSigningData should be per installation r=nalexander

Comment 11

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/8264be10e203