[benhartwich]

Builds on #5437 ("Hide Exact Location"), which is merged in here. It implements the proposal Eric agreed to in the comments below. Before merging we want input from other Discord users.

What the user sees

• New "Privacy & Sharing" tab in Allsky Settings. It holds the Allsky Map settings, "Hide Exact Location", "Share Usage Data", and "Contact Email". All are off or empty by default.

• "Map Sharing" replaces "Show on Map". It has three choices:

  • Don't send;
  • Send to the Allsky Team only;
  • Send and show on the Map.

  Upgrades convert "Show on Map" (true → map, false → none) in convert_settings_file().

• New WebUI "Privacy" page (Settings menu):

  • It's shown before any other page until the user has answered the current questions. Their version is ALLSKY_PRIVACY_VERSION in variables.sh; increase it when what is sent changes, and everyone is asked again. It isn't shown before Allsky is configured.
  • Nothing is pre-selected on the first visit, and "Yes" and "No" look the same.
  • It shows exactly what the Pi sends (postToMap.sh --show).
  • It has a "Delete my data from the Allsky server" button.

• The wording explains the benefit instead of pushing: "Sending your Map data, even without showing it, helps the Allsky Team decide where to spend development time."

• Docs: a rewritten settings/privacy.md, plus updates to settings/allsky.md and howtos/allsky_map.md. The _02 upgrade notes have cards for "Map Sharing", "Share Usage Data"/"Contact Email", and the Privacy page; there's no changelog entry.

Scripts

• One upload. postToMap.sh sends everything; postToData.sh is removed.
  • It runs at the end of night (every other day, as before) when anything is shared.
  • makeChanges.sh also runs it when a sharing choice or a Map field changes.
• Each choice's consent time is stored in the settings-only settings mapsharingconsent, usagedataconsent, and contactemailconsent (UTC). makeChanges.sh sets it when the choice is turned on and clears it when it's turned off.
• --show prints the JSON instead of sending it.
• --delete-all asks the server to delete everything for this Pi. If the server confirms, it sets "Map Sharing" to "Don't send", turns "Share Usage Data" off, and clears "Contact Email" and the consent times in all camera settings files.
• Local counts (Allsky starts, camera changes, and WebUI days) are always kept on the Pi. They're sent only with "Share Usage Data", and start over after a successful upload. Turning sharing off doesn't delete them.
• "Hide Exact Location" also applies to the copy of the settings and Website configuration that's sent. The Contact Email is removed from the settings copy; it's only sent on its own.
• The JSON is built with jq and sent with curl --data-binary @file, instead of eval with quote escaping.

Server side (Eric)

Everything goes to postToMap.php. The current Map fields keep their names and place at the top level, so the existing code keeps working for them.

Normal upload:

{
  "force": false,
  "machine_id": "…",
  "allsky_version": "v2026.10.01_02",
  "map_sharing": "none | team | map",
  "location": "…", "owner": "…", "latitude": "…", "longitude": "…",
  "website_url": "…", "image_url": "…", "camera": "…", "lens": "…",
  "computer": "…", "equipmentinfo": "…",
  "website_settings": { }, "allsky_settings": { },
  "usage": { "since": "2026-11-01", "os": "…", "computer": "…", "camera": "…",
             "cameras_connected": 1, "allsky_starts": 3, "camera_changes": 0,
             "webui_days": 2, "modules": { "night": ["allsky_overlay", "…"] } },
  "email": "…",
  "consent": { "privacy_version": 1, "map": "2026-11-04 10:00:00",
               "usage": "2026-11-04 10:00:01", "email": null }
}

• The Map fields (location … allsky_settings) are only present when map_sharing isn't none.
• Show the camera on the map only when map_sharing is map.
• usage: null means delete the Usage Data, and email: null means delete the email.
• A consent value is null when that item isn't shared.

Nothing shared any more: the existing delete request plus map_sharing:

