Chronos > Software Dev
Updating the UI: Network / Remote Control Screen
DDR:
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. :D
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. ;D
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. :)
BiduleOhm:
For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
NiNeff:
--- Quote from: BiduleOhm on September 22, 2018, 06:53:24 AM ---For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
--- End quote ---
This is then just security by obscurity and therefore not really secure. It might also break (badly designed) stuff which relies on the defaults. I do however like the general idea to be able to change the port using the UI.
--- Quote from: DDR on September 21, 2018, 09:23:38 PM ---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.
--- End quote ---
Indeed, get rid of the locking. It's less stuff to implement and more screenspace!
--- Quote from: DDR on September 21, 2018, 09:23:38 PM ---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.
--- End quote ---
I also prefer version 2. However displaying 2 QR Codes next to each other is confusing and might be error-prone. Maybe only ever display one type of IP and add a button to switch? Like "display IPv6" ?
--- Quote from: DDR on September 21, 2018, 09:23:38 PM ---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.
--- End quote ---
Then perhaps call the button next interface or next adapter. I had to read your description to figure it out, but it should be obvious from just looking at the picture.
--- Quote from: DDR on September 21, 2018, 09:23:38 PM ---So, as always, please tell me you think. The best time to change designs is while they're still on the drawing board. :)
--- End quote ---
I like it in general!
BiduleOhm:
Of course it should not be the only element in your security, it's just a very simple way to avoid the majority of attacks.
DDR:
Thank you for the feedback, NiNeff and BiduleOhm. I've spent a few hours here going back and redesigning the screen, and it has really benefited. :D
Version 3:
--- Quote from: BiduleOhm on September 22, 2018, 01:53:34 PM ---Of course it should not be the only element in your security, it's just a very simple way to avoid the majority of attacks.
--- End quote ---
Exactly, BiduleOhm.
Re SSH:
--- Quote from: NiNeff on September 22, 2018, 12:06:07 PM ---It might also break (badly designed) stuff which relies on the defaults. I do however like the general idea to be able to change the port using the UI.
--- End quote ---
I've never come across anything that's been unable to deal with nonstandard SSH ports either, since it's so common. However, I can definitely see some networks could be locked down in weird ways. I've added it to the design. :)
--- Quote from: BiduleOhm on September 22, 2018, 06:53:24 AM ---For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
--- End quote ---
Hm, probably best to make it easy, then. Plus, I was able to add the actual command to connect in that space. :)
--- Quote from: NiNeff on September 22, 2018, 12:06:07 PM ---Indeed, get rid of the locking. It's less stuff to implement and more screenspace!
--- End quote ---
Gone! The illusion of security is worse than insecurity itself.
--- Quote from: NiNeff on September 22, 2018, 12:06:07 PM ---I also prefer version 2. However displaying 2 QR Codes next to each other is confusing and might be error-prone. Maybe only ever display one type of IP and add a button to switch? Like "display IPv6" ?
--- End quote ---
Given the relatively poor support of ipv6 overall, I've removed it from the GUI entirely. I think it would just cause confusion for the most part when it inevitably didn't work. ipv6 is still be available through the command-line interface, and it should be visible in the connected devices on your network as well.
--- Quote from: NiNeff on September 22, 2018, 12:06:07 PM ---Then perhaps call the button next interface or next adapter. I had to read your description to figure it out, but it should be obvious from just looking at the picture.
--- End quote ---
You're right. I've made a drop-down menu so you can select what network interface you're viewing. It says what you're connecting through, so you don't have to guess now. Thank you for calling me out on that. I think I did some rather bad design work there in retrospect.
Navigation
[0] Message Index
[#] Next page
Go to full version