1871561 - Starting Firefox creates 5 mozilla.org cookies (per "manage data" dialog in settings) which is confusing when trying to delete cookies and restarting

Status: NEW

(Toolkit :: Add-ons Manager, defect, P2)

Description

[:Gijs (he/him)]

From bug 1869734 comment #13:

i have installed new FF in linux.
i go to settings and delete all browsing data.
i restart FF and see 5 cookies from mozilla.org
i again remove all data and set FF to always private mode and restart.
i go back to data dialogue and see 5 cookies from mozilla.org
i again delete them all.
i restart FF and again, 5 mozilla.org cookies are displayed.

full of sadness, I open mozilla.org in a new tab, to check if these cookies are all the same.
i open web developer tools and reload mozilla.org
on all 4 storage classes, web developer tools say "no data for the host".

what kind of 5 mozilla.org cookies could respawn or be undeletable and how to inspect them?

We deliberately do not send cookies for our internal requests like telemetry, cf. https://searchfox.org/mozilla-central/rev/05178ae3d8ed27d47b340094de52bd3f572a5e1d/toolkit/components/telemetry/tests/unit/test_TelemetrySend.js#972-998 / bug 1452139.

I don't know off-hand what other request(s) may be setting these (and/or if maybe the server is sending cookies that we then never send back, or something).

Comment 1

[:Gijs (he/him)]

Looks like these are created on the client, without network requests, by the add-on recommendation service. There are 5 because of containers (1 for no-container + 4 default containers) - if you have more containers there would be more, if you disable containers there will be fewer. If you disable "Allow Firefox to make personalized extension recommendations", the cookies will go away (you don't need to disable telemetry for that).

The "Manage data" dialog shows cookies by their toplevel domain (so all of mozilla.org gets grouped, all of google.com gets grouped, etc.), and so the cookie doesn't show up when you browse to mozilla.org because the cookie is set for addons.mozilla.org. If you go to addons.mozilla.org, the cookie shows up in devtools just fine. (visiting AMO without "do not track" or similar enabled may also set other cookies when you visit)

It's not really clear to me why we'd need to create a cookie for each container... Hopefully some of the addon folks can comment.

Moving this to the add-on manager component. I think ideally, this should not be so confusing for users (where are these cookies coming from if all data has been deleted?).

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Rob Wu [:robwu]]

The patch that adds taarId cookie was added in bug 1489531.
An early version of the code on AMO started referencing it (https://github.com/mozilla/addons-frontend/pull/7357), but before the PR was merged, the taarId usage was removed: https://github.com/mozilla/addons-frontend/pull/7357/commits/824a9210295f7884d102e6e3212486aeecca9054

We should be able to remove the taarId cookie logic altogether. The TAAR ID is passed somewhere else, at https://searchfox.org/mozilla-central/rev/43c40b22c776d098afb89d5237da3464a7545532/toolkit/mozapps/extensions/content/aboutaddons.js#600-603

We can thus fix this bug easily by removing browser/modules/Discovery.sys.mjs and related tests in browser/modules/test/unit/test_discovery.js.

Comment 4

[Rob Wu [:robwu]]

Fixing this is trivial, per comment 3. Marking as P2 so that we can move it to our "small task" queue when it's ready.