make reporting user location to geoclue and mozilla opt-in rather than opt-out

This is such an awesome project!

However it looks as if, by default, this program reports the user's location to geoclue and/or mozilla immediately upon startup (or perhaps as soon as the user drags the map) without asking for permission first.

Would it be possible to make this opt-in rather than opt-out? Or offer an option for downstream distributions to compile mepo such that location reporting is opt-in?

Thanks again for such an awesome project!

Assigned to
2 months ago
2 months ago

~mil 2 months ago

Thanks for your intrest in mepo ! It likely won't be the default to make user location positioning support as opt-in rather then opt-out as project goal is to aim for good sensible / usable defaults.

However, it should be noted for the 1.0 release on the packaging front there will be an effort made to split mepo from mepo-scripts wherein the former excludes all scripts such as the user positioning script.

Also note, in the current release of mepo you can use the -ndc commandline flag to not apply the default configuration (and thus not report location to geoclue etc.) along with -i to any apply custom config (which you can copy from the default config sans the user positioning shellpipe bit).

~mil REPORTED BY_DESIGN 2 months ago

~cnx 2 months ago

I think location positioning is device-specific, so it would make sense to decouple the coordsvia* functions into separate script and symlink one to mepo_get_coords.sh.

IMHO it is the easiest way to let users easily configure the service while allowing downstream to patch consistently. Moreover, we can avoid making calls that always fail on certain systems.

~amjoseph 2 months ago

It likely won't be the default to make user location positioning support as opt-in rather then opt-out as project goal is to aim for good sensible / usable defaults.

It makes me very sad to hear this.

Reporting my location and nearby wifi BSSIDs to third parties without asking me does not seem good or sensible. Mepo 0.4 did not do this. Then when I upgraded to Mepo 0.5 it started doing this without asking me or even letting me know that there had been a change in behavior. I do not think that this is a sensible or usable default. It's your decision of course. But a policy like this makes it very difficult for me to recommend Mepo to others.

The remainder of your comment contained instructions on how to opt-out. That's nice, but it doesn't address the problem that future versions of Mepo might add yet more privacy-violating-by-default features, which would need their own opt-outs. So every upgrade becomes a treacherous action.

I do hope you will reconsider this decision.

~mil 2 months ago

In the next release / 1.0, I'm planning to introduce customization of the scripts endpoints via ENV vars. In addition I've added an ENV var MEPO_USERPIN_ENABLED which can be set to 0 to disable the user positioning script functionality all together. The work-in-progress documentation can be seen here: https://git.sr.ht/~mil/mepo_website/tree/master/item/src/pages/userguide.md#overridable-script-env-variables ..or you can reference the master script here: https://git.sr.ht/~mil/mepo/tree/master/item/scripts/mepo_ui_menu_user_pin_updater.sh . I think this is a nice middleground for users since most users will expect location positioning to work by default and good sensible defaults is a explicit project goal. However this allows advanced users to opt out simply by setting an ENV var. Alternatively, the user can choose not to use mepo-scripts as well if they don't desire this functionality as well as described earlier.

~amjoseph reporting of wifi BSSIDs or similar is something that'd be handled by geoclue, which is just an optional dependency and things function fine without geoclue. The script uses gpsd, geoclue, or MLS (simple curl). I don't consider this privacy-violating as you put it but users or packagers can set MEPO_USERPIN_ENABLED to 0 if necessary.

~cnx the idea about coordsvia function being customizable for device-specific-purposes is also interesting as well and I would likely accept a patch to some effect of allowing custom coordsvia functions, but I think keeping things in one-script is ideal for simplicity sake. An ENV var set that references another script in PATH or to run that serves as the coordsvia function might be one way to do this.

Register here or Log in to comment, or comment via email.