[Feature Request]: Add a client notification for imprecise locations values outside of the ranges used by iOS and the public MQTT Server

[garthvh]

Platform

Cross-Platform

Description

The range used is 11-14 32 is full precision

[ianmcorvidae]

What's the benefit here? I guess I can see it for under-11 because those are pretty much just uselessly large, but 15-19 or so at least are still useful. There's not really much difference between higher than that and fully precise but they don't seem like a problem either. In the communities I'm part of & monitor, people who care about MQTT aren't using the public server because of the restrictions anyway. Perhaps this should be limited to those who are directly using the public server & have uplink enabled on the default channel?

[garthvh]

To prevent imprecise locations that are too detailed to obscure your location.

[ianmcorvidae]

If the proposal is to disallow imprecise values outside of the 11-14 range then I definitely oppose this. Many folks, perhaps even most, do not align their privacy thresholds with Apple policy or CCPA/GDPR legislation. Precision levels above 14 but less than 32 see significant use in my area.

[garthvh]

Why would anyone be using imprecise locations that are easily discoverable? Would love to see your data showing extensive use of options that can only be set from the cli, as a tiny fraction of configuration takes place from the python cli and android only allows 11-15

[esev]

I use a fixed position near my home for my "home base" node, and then set a precision of 16. I want folks to know what neighborhood/area it is in, and I want them to also know that it is not a precise location. I think I set this either from the web UI or from an admin command.

I want folks to know there is a fixed node nearby, without giving away my exact house location.

[garthvh]

I use a fixed position near my home for my "home base" node, and then set a precision of 16. I want folks to know what neighborhood/area it is in, and I want them to also know that it is not a precise location. I think I set this either from the web UI or from an admin command.

I want folks to know there is a fixed node nearby, without giving away my exact house location.

16 has given away your position, with the Android app your position can be easily determined. https://github.com/orgs/meshtastic/discussions/110

[esev]

I have a fixed position set. But the fixed position is at a park near my home. I want folks to know the park is not where the node is located, but is nearby, and so I set a precision of 16. I'm not trying to hide the fixed position that I've set. I'm just trying to let folks know that it isn't precise.

[garthvh]

I have a fixed position set. But the fixed position is at a park near my home. I want folks to know the park is not where the node is located, but is nearby, and so I set a precision of 16. I'm not trying to hide the fixed position that I've set. I'm just trying to let folks know that it isn't precise.

This would be an edge case that is lost, while better protecting user privacy. More than half of meshtastic users won't even see your node in this case as iOS and the public mqtt don't show this at all.

[fifieldt]

I do the same as @esev. It's also the approach a local community member who makes the solar nodes for interested volunteers suggests to newcomers. Though in Taipei we typically use 17 or 18 since it's so dense.

I've also seen a fun hide-and-seek variant using Meshtastic discussed that intended to use those 'mid' precisions :)

[esev]

This near-precise information is useful to our local net. It helps identify where packets are being received without giving up our fixed node locations. It helps me figure out the best way to optimize my antenna and node position to reach the mesh.

My main use-case isn't an app. It's our community meshview instance which is fed data from our local MQTT instance. It lets me see where my packets are being received from.

[ianmcorvidae]

The linked discussion reveals locations at any corner of four regions, regardless of precision. you would have exactly the same problem if you were at the corner of a precision-14 zone, or 11, or most anything. The very high precision numbers increase the number of places this happens, and that's all.

I also use precision 16, without need of a fixed position, which in my low-density urban area is still about a hundred houses. With a half-mile major street grid, precision 16 is pretty much identical to cross streets, since those give a value accurate to about a quarter mile, 1320 feet.

Like I said, different areas and people have different privacy thresholds. I'm not surprised to learn that higher density places use higher numbers than 16, either. In Taipei I bet a precision 17 area has more people & households than my precision 16 one does!

[ianmcorvidae]

also, Android allows quite a bit more than 11-15:

[thebentern]

Seems like this one isn't quite as cut and dry as previously assumed with the 15+ precision range. We should definitely take care of the < 11 range now though. Those do nothing but create eye-sores on a map.

[garthvh]

The linked discussion reveals locations at any corner of four regions, regardless of precision. you would have exactly the same problem if you were at the corner of a precision-14 zone, or 11, or most anything. The very high precision numbers increase the number of places this happens, and that's all.

I also use precision 16, without need of a fixed position, which in my low-density urban area is still about a hundred houses. With a half-mile major street grid, precision 16 is pretty much identical to cross streets, since those give a value accurate to about a quarter mile, 1320 feet.

