Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Make Location Sharing More Obvious #4539

Closed
ShakataGaNai opened this issue Aug 23, 2024 · 7 comments
Closed

[Feature Request]: Make Location Sharing More Obvious #4539

ShakataGaNai opened this issue Aug 23, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@ShakataGaNai
Copy link

ShakataGaNai commented Aug 23, 2024

Platform

NRF52, ESP32, RP2040

Description

Due to recent concerns about Meshtastic users data on mapping sites, it's clear that some users are enabling location sharing not understanding the implications of that (Ex: Their location is available to anyone in their area, or their location is now on the internet.). The general suggestion is as follows (based on #map conversation):

#1 - Disable location sharing by default. GPS may remain enabled for time sync purposes, but do not send out location over any channel by default.
#2 - When a user attempts to enable location sharing on the default encryption, prompt them with an accept/cancel popup. A disclaimed to the effect of "You are turned on location sharing to the default mesh. This means all other users in your area will be able to see your location. Your location information may also be uploaded to the internet or used in other ways. Are you sure?". This text might also link to a "Location 101" documentation page explaining the location sharing feature and how it is used, and where the data may go.

If the user is not using the default encryption, then do not provide warning.

This would only apply to iOS/Android. Users of the CLI/other are probably more technical less likely to mistakenly turn on sharing.

@ShakataGaNai ShakataGaNai added the enhancement New feature or request label Aug 23, 2024
@jrddunbr
Copy link

jrddunbr commented Aug 23, 2024

If the user is not using the default LongFast channel configuration, do not provide warning.

This is a bad idea. Many communities share a QR code for nonstandard channels w/h encryption and they will be blindsided.

@Talie5in
Copy link
Contributor

Talie5in commented Aug 23, 2024

Thanks @ShakataGaNai - Looks like what I was suggesting in the Discord Map channel here
https://discord.com/channels/867578229534359593/930915790746710116/1276420413999681626

I suggest any Default Channel, not just LongFast.

@ShakataGaNai
Copy link
Author

Thanks @jrddunbr @Talie5in I've adjusted it to say "Default encryption". Does that make more sense? I don't know if QR code configs can turn on location sharing, if they can then perhaps that should be changed. I just want to keep this FR scope super small. "How do we inform the users"

@Talie5in
Copy link
Contributor

Talie5in commented Aug 23, 2024

Adding this snippet too

<Position Disclaimer Pop Up>
ELSE
IF ENABLE POSITION DATA in Public Channels
<Position Disclaimer Pop Up>

MQTT Module:
Tick Box to Enable Sending Position Data (think this is already here (MAP Reporting)

I think not doing it based on GPS Enabled/Disabled hardware is counter intuitive,
 it's OK for the local device paired with the node to see their position, and means it 
provides a time source to the node/firmware.

@jrddunbr
Copy link

I think that it would be best implemented as a global setting for whether you transmit that data anywhere, and be restricted on sending that data to any location until you make a choice, and that it would be global everywhere at that level unless you override it for a channel configuration or a DM configuration. That's my two cents.

@garthvh
Copy link
Member

garthvh commented Aug 23, 2024

It is already a configuration, not sure how this will really solve any actual issues. The text as is is far to long and confusing for the mobile apps.

@garthvh
Copy link
Member

garthvh commented Aug 23, 2024

Related issue transferred to a discussion here #4546

@garthvh garthvh closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants