[benhartwich]

Closes #5436.

Update: As discussed with Eric, this PR now only adds "Hide Exact Location". The installer's Allsky Map prompt and its showonmapdeclined setting are removed, since the prompt will move to the WebUI (#5444). The changelog is no longer updated, so the new setting is described in the v2026.10.01_02 upgrade notes instead.

Hide Exact Location

• The new boolean setting hideexactlocation sits right after ==Latitude== and ==Longitude==.
• When it's on, the Allsky Map and the local and remote Websites get the latitude and longitude rounded to the nearest 0.02 degrees, so they're at most about 1.3 km (0.8 miles) off. The settings file keeps the exact values, and sunwait and everything else in Allsky still use them.
• The new getPublicLatLong() in functions.sh (convertLatLong plus rounding, locale-safe) is the one place this is calculated. It's used by:
  • postToMap.sh, every time it runs;
  • makeChanges.sh, for latitude/longitude and for the new hideexactlocation case, which updates both values in the configuration.json files and uploads the remote one;
  • replace_website_placeholders(), when a new Website configuration file is created.
• postToMap.sh also sends the whole settings file and the Website configuration to the map server, and both contain the exact location. When the setting is on, the location in that copy is replaced by the rounded values.
• ==Show on Map== and ==Hide Exact Location== are kept the same in all camera-specific settings files (update_all_settings_files()), since there's only one map entry per Pi.

Not changed

• Overlays that show ${LATITUDE}/${LONGITUDE} (mentioned in the docs).
• The Allsky Sensor Server payload in allsky_shared.py.

Docs

• settings/allsky.md: new row; the Longitude text now points to the setting instead of "change the values slightly".
• howtos/allsky_map.md: new section "Hiding your exact location".
• upgrade/v2026.10.01_02.md: a "NEW" card under Settings.
• In html/docs I only patched the changed content, because a full mkdocs build changes the navigation of many pages.

Testing

• getPublicLatLong: tested with signed and NSEW values, a comma decimal point, and a German locale.
• public_location in postToMap.sh: tested with a settings file and a configuration.json.
• bash -n passes on all changed scripts. ShellCheck has no new warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WCB72NisBJbcYhWokSnGH7

[EricClaeys]

Putting showonmapdeclined in the settings file is fine for now. At some point I'd like to separate the camera-related settings like "exposure" and non-camera settings like thumbnail sort order and showonmapdeclined. There would then be a "global" settings file and one or more camera-specific files. The "carryforward" field in the options file more or less indicates which settings I thought were global when I added the field a few years ago.
In the meantime, would it make sense to update "showonmap" and "showonmapdeclined" in all existing settings files (I realize not many people have multiple cameras, but some of us testers do)?

Can hidelocation be named hideexactlocation to better reflect what it does?

Sorry, I should have been clear when I asked about this, let's target v2026.10.01_02.

On the Discord server we talked about prompting to upload other data as well that would only be used by the Allsky team and not appear on the map. For example, an email address and some yet-to-be-defined usage data. So the prompts would be for the Map data, an email address, and usage data (would need a better name).
We should probably have a "privacy" page that describes the information uploaded as a result of each of the prompts/settings as well as what we do with it. And something to deal with other GDPR requirements.

If we had multiple prompts, should each one have a "declined" setting, or should there be one setting with multiple semi-colon separated fields?
And with multiple prompts to upload data plus additional fields for GDPR, we may want a new section in the WebUI.

Do these changes make sense?

[benhartwich]

Thanks, done in f92e283:

• Renamed to hideexactlocation.
• All settings files: the new update_all_settings_files() (in installUpgradeFunctions.sh) updates a setting in the settings file and in every camera-specific settings_*.json. It skips the one the settings file links to.
  • install.sh uses it for showonmap, showonmapdeclined, and hideexactlocation.
  • makeChanges.sh uses it when showonmap or hideexactlocation is changed in the WebUI, so switching cameras doesn't bring the camera back onto (or off) the map.
  • Tested with two camera files and the symlink: both files get the new values and the link is kept.
• v2026.10.01_02: there's no such branch yet. I'll change the base and move the changelog entry from _01 to a _02 section once it exists.

On the other ideas:

• One "declined" setting per prompt (showonmapdeclined, emaildeclined, ...) rather than one setting with ;-separated fields. That way each can be read with settings/jq directly, carried forward on its own, and new prompts can be added without changing a format. They'd move to the "global" settings file later.

• A new WebUI section, e.g. "Privacy & Sharing", makes sense. It would hold Show on Map, Hide Exact Location, the email address, and the usage-data setting, each with a short "what is sent and why" text that links to the privacy page.

• The privacy page should list, per prompt or setting:

  • what is uploaded;
  • where it goes (thomasjacquin.com map server, Allsky team);
  • what it's used for;
  • how long it's kept;
  • how to have it deleted (e.g. postToMap.sh --delete for the map).

  GDPR also needs:

  • consent that is opt-in (default "No", which this PR already does) and that can be withdrawn as easily as it was given;
  • a contact for deletion requests;
  • for the email address, a stated purpose.

