Open Bug 1871000 Opened 10 months ago Updated 1 month ago

Add a page explaining what unique identifiers Firefox sends to remote endpoints, why, and how users' privacy is safeguarded [Firefox Desktop off-train]

Categories

(support.mozilla.org :: Knowledge Base Content, enhancement)

Desktop
All
enhancement

Tracking

(firefox-esr115 affected, firefox121 affected, firefox122 affected, firefox123 affected)

Tracking Status
firefox-esr115 --- affected
firefox121 --- affected
firefox122 --- affected
firefox123 --- affected

People

(Reporter: bug.reporter.321, Assigned: lsiebert, NeedInfo)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

To my knowledge, we do not have an about: page for hidden identifiers in Firefox.
FF maintains various undocumented identifiers for various "services" provided by mozilla or others.

A) Some of these are inspected in the configuration about:config:

browser.newtabpage.activity-stream.impressionId
dom.push.userAgentID
toolkit.telemetry.cachedClientID
app.normandy.user_id
...

B) Some seem completely invisible
e.g. the hidden encrypted cookies from google safebrowsing v4 (see e.g. https://github.com/google/safebrowsing/blob/master/internal/safebrowsing_proto/safebrowsing.proto line 198-199)

Actual results:

There is no oversight about hidden identifiers in firefox.

Expected results:

We should have an about: page, which is linked via the privacy settings, displaying our identities/cookies for external services.

(In reply to Hannes from comment #0)

We should have an about: page, which is linked via the privacy settings, displaying our identities/cookies for external services.

What purpose would showing these identifiers serve?

Flags: needinfo?(bug.reporter.321)

Because they are basically cookies.
Like the other cookies, you might want to know what services you are steadily subscribed to (and maybe even be asked before it activates).
Arkenfox can disable these services, but i think for sake of transparency, noone would be hurt if all these services are enumerated and displayed at a central place (and ideally activation can be toggled by the user).

For push-id, for example, there is a nice write up: https://support.mozilla.org/en-US/kb/push-notifications-firefox
It could be linked next to the pushid field.

Its just that we can see what we are subscribed to and why, so we can make informed decision.

Thanks so much

Flags: needinfo?(bug.reporter.321)

I confirm this report as an enhancement. Other more technical decision-making people should decide whether this is actionable or not.
Thank you for your contribution!

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop

I've chosen this component because the report is an enhancement suggestion to implement a new "about" page. If this component is incorrect, please set a more appropriate one.

Component: Untriaged → General
Product: Firefox → Toolkit

I've discussed this with the Firefox team.

We don't think that having an in-product page is a good fit for this problem space. There is limited scope for explanation inside an about: page, it would require all volunteer translators to translate all the content, and for architectural reasons offering "turn this off" toggles is best done inside the usual Settings or about:config environments.

In terms of oversight, code review and data review processes are in place so I don't think "no oversight" is a fair characterization of how Firefox treats the unique identifiers you're talking about.

In terms of user insight into what identifiers are sent, there are other tools available (the browser toolbox's network panel and storage inspection tools, or normal external networking inspection tools like Wireshark and external tools to read sqlite databases if you don't trust Firefox, etc.). We don't think that the value of Yet Another About Page (Firefox already ships with more than 70!) is a good trade-off for the cost of maintaining that forever, especially when also considering the lack of discoverability both inside and outside Firefox.

The first thing that someone curious about these requests is likely to do is search the web. So a web-based solution seems better. We could host this either on the developer-focused https://firefox-source-docs.mozilla.org/ or the user-focused https://support.mozilla.org/ . The latter seems preferable: it is more discoverable, it's where lots of similar explanations already live, and it offers translated content - even though it is slightly more difficult for engineering teams to update. Doing all this on the web instead of an about: page also makes it easier to link to and from other explanations, like the privacy policy and the documentation of automatic connections (which also lives on SUMO).

Because of this, I'm moving this to the support.mozilla.org part of bugzilla so that team can take a look at doing this.

As an aside, your github link is not a permalink so it may be/go out of date - assuming you meant the new_client_state variable, from a very quick read, as far as I can tell that is simply a hash of downloaded safebrowsing information; it's not really unique to the client so isn't an "identifier" - it looks like it's used in the same way as an ETag is used in http caching.

Component: General → Knowledge Base Content
Product: Toolkit → support.mozilla.org
Summary: Privacy enhancement: Please add an "about:" page for hidden identifiers → Add a page explaining what unique identifiers Firefox sends to remote endpoints, why, and how users' privacy is safeguarded
Version: Firefox 120 → unspecified
Assignee: nobody → lsiebert

Hi team. We need the content intake template filled out (sharing some instructions here: https://mozilla-hub.atlassian.net/wiki/spaces/MSS/pages/21430745/Mozilla+Knowledge+Base+and+Support+Content) to clarify the full scope of what needs to be covered so we can determine the best approach.

Hello team! To follow up on Mandy's request, could we get additional details on the documentation's scope to better decide on our approach?

Flags: needinfo?(bug.reporter.321)

(In reply to Lucas Siebert from comment #7)

Hello team! To follow up on Mandy's request, could we get additional details on the documentation's scope to better decide on our approach?

Stealing this needinfo. :-)

Flags: needinfo?(bug.reporter.321) → needinfo?(gijskruitbosch+bugs)
Summary: Add a page explaining what unique identifiers Firefox sends to remote endpoints, why, and how users' privacy is safeguarded → Add a page explaining what unique identifiers Firefox sends to remote endpoints, why, and how users' privacy is safeguarded [Firefox Desktop off-train]

Going to try to fill in the questions from the content request form here:

Is the content embargoed: No.
Product: Firefox
Type of request: New article
Request summary: Please add an article describing the types of unique identifiers Firefox sends as part of its normal operations
Release number and date: no release number / date. If a deadline is helpful, 1 month from now?

Applicable documentation, design assets, instructions for testing in product

We should start with the list from comment 0 and update it as needed. We'll need an overall description at the top of the article that explains what this is (a list of the types of unique identifiers that Firefox uses to make things like push notifications and experiments work), and probably a paragraph or two per identifier that explains what they are (can be shorter if we can link to existing other articles, like the dom.push.userAgentID one can link to the push docs, the normandy user ID can link to https://support.mozilla.org/en-US/kb/shield , the telemetry client ID can link to https://support.mozilla.org/en-US/kb/telemetry-clientid ). I'm not sure if we have existing documentation on pocket's impression ID - hopefully Scott Downe can help.

Let me know if this is enough to get started on the article / if you need more information. :-)

Flags: needinfo?(gijskruitbosch+bugs)

Per meeting with Lucas and Gijs, CX should be able to have this article published sometime between Mar 19 and Apr 16.

(In reply to Lucas Siebert from comment #11)

Asana: https://app.asana.com/0/1203460865189761/1206423140139282/f

I don't have access to this. Do you need me or someone else to review this?

Flags: needinfo?(lsiebert)

Hi (In reply to :Gijs (he/him) from comment #12)

(In reply to Lucas Siebert from comment #11)

Asana: https://app.asana.com/0/1203460865189761/1206423140139282/f

I don't have access to this. Do you need me or someone else to review this?

This is just for our internal content roadmapping. We will definitely let you know once it's ready for review, thanks!

You need to log in before you can comment on or make changes to this bug.