gluon icon indicating copy to clipboard operation
gluon copied to clipboard

Add option to hide owner info from statuspage

Open maurerle opened this issue 2 years ago • 3 comments

Owner info should not be able to crawl from public ipv6 addresses

This is a first draft to discuss the idea. Of course, an option in the wizard (or configurable in the site config) would also be needed.

maurerle avatar Aug 17 '22 19:08 maurerle

Hi @maurerle, thanks for the suggestion.

Wouldn't it make more sense to clarify in the config mode that this is publicized if there is confusion about this field?

And regarding the potential question why this is publicized, this should be related to the Pico Peering Agreement and the principle of decentralization which various Freifunk communities have signed up on: https://blog.freifunk.net/2015/05/15/memorandum-understanding/.

T-X avatar Aug 18 '22 20:08 T-X

Hi @T-X , in yanic one has the option to set no_owner = false to hide owner info on the published meshviewer.json/nodes.json But still allows that the infrastructure team can contact people if needed. This makes sure, that the contact info is not visible on the map.

Yet the info is still available by looking at the status page of the public ip addresses of nodes.

I'd like to be able to contact node owners based on yanics aggregation, but hide the contact address for people outside the mesh (on public ipv6 addresses for example).

This is already possible for the location (advertise location setting) - so I think its reasonable to provide the same function for the contact address too? I'd prefer a way to set this in the site.conf per community.

This is beneficial so that owners, who are comfortable with providing contact info to admins but not to the public, enter contact details instead of nothing at all.

maurerle avatar Aug 19 '22 16:08 maurerle

We visited ffbs last week, where they talked about their approach to the contact field; iirc they do (maybe optionally) not publish their nodeowner information to the statuspage and respondd, but have a second (authorized and encrypted) channel, where only their coreteam can access the owner information. That is not done automatically but once something is wrong with the device.

I think if an option like @maurerle suggested would encourage more people to leave 'some form' or even an enhanced version of contact info that would be a win, even if that is not how contact info is currently used.

AiyionPrime avatar Aug 28 '22 17:08 AiyionPrime

Hey @maurerle. We just talked about this PR in the developer meetup.

While we do see the benefit of a hidden contact option, we do not think to retrofit it into - and technically repurpose - the owner field is the right way to achieve your goal.

If you really want it, we suggest the introduction of a new field, that does not get shared via statuspage and respondd but is only accessible to core-members of the community through a separate channel. I'd recommend discussing how to implement such channel in an issue - before doing it; it might become opinionated, and longer than you'd like. Again I'd recommend taking a look at ffbs and their ssh implementation; @lemoer at one point drafted encrypted or signed respondd messages, neither made it in yet, but maybe your usecase gives that a new spin.

As this PR is rather short, I'd close it at this point until and if you intend to pick this up again on a larger scale. Thanks for your contribution!

AiyionPrime avatar Feb 15 '23 23:02 AiyionPrime