[Feature Request] Add privacy preferences to the protocol headers(s)

[Cisien]

I would like to see a flag added to the header of all meshcore packets (if not the main header, then the payload header) which indicates that a user wants privacy to be respected.

This value should default to "true", and would be something that the user can configure.

What this flag does is signals the user's desire to allow other entities to do things with the data their radios send out.

The current implementation of the phone app could benefit from this setting to know whether actions such as sharing a contact (to the map, clipboard, local flood) should be allowed, and can be used as an indicator to dilute the precision of that user's location. The firmware could use this flag for obfuscating GPS position as well.

My use case:
I want to expand on the excellent start of Andrew's work on https://github.com/Andrew-a-g/meshcoretomqtt and decode/send a bit more detailed data to MQTT. In order to do this in a way that respects everyone's choice I need a way for the user's to opt-in to this kind of sharing.

This flag would provide a way for the user's to consent in an opt-in basis.

The current path I'm exploring to move forward with the idea is to have users that wish to participate add a ^ character at the end of their display name. This clutters display names, as well as adds a constraint on their freedom to chose their node name. Additionally it takes 8 bits on the packet instead of 1.

[mattsains]

I think this is a good idea but we should be clear about what “privacy” means here. What are the expectations when it is enabled, and what’s allowed when it’s disabled? I think your example of not allowing publishing adverts to the map is a good one.

Maybe a slight name change from “privacy mode” to “private mode” would help to clarify the expectations here

[Cisien]

good suggestion on the name.

I think the intent is that users get a choice on whether their data should be sent off-mesh. Of course this doesn't stop bad actors, but it will at least help those of us with good intentions respect the user's choices.

[mattsains]

To me, “private mode” sounds like it means more than “stays on the mesh mode”

[Cisien]

maybe multiple flags are needed to cover the various use cases?

[mattsains]

That’s what I was thinking too. I think it’d be hard to choose the exact right feature tradeoff for a single private mode that would satisfy everyone. Imagine someone wanting to use MeshCore for precise GPS tracking but don’t want anyone on the internet seeing it, is that “private” or not? I think if we think about specific things that we will or will not do, that’s a better approach

[mattsains]

(We don’t have to implement all of them, but I think private/privacy is a broad topic)

[Cisien]

just to take a stab at defining a few things:

• allow my data to be used off-mesh
• allow contact sharing
• allow map sharing (off-mesh maps)
• allow message sharing (off-mesh)

probably only relevant in the advert payload:

• position is reduced precision [maybe with another field indicating the precision]
• clients should reduce precision when sharing [with a field indicating how much to reduce precision]

[jbrazio]

I want to expand on the excellent start of Andrew's work (..) and decode/send a bit more detailed data to MQTT

Please use Meshtastic instead, thanks.

[mattsains]

I want to expand on the excellent start of Andrew's work (..) and decode/send a bit more detailed data to MQTT

Please use Meshtastic instead, thanks.

To me, this seems like quite a dismissive and unhelpful reply. I’m sure you didn’t mean it that way. As a newer community member, seeing replies like that really makes me second guess my contributions to this project.

Why is exporting data to mqtt so incompatible with meshcore? Please keep in mind that nobody is suggesting publishing mqtt data onto the mesh, that would obviously be a mistake.

[Cisien]

I want to expand on the excellent start of Andrew's work (..) and decode/send a bit more detailed data to MQTT

Please use Meshtastic instead, thanks.

This feature request has nothing to do with MQTT. This feature request is to get user preferences for how to treat their data into the protocol.

[jbrazio]

If you want to publish data to mqtt, why not use a connector outside of the core protocol ? In the same sense you have the companion app "outside" of the core protocol.

Meshcore is already quite private by default over RF, unless you speak on the public channel or do a flood advert.. your privacy is kept.

[Cisien]

Again, this request has absolutely nothing to do with MQTT. This request is all about allowing users to communicate their preferences.

The only thing that's private is DM and room server chat. There's a lot of info in the protocol that is sent clear, including source and destination nodes, location data, identity (to the extent provided in the name), etc. This info can be collected to build a "who's talking to who" map if someone wanted.

Whether I passively observe propagation with a companion app, or by looking at the raw protocol doesn't change that currently users have no mechanism in which to communicate their preference for data sharing. This can only be addressed by extending the protocol.

This request is asking for 1 byte in the packet.