I'd suggest doing those in a separate PR once this one is merged, so this one stays small. Should I start on that? A name for the usage data could be "anonymous usage statistics".

[EricClaeys]

Thanks for the changes Ben. I agree with your other ideas.

Not in this PR, but shouldn't makeChanges.sh call update_all_settings_files() for all "global" settings, not just showonmap, showonmapdeclined, and hideexactlocation? Basically any setting with the "carryforward" field set?

I like the name "Privacy & Sharing" for the new WebUI section. I'm thinking all the Map fields should go there, ideally in an "AllskyMap" subsection. The other settings could go in an "Anonymous Data" subsection.

"anonymous usage statistics" is long for a setting label in the WebUI, especially on phones. How about "Usage Data"?

If you could start on this I'd appreciate it. _01 should be out 1 November at which point Alex will create _02.

[benhartwich]

Agreed on all points, "Usage Data" it is. I'll start on it in a new branch on top of this PR.

Plan

1. A new Privacy & Sharing header in options.json.repo:
   • an Allsky Map sub-header with all the Map fields (Show on Map, Hide Exact Location, Location, Owner, Lens, ...);
   • an Anonymous Data sub-header with ==Email Address== and ==Usage Data==.
2. Installer prompts for the email address and Usage Data, built like the Map prompt:
   • default "No";
   • each with its own ...declined date;
   • asked again after a year.
3. A Privacy documentation page. For each setting it says what is sent, where it goes, what it's used for, how long it's kept, and how to have it deleted. It also covers the GDPR points. Each setting's description links to it.
4. The carryforward → update_all_settings_files() change in makeChanges.sh, as a separate PR.

Questions before I add the two new settings

• Where should the email address and the Usage Data go? The Map uses thomasjacquin.com/allsky-map/postToMap.php. Is there, or will there be, an Allsky team endpoint? Until there is one I'd only store the settings and not send anything.
• What should Usage Data contain? My suggestion, all without location or identity:
  • Allsky version;
  • Pi model and OS;
  • camera type and model;
  • which features and modules are enabled;
  • the machine-id hashed, so repeated reports can be counted without identifying the Pi.
• Who is the contact for deletion requests and the "controller" in GDPR terms? You, Alex, or the AllskyTeam org? This goes on the privacy page.
• What is the email address for? Release notices only, or replies to support questions too? GDPR needs the purpose stated.

Items 1 and 3 (for the Map) and 4 don't depend on these answers, so I'll do them first.

[EricClaeys]

Just thinking out loud, so don't do anything yet...

For # 2, rather than have the installer prompt for new settings, can we have the WebUI force the user to fill in the new fields?
After installing a release with new settings it forces users to review the settings, or at least click on the blue button:

It would be nice to have the WebUI say something like "There are 5 new settings, highlighted below. You must set them before Allsky will start.". If we set their new values to "NEW_SETTING" the WebUI would show the field with OUT anything selected, forcing the user to select something. That something may be to clear the field, like with email. Or select Yes/No to a "Do you want to..." field.

The WebUI also highlights new fields, at least when changing cameras to one that hasn't seen the new settings.

It would be nice for the prompting to be done in the WebUI if possible.

[EricClaeys]

Where should the email address and the Usage Data go?

To the Allsky Map server (thomasjacquin.com). I'll create a new postToData.php script to handle the data. The script will return a string indicating success or failure, similar in concept to postToMap.sh returning "UPDATED 1 5" or "INSERTED" or "DELETED". Can we store the machine ID with this data like we do for the Map data?
The string https://www.thomasjacquin.com/allsky-map/ should go in variables.sh since it will now be used by this new mechanism as well as by postToMap.sh. In both cases the scripts would create the final URL by appending their respective PHP scripts to the map URL.

What should Usage Data contain?

• Pi OS. The Map data already contains the Allsky version, Pi model, camera info, and machine id. The machine id isn't hashed - does it need to be?
• Enabled modules - probably just the module name
• Which features did you have in mind?
• Regarding usage statistics, I have thought about it much, but maybe the number of times they use the WebUI, how often they start Allsky (a huge number may indicate a problem), how often they change cameras, how many cameras they have connected to the Pi.

Who is the contact for deletion requests and the "controller" in GDPR terms?

Deletion requests: Can we use a URL to a new page that lists the data the user is sharing along with a "delete" button that would send a request to a new deleteData.php script on the Map server? If so, we should add a link in the new "Privacy" page to the "delete" page. And a link to the "Privacy" page. The new script will need to be given the machine ID as well as the type of data to delete (map, usage, email), or "all").

Controller: The core Allsky team. Can the GitHub/Discussions URL be used?

What is the email address for?

It's so the Allsky developers can contact users when we notice a problem with their data or have a question about their data and/or setup. While looking at the map data and noticing something strange, I've wished I had a way to contact the user.
The email would not be used for marketing or other purposes, nor will it be shared outside the core Allsky team.
I don't think we need email for release notices since _02 will contain an improved new release notification system, and it checks every 12 hours.
I could see using the email to ask for help testing new release, or asking what features users would like added, but I wouldn't want to send too many mails and hassle users.
Another possible use would be to notify users of security issues like the recent PHP2Shell bug.