Documented coordinate privacy protection is not applied to emissions.csv
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.9k
- Forks
- 323
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 12
Description
The output reference documents that latitude and longitude are written with reduced precision as a privacy measure. That is true for the API path only. The CSV receives full-precision coordinates, so users relying on the documented behaviour are sharing a more precise location than they expect.
Current behaviour
docs/reference/output.md describes the latitude / longitude fields as being written "with reduced precision to 11.1 km (privacy protection)".
Rounding is applied in exactly one place, on the API path:
# codecarbon/core/api_client.py:245-246
longitude=round(self.conf.get("longitude", 0), 1),
latitude=round(self.conf.get("latitude", 0), 1),
The CSV path does no rounding. _prepare_emissions_data reads the values straight from config:
# codecarbon/emissions_tracker.py:1111-1112
longitude=self._conf.get("longitude"),
latitude=self._conf.get("latitude"),
and those were populated at full precision from the geolocation lookup:
# codecarbon/emissions_tracker.py:385-386
self._conf["longitude"] = self._geo.longitude
self._conf["latitude"] = self._geo.latitude
Why this matters
emissions.csv is the artefact users attach to papers, commit to repositories, and upload alongside experiment results. The documentation gave them a reason to believe the coordinates in it were already coarsened to roughly 11 km. They are not — they are whatever the geolocation provider returned, which for a residential connection can be considerably more precise.
This is a mismatch between a documented privacy guarantee and actual behaviour, which is worse than never having documented it.
Expected
One of:
- Apply the same rounding on the CSV path, making the documented behaviour true everywhere. This is the option that matches what users have been told, and one decimal place is unlikely to matter for any legitimate use of the field.
- Correct the documentation to state that full-precision coordinates are written to the CSV, and offer a configuration option for users who want them coarsened or omitted.
Option 1 seems more defensible given the field was documented as privacy-protecting, but it is a behaviour change to an output column and deserves a maintainer decision.
Note
The documentation half of this is being corrected in a separate docs PR, which changes the text to describe what the code actually does. This issue tracks the underlying behaviour question.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the API rounding in codecarbon/core/api_client.py:245-246 with coordinate handling in codecarbon/emissions_tracker.py:385-386 and 1111-1112. The issue presents two possible resolutions, so confirm the maintainer’s decision first; done means the CSV behaviour is implemented or documented consistently with that decision and emissions.csv no longer contradicts the stated privacy guarantee.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100