Add more local data

[fabricedesre]

The box should also send the port number it's listening on, and maybe the local hostname in addition to the local ip.

[cr]

Perhaps every Foxbox should be using a unique and sufficiently strong random ID for registration. This enables a few nice features on the registration server side:

• It can more reliably detect external IP address changes, for example due to DSL reconnects.
• It can more reliably detect and handle internal IP changes which sometimes occur under common home network DHCP regimes.
• It can better handle multi stack environments (IPv4 and IPv6).
• It can more easily detect and mitigate malicious behavior. For that the registration should use TLS and the original registration ID must not be returned in pings.

[fabricedesre]

UniqueID == risk of tracking ! I'd like to avoid that if possible.

Being somewhat more aggressive with the re-registration from the client and eviction on the server should mitigate your first 2 points in practice (eg. every 5 minutes).
I'm not sure how the last 2 are issues. Which kind of malicious behavior are you thinking about?

[michielbdejong]

We might want to deploy some type of API key or signed client-cert which allows the Box to connect to http://knilxof.org:4242/register?ip=192.168.0.42, so that not just anybody can pretend to be a Box.

[arcturus]

Also, what about registering what's my public name if registered against any proxy solution we could have. (Until the dynamic dns solution is in place)

[michielbdejong]

Also, what about registering what's my public name if registered against any proxy solution we could have. (Until the dynamic dns solution is in place)

Yes, we need that. Right now the Box registers its local IP address. Instead, it should register its public-local DNS host (whether dynamic or not).

I'll prepare a PR for this.

[michielbdejong]

Update: @arcturus mentioned on irc that he wants to keep the interaction-less flow as an option, even after gate 1.

We can however harden this server by requiring the Box to authenticate when registering (with a client cert for instance).

Another hardening option would be white-listing/black-listing CORS origins. For instance, the registration server instance could have an interface where an app developer registers the origin of their web app; if we see abuse, we revoke API access for that origin.