{ "machine_id": "…", "website_url": "DELETE", "map_sharing": "none" }

As agreed, the server keeps the record marked as deleted.

Delete button: delete everything for this machine ID (Map data, Usage Data, email). Reply RETURN DELETED.

{ "machine_id": "…", "delete_all": true }

Replies: the same RETURN … lines as today.

Retention: the docs say that data from a Pi that hasn't sent anything for 12 months is deleted automatically, so the server needs that cleanup.

Testing

• postToMap.sh --show in a sandbox, with made-up locations, for each case:
  • team + Usage Data + email, with and without "Hide Exact Location";
  • "Don't send" with Usage Data and email;
  • nothing shared (the delete request);
  • --delete-all.
• Sending against a local test server:
  • a normal upload resets the counts;
  • --delete-all turns the settings off.
• ShellCheck with the CI's options reports nothing on the changed scripts. php -l passes on all PHP files.
• Not yet tested: the WebUI page and makeChanges.sh on a running Pi.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WCB72NisBJbcYhWokSnGH7

[Alex-developer]

We will look at this for _02 as there are a lot of considerations around GDPR that need to be considered before we can release this to the public,

[EricClaeys]

@benhartwich,
if 1 decimal place gets us within 11 km, how close does 2 decimal places get us? I would think anything within a km or two is sufficiently hidden.

[benhartwich]

@EricClaeys, two decimal places: 0.01° of latitude is 1.1 km. Rounding moves the point by at most about 0.55 km north–south and, at 50° latitude, about 0.36 km east–west. So the real location is within about 0.6 km of the shown point, in a cell of about 1.1 × 0.7 km. In a town that's many houses, but in the countryside such a cell may hold only a handful of buildings.

