Wishlist: Personal WebRTC Server
The support of WebRTC in web browsers allows video chats to be conducted directly browser-to-browser. However, a service is still required to initiate the connection between the browsers.
But since the server has no involvement once the session is started, demands on such a server are obviously much lower than they would be if all session traffic had to transit the server.
In other words, a WebRTC connection service can be offered from considerably less powerful hardware than would be required to channel audiovisual streams for each connected chat.
My wish is for something “lightweight” that I can manage on my own platform. To keep things simple, I’m comfortable relying on “security by obscurity” measures instead of having to manage user accounts and the issues entailed in that. I conceive this as being something I would use to communicate with any of just a handful of people.
And the software would need to be under a Free/Libre and Open Source Licence (FLOSS) before I would consider it.
Manual Configuration
I’d prefer to have all configuration done via text editing of configuration files. No configurability should be exposed through the web service itself. There shouldn’t be too much to do, and it will be that much less in the web interface in which to find exploitable flaws.
Secure Communications
The WebRTC specification assumes all communication will be secured. Among options to consider:
A configuration option could point to the location of a certificate already on the server for other purposes.
Automate the use of a Let’s Encrypt certificate might leave one less thing to go wrong.
A self-signed certificate might be an option, although these are becoming more problemmatic as the handling of certificates in browsers is strengthened.
Configurable Port#
Even after subtracting port#s that might be used on a small, personal server, there are still easily over 60,000 choices.
Add a reasonably aggressive firewall, with a low threshold for blocking an IP# that appears to be scanning the server’s ports, and finding the port will be largely a matter of luck.
And if it gets found, it can be quickly changed.
Alternative: “Hidden” Subdirectory
Another possibility would be something that could be dropped into a “hidden” subdirectory of an existing web service. In similar fashion to the hidden port#, the subdirectory would be something I share with those I want to use the service. It should otherwise have no discoverable link, directly or indirectly, to the web service’s home page.
And again, if it gets found, it could be quickly changed.
But I prefer the idea of this running as an independent service, on its own port#.
Standard User Interface
Anyone connecting to the https://server:port with a browser should be greeted by a very simple web page. The page would allow the person to enter some identifying information, and then select a “chat request” button.
At that point the web page will simply wait for me, as an administrator, to select that person to start a chat.
Administrative User Interface
I would connect to https://server:port/something-configurable and be presented with a web page listing all of those sitting on the standard user page requesting a connection. The minimum information it should show for each includes:
the identifying information entered by the person;
the IP address from which they are connected;
the results of a reverse-DNS lookup on that IP address; and
the geolocation associated with that IP address.
Each would also have a button to allow me to initiate a WebRTC session with that person.
The something-configurable is again something that could be quickly and easily changed if it is ever discovered.
Alternative: “Hidden” Directory
If this option, described above, is chosen, the “something-configurable” would be under the hidden directory.
Possible Enhancements
Described above is what I see as a minimum for the service. But the following are some of the options that might be added to enhance its utility while still keeping it “lightweight.”
Automatic Geoblocking
Knowing who I want using it, I presumably know where they are (or will be). Being able to “whitelist” geographic locations from which connections are allowed seems an obvious useful addition.
Permitted User Names
In similar fashion, I might predefine the names I expect to have entered in the Standard User Interface described above. The entry of anything else should be silently ignored in some fashion. Returning the web page that a standard user sees while they wait would be okay. However, on the Administrator page they should be listed in a fashion that identifies them, but does not allow a call to be initiated with them.
Multiple Administrators
I could see some value in letting, say, family members also use this for their own contacts. I could configure another instance on a different port# (or, in the Hidden Directory case, a difference directory).
Or, perhaps, the same service could be used by adding a second field to the Standard User Interface form in which someone could indicate who they wish to contact. As more of the “security by obscurity” nature, I’d want them to type the name in, and not be offered a list of valid choices.
Each administrator name would be mapped to a different “something-configurable” as described for the Administrative User Interface.
Each administrator should be configurable with their own Permitted User Names when that feature is provided. Names may overlap between the lists.
In this case, one administrator should be the “super administrator,” and only that administrator would see any attempts to tap into the service incorrectly.