Entries in datareporting/archived despite telemetry being disabled
Categories
(Toolkit :: Telemetry, defect, P1)
Tracking
()
People
(Reporter: p7272, Assigned: chutten)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0
Steps to reproduce:
Recent files in the datareporting directory, but i have always unchecked those options
Actual results:
Files are being generated.
Expected results:
There should be no files.
Comment 1•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Telemetry' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•7 months ago
|
||
I created two profiles and tried to keep them as similar as possible but turned off telemetry upload and daily health ping. Then I compared the two profile directories and found more files in the no-telemetry profile, the datareporting files mentioned in comment 0 and also files in a saved-telemetry-pings directory.
Removing those would 1) eliminate wasted space on systems without telemetry, and 2) give better assurance that telemetry isn't being collected.
| Assignee | ||
Comment 3•7 months ago
|
||
That's unexpected. I'll take a look and see whether this is a leftover from a previous design (we'd still collect data locally in case the user found it interesting to diagnose their own performance bugs (cf. Firefox Health Report)) or a bug or what.
| Assignee | ||
Comment 4•7 months ago
|
||
The code's pretty straightforward: if sending's disabled, we don't even save pings to disk. So this seems like a bug.
In the no-telemetry profile, did you merely uncheck the checkmarks in the settings, or did you perform any other customization?
Comment 5•7 months ago
|
||
I went into settings and unchecked:
- Send technical and interaction data to Mozilla
- Send daily usage ping to Mozilla
After that nothing in Nightly Data Collection and Use was checked.
I just tried it again and entries appeared in datareporting/archived/2025-09 with a timestamp six minutes after I made the settings changes.
The contents of saved-telemetry-pings is less scary if you look at the file contents -- it looks to be the delete request:
{"type":"deletion-request","id":"f9cf124c-bdfb-452f-8f6c-92290c361a7c","creationDate":"2025-09-29T18:32:17.866Z","version":4,"application":{"architecture":"x86-64","buildId":"20250927093555","name":"Firefox","version":"145.0a1","displayVersion":"145.0a1","vendor":"Mozilla","platformVersion":"145.0a1","xpcomAbi":"x86_64-gcc3","channel":"nightly"},"payload":{"scalars":{"parent":{"deletion.request.impression_id":"{6abd6f71-765f-41df-9bee-b985b67f5e5c}"}}},"clientId":"8760bf5b-bcb8-48b7-93cd-65215206dd30","profileGroupId":"8aad9294-3e21-4202-ab23-b2ca1fe092cd"}
But seeing a telemetry ping after turning of telemetry was unexpected.
That's the deletion-request. We treat disabling telemetry as a signal to delete Telemetry data on our end (docs). It's intentionally limited and only sent once.
| Assignee | ||
Comment 7•7 months ago
|
||
Is it only the one ping? It should only be the one ping.
Comment 8•7 months ago
|
||
There is only one entry in saved-telemetry-pings. New entries are being created today under datareporting even though I tried to turn off information sent to Mozilla on 29 September.
Can you reproduce this behavior?
| Reporter | ||
Comment 9•6 months ago
|
||
Back from vacation.
My saved-telemetry-pings folder is empty and datareporting is the same for me with new entries daily.
Comment 10•5 months ago
|
||
The severity field is not set for this bug.
:chutten, could you have a look please?
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 11•5 months ago
|
||
Sorry for the delay, I've been swamped.
I've reproduced the circumstances and the result. If you turn off the data upload checkbox in the settings, more pings will continue to be archived locally on disk in the datareporting\archived\yyyy-mm folders.
Firstly and most importantly: these aren't uploaded. They are a local archive and they have the "known canary client_id" value of c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0 so that if by any odd mechanism (be it logic bug or someone being clever and using curl) they do end up sent to Mozilla, we have no idea which Firefox actually uploaded it and know to ignore it/delete it. The only ping that can be uploaded when data upload is disabled is the "deletion-request" ping (to make sure we delete any data we received from that profile before data upload was disabled).
I agree, though. I, too, find it unexpected to see new data show up on disk.
I do believe this to be operating according to design, though, if not desire or expectation. This legacy telemetry system's history includes a time where it was used to record diagnostic data locally so that users could use it to diagnose problems they might be experiencing (like slow startup or bad performance). This system was called Firefox Health Report and hasn't existed in this form since Firefox 42. But it's still one of the two systems that made up the current Legacy Telemetry (the other one was called Firefox Telemetry. We took its name. But we kept FHR's pieces elsewhere, including the internal name for the pref that data opt-out setting reflects: datareporting.healthreport.uploadEnabled). As a result I can understand why this would be the design, and why this would be the result: you need a record of past data in order to report trends and diagnose faults, whether upload of that data is enabled or not.
Luckily, this behaviour will soon be removed. We're in the process of replacing Legacy Telemetry with a different collection library called Glean. Glean doesn't have an archive at all, and if data upload is disabled it just stops recording data (rather than writing it down in case a curious user would like to inspect it locally). By the end of 2026 we hope to have turned off and removed Legacy Telemetry from Firefox Desktop, so by then at the latest we should be rid of this unexpected behaviour.
For now, though, I would understand if you're not content with the behaviour. If you'd rather that the archive not be updated with new pings that will never be uploaded, you can turn off the Telemetry Archive by opening about:config and setting toolkit.telemetry.archive.enabled to false: this disables the archiving of pings whether you have data upload enabled or disabled. If you don't mind the behaviour now that it's been explained, you can feel free to leave it to do its own thing -- it's a self-limiting system, so it won't take more than 120MB of disk space and won't store any pings older than 60 days.
Does that resolve your issue? If so, I will close this bug.
| Reporter | ||
Comment 12•5 months ago
|
||
Just typing telemetry in about:config shows a lot more going on than just toolkit.telemetry.archive.enabled. ;-/
| Assignee | ||
Comment 13•5 months ago
|
||
You're right: there's a lot in about:config with the word telemetry in it. This is to be expected of any browser subsystem. Check out how many there are for sync!
Each line in about:config is a piece of state that Firefox is storing persistently between runs. Much of it is of internal interest only. For example: toolkit.telemetry.ipcBatchTimeout is a performance knob we could tweak in case having more, smaller batches would be better instead of fewer, larger batches. We find it helpful to put everything and the kitchen sink in these pieces of state (called "prefs").
Be cautious while you're in there, though. I told you about toolkit.telemetry.archive because I'm the module owner for Telemetry and so I'm confident that its interactions with other pieces of code should be benign in your case. (I also told you because you've shown interest in and understanding of the Legacy Telemetry component. It seemed to me like you'd want to know.) Changing the wrong thing in there could lead to an inconsistent state in your profile, bad performance, or any number of things.
Ultimately, it's your Firefox, so you can change these however you want. But maybe back up your profile before you do too much experimentation.
I'm going to consider the original issue you spoke about as resolved for now, and mark the bug as such. We can keep the comment thread going here even if it's resolved if you have more to ask or to report, and we can even reopen it if needed.
Description
•