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!
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.0release on the packaging front there will be an effort made to split
mepo-scriptswherein the former excludes all scripts such as the user positioning script.
Also note, in the current release of mepo you can use the
-ndccommandline flag to not apply the default configuration (and thus not report location to geoclue etc.) along with
-ito any apply custom config (which you can copy from the default config sans the user positioning shellpipe bit).
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.
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.
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_ENABLEDwhich can be set to
0to 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-scriptsas 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-violatingas you put it but users or packagers can set
~cnx the idea about
coordsviafunction being customizable for device-specific-purposes is also interesting as well and I would likely accept a patch to some effect of allowing custom
coordsviafunctions, 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
coordsviafunction might be one way to do this.