So, something I just realized here is that - now that we have Debian up and running - we need a way to configure network access. This covers HTTP for the web app, the HTTP control API itself, and SSH access to the root of the camera. Now, a word of warning - I'm a UI designer, not a network admin or security expert, so I'm actually somewhat unsure of this design. Please call me out on my mistakes.
For configuring access to the web interface, it wouldn't do if just anyone could log on to our cameras and control them by default. Someone might go and make
a web page that gave you control of a random camera, and we wouldn't want that. I figure requiring a password to be set before enabling web control will avoid that problem nicely. It's also probably all we can do anyway, since anything more, such as 2-factor authentication, is much more effort and complexity than it's worth in this scenario. We may not be able to use HTTPS anyway, so whatever credentials are set will somehow wind up transmitted in plain text anyway. We can hash the password, at least, but it's still fundamentally insecure. This would be all fine over a local network without access to the internet at large, but the internet has a habit of getting into places it shouldn't.
Realistically… though… it would probably be fine. But still. Sheesh. I'd like to do this properly if I can.
For SSH access to a Linux machine, given the amount of malware that's out there trying to log on to everything, best practise is to use key-based authentication. We could use a password, but I think that is inviting disaster given the sheer volume of shit that will be thrown at the camera. Since anyone wanting to SSH into the camera will probably have used SSH before, and since key-based authentication is quite common, I assume it's quite reasonable to require it to access the Chronos CLI.
We could have a password and *then* let you set up key-based authentication on your own, but I think most people will honestly just set the password and get on with whatever they need to do.
Connecting via the MiniUSB would bypass all access control. Since you have physical access, you could just reprogram the camera firmware anyway, so there's no reason to deal with any of this.
With all this in mind, I've mocked up two versions of a network control screen.
Version 1:
In version 1, we've laid out remote control, api access, and ssh access authentication.
Tapping on one of the SSH keys in the list will highlight it and show an X, and tapping the X will delete that key so it can't be used to log on anymore. (All keys grant access to log on as the root user.
This can be changed later by logging on and setting up users as you want, if you want. Since the Chronos is running a Debian Linux under the hood in this instance, you can do whatever you'd do on a traditional server. I don't really anticipate wanting to manage users though, so I've made no allowances for it in the UI.)
I've made the screen lockable, not that it's worth very much since anyone can pop out the system MicroSD card and fiddle with the saved settings on it. I might just remove the button entirely, since perhaps it confers a false sense of security.
You can also click the underlined address to bring up a QR code. I don't like typing things in, much simpler to just scan and be taken to the mobile app.
Version 2:
In version 2, which I like quite a bit more, I unified the HTTP API and web app controls. The web app uses the HTTP API to control the camera, so you can't really have one without the other. I figure if you're just using the HTTP API, it's not a big deal if the web app is being served in the background. You can just ignore it. Unifying the controls also freed up enough space to display the IPv4 and IPv6 addresses' QR codes on screen, which I think is less confusing. We don't use the underline anywhere else in the back-of-camera UI.
One alternative to this layout might be to drop IPv6 address entirely () and put a longer description in that space. It would be nice to use IPv6 to expose the cameras on the internet, though, since stable IPv4 addresses are getting harder to come by these days.
Note: The web address section only shows up after you've enabled the network interface. The "Next Address" button only shows up if there's more than one active network interface - ie, you've plugged in MicroUSB and Ethernet, and maybe WiFi if we can get it working reliably. It'll cycle through the things which are plugged in.
So, as always, please tell me you think. The best time to change designs is while they're still on the drawing board.
Show Posts
We do like the idea of saving at a reduced bit depth, but it would be a fairly far future thing if we did it. Unfortunately, there are several other things that need our attention first. Motion triggering, (most of the) text overlay, power control, etc.