mlco2 / mlco2/codecarbon

Documented coordinate privacy protection is not applied to emissions.csv

Open
#1,376 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. 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.
  2. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.