Like I said, different areas and people have different privacy thresholds. I'm not surprised to learn that higher density places use higher numbers than 16, either. In Taipei I bet a precision 17 area has more people & households than my precision 16 one does!

With both 16 and 18 and positions from a device gps on an android phone my location is easily pinpointed once there are a couple hundred locations.

[caveman99]

Can we agree on the precision setting being a case of informed cconsent with a CCPA/GDPR-friendly default? Nobody should be prevented from setting something they intend to set, but with a sensinble privacy-default. The latter is given, the former not. CCPA/GDPR is not a ball-and-chain approach, if someone absolutely wants to broadcast their position, they should be allowed to.

[esev]

We can help users better understand the setting too. If we expect that 11-14 is considered an imprecise location and that 15-32 is considered a precise location, maybe that is something the UI can show. As the slider crosses between 14 & 15 the app could change the displayed text to show that the boundary between imprecise/precise has been crossed. It would help with making an informed decision.

Changing the defaults in the app and the firmware can help too. It still seems the Android app defaults to a precise location when the position is first enabled. I personally would have been more comfortable with a default of 11 after enabling position reporting. Then it can be changed to be more precise as desired.

Edit: Aside, I had a bad experience with my first t1000e. I don't know if the factory defaults for the t1000e are to use a precise location, or if I didn't change the default in the app, but I was surprised when it reported a very precise location. I think any change that avoids surprises would be beneficial. But I also like that I do have control over setting it more precisely when that is desired.

[ianmcorvidae]

Got away from the internet last night, will respond to several things at once here:

Can we agree on the precision setting being a case of informed cconsent with a CCPA/GDPR-friendly default? Nobody should be prevented from setting something they intend to set, but with a sensinble privacy-default. The latter is given, the former not. CCPA/GDPR is not a ball-and-chain approach, if someone absolutely wants to broadcast their position, they should be allowed to.

Agreed, 100%.

With both 16 and 18 and positions from a device gps on an android phone my location is easily pinpointed once there are a couple hundred locations.

I'd be curious to see the method of this for any case except sitting on an intersection of 4 precision zones or near an edge, which is the case in the linked discussion. If your position is far enough from the edge of any precision area that your GPS inaccuracy doesn't mean you appear to leave the zone, that shouldn't reveal information beyond the configured precision, and if you're near only one edge and not a corner it should only reveal that you're within GPS inaccuracy range of that one edge. If the zone is smaller than GPS inaccuracy, it'll probably show you in the zone you're actually in more often than inaccurate ones, and maybe you could statistically reason about which edges/corners someone is closer to based on how many appear in each of the 8 surrounding zones, but that's a far cry from it pinpointing the location. That case is more like "statistics could render the location more precise than your setting". Which does seem like something worth informing users about.

(And also to note again, when near edges and corners it doesn't matter what precision level you've set; sitting on the corner of 4 precision-11 zones will just create a bigger X over your basically-precise location in the log)

I think we could probably improve on this problem with some sort of flapping detection near edges of precision zones. But that would need some engineering, of course. Given that it applies to any precision setting, not just more precise settings, I think we probably should do that work. I'll see if I can put together a proposal.

We can help users better understand the setting too. If we expect that 11-14 is considered an imprecise location and that 15-32 is considered a precise location, maybe that is something the UI can show. As the slider crosses between 14 & 15 the app could change the displayed text to show that the boundary between imprecise/precise has been crossed. It would help with making an informed decision.

I like this idea a lot. I'd say that 20-32 are basically fully-precise, 15-19 or so are maybe "mostly precise", with 11-14 as truly imprecise. I think we should add the "mostly precise" category to clarify why someone might choose those rather than just setting it to full precision.

Possible 3.0 idea would be taking advantage of position precision to pack positions into less space over the air, somewhat relatedly. If the position was a single bytes field, full precision would take the same space as today (1 byte field tag, 1 byte length, 8 bytes actual data (4 per lat/lon), vs. today where it's two different field tags and two fixed32s that take 4 bytes each), but with position precision of 17-24 it could use 8 bytes (2+6), and with 9-16 could use only 6 (2+4). This would be another reason to use especially 16 or 24 instead of 32.

Changing the defaults in the app and the firmware can help too. It still seems the Android app defaults to a precise location when the position is first enabled. I personally would have been more comfortable with a default of 11 after enabling position reporting. Then it can be changed to be more precise as desired.

Also agreed. I think we set something like that for the default channel in firmware, but defaulting to something like that in the apps would improve this. As a default that can be overridden, it can also let us be more consistent between the default channel and new/private channels -- have everything default to whatever value we like but be configurable.