Skip to content

Documented coordinate privacy protection is not applied to emissions.csv #1376

Description

@davidberenstein1957

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions