I recently worked on a custom hardware project for the display of digital art. This was a standalone component where the idea was that a customer would buy the hardware, put it in their home, connect it to their local WiFi network, and be able to control it from either an iOS client, or a web browser.
One of the specific aspects I worked on was discovery of and communication with the hardware via a web browser. What quickly became apparent was that web browsers are sandboxed (for good reasons) in a number of ways that made this more difficult than it sounds.
Sending a UDP packet violates basic browser security. Therefore, sending an M-Search request for DIAL discovery is not currently possible from the browser. After some further investigation, I found there is a W3 standard for discovering network services. Unfortunately, this is not implemented in any major browser despite the standard and implementation requests for this dating from 2009. Chrome apps can be enabled to issue multicast requests, but not Chrome extensions, and the separate UI required for a Chrome app vs an extension was not an acceptable user experience.
At this point I was fairly frustrated. I eventually had to bite the bullet and implement a non-ideal solution involving the hardware reporting itself to a centralized server, the browser querying the server, and the server returning devices that have reported themselves from that same public IP. This is not ideal for a variety of reasons, but given the constraints, it was deemed an acceptable solution.
HTTPs and HTTP
The next hurdle involved HTTPS (SSL). The entire web application is served over HTTPS. Pages served over HTTPS can not load content from non-HTTPS sources, and any AJAX requests to non-HTTPS endpoints are blocked by the browser. The hardware would not be able to serve HTTPS, as that requires the browser to trust its SSL certificate. The hardware only had a local IP address on the network, and therefore could not be issued a certificate from a trusted Certificate Authority. We experimented using a self-signed certificate, but this yielded a big ugly browser warning the first time a user tried to contact the hardware, since the certificate was not trusted by the browser. This was not an acceptable user experience, so an alternative had to be found.
As can be seen above, the extension exists within the context of the browser, not the web page itself. A secure web page can communicate with an extension, and the extension can communicate with external endpoints via standard AJAX. The extension can be used as a proxy between the secure page and the non-HTTPS hardware endpoint.
Using an extension to handle communication also had the advantage of allowing state information about the hardware to be held in the extension instead of duplicated across multiple browser pages. Extensions typically exist as singletons in the browser, so multiple pages can access and interact with the same extension.
Of course, the user now had to add an extension to their browser for communication with the hardware device to work, but this is significantly more straightforward and easier for users to understand than a Chrome app.
Surprisingly, the majority of this project involved working around browser security measures. Blocking information from non-HTTPS sources on a secure page is undoubtedly necessary for maintaining the integrity of a secure page. Similarly, requiring a trusted SSL certificate to be included as part of the HTTPS protocol is vital to preventing man-in-the-middle attacks.
However, providing more straightforward, user-friendly methods of interacting with network-connected devices through a web-browser will be important as we move towards an internet of things culture, where more and more everyday objects can connect to local networks and the internet.
Despite the headaches, this was a very interesting project that touched on a number of aspects of browser security and network architecture that is often not encountered during more standard web development. The entire team learned a lot about browser internals, and ultimately I was able to build a functional solution with an acceptable user experience within the constraints of current web browser technologies.