To match "a km or two", Hide Exact Location now rounds to the nearest 0.02° (0027f47 in #5437, rebased here). The real location is then within about 1.3 km, and the values still have 2 decimals, so nothing changes for the Map server. The docs and the Privacy page say so.

Thanks for the answers in #5437 about email and Usage Data. I'll start on the Allsky side here:

• ALLSKY_MAP_URL in variables.sh, used by postToMap.sh and the new script.
• New settings in the Privacy & Sharing tab, all off or empty by default: Share Usage Data and Contact Email, each with what is sent and why.
• A new postToData.sh that sends them to postToData.php, at the end of night like postToMap.sh and when the settings change. Turning a setting off sends a delete for that type. A --show option prints exactly what would be sent, so the Privacy page and a future "your shared data" page can display it.
• Counters for Allsky starts, camera changes and WebUI use, kept locally and sent only if Share Usage Data is on.

I'll put the request and reply format in the PR description so you can write postToData.php and deleteData.php against it.

About the machine ID: /etc/machine-id is meant to stay private on the system ("should be considered confidential", man machine-id), and other software uses it too. I suggest sending a hash of it plus a fixed Allsky string for the new data. The Map can keep the raw ID for now and switch later, since the delete script needs to match both.

[benhartwich]

@EricClaeys, the Allsky side of Usage Data and Contact Email is in (276e07a). The PR description now has the JSON format for postToData.php and deleteData.php, so you can write them against it. They reply with RETURN ... lines like postToMap.php does.

Both settings are off or empty by default, and nothing prompts for them yet. That leaves room for your idea of having the WebUI ask after an upgrade. Still open: how long the server keeps the data, and the WebUI page that shows the shared data with a delete button.

[EricClaeys]

For Usage Data and Email we may need to track when someone enabled them. And when they asked for that data to be deleted? Not sure about that.

Thanks for changing to 0.02 for hidden data.

Can postToMap.sh also send the email and usage data? Logically it's just adding a couple fields if the usage data is a json string like the allsky and Website settings.

When a user currently disables "Show on Map", the server marks the record as deleted and doesn't add the data to the map, but it doesn't actually delete the data. It's useful for us to know how many people have turned that setting off. I think from a user's perspective that setting only determines if their camera appears on the map. Can we keep that behavior but add an explicit "delete my map data" checkbox on the privacy page (or elsewhere)?
The email will be nulled out in the DB if the setting is empty.
For usage data will also be nulled out if that setting is disabled.
If we do the above I don't think we need `postToData.sh.

Turning Usage Data off also deletes the local counts.

I suggest leaving any local counts if we legally can - I could see where we might have Allsky look at the numbers and change its behaviourm.

How long the server keeps Usage Data and email addresses.

Can we keep the data forever or until the user deletes it?

Question: does a user clearing out the email field or disabling the "Show on Map or "Upload Usage Data fields constitute an official request to gave the data deleted on the server, or should we require them to explicitly press a "delete from server" button?

I'd think the WebUI is the best place for the prompts. Perhaps if determines it needs to prompt for anything, it displays the prompt page before showing any other page, so there's no way the user can't see the prompt.

And if after a year it needs to prompt again, it would show the same page.

Comments?

[EricClaeys]

Can a user elect to send the map data but not have it display on the map? That would be a good option: Send Map Dara but do not display", and Send and display Map data". I'd like to get as many people sending data as possible.

For the map prompt, I'd like to include a sentence like "The Allsky team STRONGLY suggests sending your Map data, even if you ask that it not be displayed on the Map". We use that data to help decide where to put our development efforts."

[benhartwich]

Thanks Eric, good points. Proposal:

One script. Agreed: postToMap.sh sends everything in one upload. The email and the Usage Data are optional fields that are only included when enabled. I'll drop postToData.sh and keep --show in postToMap.sh, so users can see exactly what is sent.

Consent time. Agreed. Each upload includes when each item was turned on, plus the version of the privacy text the user saw. That way we can show what someone agreed to and when.

Send Map data but not display it. Fine with me. I'd make it a choice in one setting rather than two checkboxes:

• Don't send
• Send to the Allsky Team only
• Send and show on the Map

For the wording, I'd explain the benefit rather than say "STRONGLY", e.g. "Sending your Map data, even without showing it, helps the Allsky Team decide where to spend development time." A neutral prompt keeps it clearly voluntary, which matters for consent under the GDPR.

Turning things off.

• Clearing the email or turning off Usage Data nulls that data on the server, as you said.
• Turning off display on the Map only hides the camera.
• A separate "Delete my data from the Allsky server" button in the WebUI deletes all of it (map, usage, email).

The privacy page will say this clearly. I'll keep the local counts on the Pi; they never leave it unless sharing is on.

How long we keep data. Forever is hard to justify under the GDPR, which requires storage to be limited. I'd suggest: kept until the user deletes it, or deleted automatically when a camera hasn't sent anything for 12 months. You still keep all active cameras and the history of who turned display off.

Prompts in the WebUI. Agreed: a page shown before any other page until the user answers, with "Yes" and "No" equally prominent. I'd ask again only when what we collect changes, not every year. Asking people who said no every year can feel like pressure.

If that works for you, I'll update #5444 to match. The server side (fields, nulling, delete, 12-month cleanup) would be yours.

[EricClaeys]

@benhartwich,
your proposal looks good. We still need to get input from other Discord users.

[benhartwich]

@EricClaeys, I updated this PR to match the proposal you agreed to:

• one upload in postToMap.sh;
• consent times;
• "Map Sharing" with three choices;
• a WebUI "Privacy" page that asks before any other page and has a delete button;
• the local counts are kept.

The description now has the JSON format for postToMap.php, including delete_all, so you can update the server side against it. It also merges the slimmed-down #5437, and the changelog entries are now cards in the _02 upgrade notes. I have not tested the WebUI page and makeChanges.sh on a running Pi yet.

When you ask the Discord users, the Privacy page and the "Privacy & Sharing" documentation page are probably the best things to show them.