Gluon has a single interface to configure node information like location or contact info. This is done in config mode, a distinct operating mode of each node that can only be accessed by pressing button and physically connecting a network cable, while disrupting normal mesh operation at the same time. While this is feasible on planned installation it is less suited for ad-hoc setups of new nodes and while moving nodes.
A core principle of most Gluon-based firmwares is to prevent any accidental access to a node's config during normal operation, except for signed automatic updates. While users are free set a password or add a SSH key, there is no default password. We'd not like to encourage users to set passwords, either. Passwords are likely to be unsafe yet granting full root access to a node so we'd like to keep that attack vector as small as possible.
Most communities would like to have coordinates and contact information set for all nodes. At good map seems to stimulate a communities growth quite a bit and node operators contacting each other helps decentralization of communication. Changing a node's location by first having to enter config mode is cumbersome (think nodes a high and remote locations without a RC copter ready for pushing the button).
I imagine setting the coordinates of a node from a map during normal operation just by dragging the node's marker around and confirming the new location by clicking "Place node here" and entering a secret token. This could be done from meshviewer or any other map implementing a certain API. In the future, this may even be integrated into the status page.
One may ask why we can't provide a simple web interface, protected by a password, after all there is already a status page accessible during normal operation served by the very same webserver serving config mode. Well, put simply: This can never be secure due to:
- man-in-the-middle attacks
- no SSL possible
- potential password re-use
So what is the real problem here? The user must authenticate a command sent to the node. This command may be "Set location to x, y." or "Disable sharing of location data". There is no need for a detailed response from the node other than "Yep, I did whatever you just told me to do" and there's no need to query location information either (in case when sharing is disabled but a location is set).
We'll define a simple HTTP API for setting:
- set_location(lat, lon, alt): location data
- share_location(bool): enabling and disabling sharing of location data
- set_owner_contact(string): setting owner information
Each endpoint will respond either with "200 OK" or "401 Unauthorized".
A request will be authenticated using HMAC and a time-based One-time-password (RFC 6238).That is, users will just enter a 6 digit OTP from their OTP device (smartphones can do this) to authenticate a request. This eliminates man-in-the-middle attacks.
Users will be shown a QR code and textual representation of the code for setting up their OTP devices during config mode. They would also be able to generate a new code (invalidating the previous one) or disable the feature altogether.
The actual update request(s) need to be completely encapsulated inside the http payload, so we are able to handle multiple requests as one transaction in a single http request. This is important, so that we can change multiple things but only use a single one-time password.
Repeatedly asking the user for a new one-time password for each option changed is unfeasible.