Summary: Designing the JNIOR edge controller has provided a front-row seat to the collision between browsers and industrial automation. As browsers become the default user interface for edge devices, they continue to carry assumptions inherited from a very different world. Is it time to reconsider those assumptions?
For browsers there is a new class of target on the rise. No, it is not another HTML requirement, JavaScript complexity, CSS trick or DOM extension. Not a new cross-engine or cross-platform challenge. Not another wave of AI integration. And, it is not even an issue with cross-browser standards. It is a perfectly valid place to point a URL. However, it is not the typical type of destination and that is what may lead to difficulty.
More and more engineers need to use their browser to reach these destinations every day. Unfortunately, they are not always successful. It is a frustration that we just don’t need when our mission is to get work done efficiently. That frustration shouldn’t come with technology this exciting and obviously beneficial. Here we will look into what is behind all of this.
You are all very familiar with those domains leading you to websites that you no doubt absolutely need. Of particular value are those financial institutions that allow you pay your bills. There are clearly those social media sites that, well, demand your continued attention. And, for heaven sakes, you have to shop. While you can’t have everything, there is nothing, apparently, stopping you from trying. Heck, you might even be looking to buy that very thing that we are on about here.
So what brand new web destination is he referring to?
Well, it is not exactly new. It is a fast growing subset of the interconnected world that continues to be largely ignored. Not by those who find it useful. But by the tools we use to reach it. By “ignored,” I simply mean that it doesn’t yet seem to be on the radar of browser developers or standards committees.
If you want to get to something on the Internet, you bring up your browser. It might be Chrome. It might be Firefox. Or perhaps it is Microsoft Edge – which, by the way, is not what the title of this article is referring to.
I am talking here about the world of Edge Computing. That portion of the Internet of Things (IoT) that has quietly grown into full-fledged network servers. Those are the little engines that can get the job done. These devices are at the forefront of the drive to automate everything.
Let’s see why browsers sometimes leave you wanting at the edge.
There is a class of tiny networked devices with sensors and light-weight software that strive to communicate via Ethernet, and by extension, the Internet. Those small devices enable connectivity and avoid the investment in industrial Programmable Logic Controllers (PLCs). The concept has been around for over four decades and even the term, “Internet of Things” has been on the table since the turn of the century. Well, it is here to stay.
But while you are envisioning little electronic gadgets that flex little muscles and are happy to publish a few pieces of data to your favorite MQTT broker, you should know that it didn’t stop there. It still hasn’t.
The concept originated with the idea of having the nearby pop machines wake up the lazy vendor across town so he can get his backside down there to promptly refill the thing. And, to do so before you drag yourself over to the one in your college dorm. That invariably happens when you are in search of caffeine in the middle of an all-nighter and risk being greatly disappointed. After all, nothing can affect your academic performance more. This is clearly the quintessential basis for triggering a new technology wave.
Little devices publishing data everywhere. That does sound useful. And, why should you ever stop at there?
If the device is on the Internet it certainly can communicate bi-directionally. It can do so much more. It can remotely take control and do some of the work for us. It might even think on its own. Now that sounds like Automation. And that seems like it would be a hot topic. Evidently, the world can’t seem to get enough of it.
No matter what you do, someone thinks that they can do it better. You can always make a version of a thing do more. And, there is no shortage of that.
In the case of the high-end IoT devices that functional expansion quickly surpassed anything that you might ever call “feature creep”. The IoT application footprint spread like wildfire. And, in this case, those small light-weight firmware-based microprocessor gadgets got an idea to assimilate the rest of the computing spectrum. That mission to dominance is ongoing. It might even be accelerating.
No stake in the sand sits still long. That growing application footprint involves not only a larger complement of supported network protocols, it has also succumbed to pressure to become an active card-carrying member of the World Wide Web.
IoT devices that provide remote monitoring and control, also need to support remote configuration and real-time status. After all, you need to know if it is working as you intended. And that, before your paranoia leads to panic. You know, there is always some tweak required. And, clearly, you need to get to that right now and frustration-free.
The early IoT devices were taking the embedded Java concept by the horns. Devices that by definition are devoid of keyboard and monitor still need a way to express themselves. The browser, for a network oriented gadget, provides a free graphical user interface. And as for all things Java, those devices deployed Java applets to create that human-machine interface. If you had wanted interactive web pages, that was the way to go.
Or, maybe not.
Maybe this foreshadowed the main topic here. But while browsers initially embraced Java and happily executed its applets, that ended quickly. Nefarious actors learned how to leverage those applets to infect and own PCs. Those executable programs became central in the effort to reach deep into the heart of your machine and tear from it what is most dear to you; your passwords, data and personal information. Those Java applets rapidly created an insurmountable security problem.
Hey, perhaps someone should have realized. Realized that letting random websites execute code on your PC might have a downside. That kind of fits right in there with letting anyone anywhere globally post any 140-character message they want. What could could possibly go wrong?
The browser solution: Stop running applets. Ban them.
The growing population of firmware devices, few of which were field reprogrammable, were just out of luck. They were of no concern and not apparently considered at all in that decision. It was a serious setback for IoT.
There was a logical solution to this in JavaScript. That provided a managed language that could be kept in line and controlled. That eventually offered a much better interactive experience. Letting menus dance around the screen and graphics actively respond to your presence. All of that expanded client-side capability would soon leverage all of the server-side functionality that the big servers had to offer.
Remember those IoT devices left out to pasture? Faced with the setback, they roared back with a vengeance. They built fully featured web servers that can actively deliver pages loaded with JavaScript supported by server-side scripting, security and even WebSocket based protocols. IoT devices set their sights on, and drove hard into, the world of network servers.
At the same time highly capable single board computers, able to leap small buildings with a single bound, having those network requirements in the bag, saw opportunity. Those tiny affordable computers started to venture into the controls world. Toggling relays and reading sensors. That all is simple, right?
The gap between them quickly closed.
The world of Edge Computing was off and running. Meanwhile, browsers continued evolving around the needs of the public Internet. Enhancing those web destinations that call your name and promote commerce. And all of that time, the upcoming IoT and Edge Control population never quite reached the top of anyone’s priority list.
Let’s look at what you have. There is an extremely broad range of hardware platforms all supporting the complete network stack. They will all do it correctly. That is not the concern.
The difficulties stem from the fact that these IoT devices are not multi-core processors running at GHz clock rates equipped with wide data busses and high-speed memory components. They do not have hardware accelerators, cryptographic instruction extensions, and high-speed cryptographic coprocessors. But, on the positive note, they do not generate enough heat to keep a small room comfortable during long winter nights.
Instead, many are probably running on a single micro-controller (MCU) rocketing along at maybe 100 MHz struggling with narrow external busses and average speed memory components. Cryptographic support is based on the skill of the firmware programmer. None of those devices need a fan let alone liquid cooling.
They all successfully implement a functional stack. They offer much of the same services that the big boys bring to the table. They just can’t do it as fast.
The security industry has been pushing up key sizes and deprecating algorithms. It would be one thing if these were just recommendations. Updates roll out TLS configurations that disallow smaller key sizes and disable suites based upon simpler algorithms by default.
They are preparing the world for the impact of the not-quite-here-yet quantum computer. Our entire security methodology is based on computationally challenging and therefore expensive algorithms. The more work it takes to compute the cipher, the more secure it will be.
Should we be concerned about a theoretical computer that simultaneously already knows every possible answer for any calculation and can instantly generate the solution? It is true that on paper this would break cryptography as we know it. At that point the key size is irrelevant.
But more down to Earth, the real concern is that extremely fast computers are becoming more affordable. When you consider the ability we have now to focus multiple fast and inexpensive computers (with AI support) on a problem, old computationally expensive calculations risk becoming easy-peasy.
With software, that can be updated, you can force the use of more complex algorithms. You cannot expect existing hardware to change to handle that. They are trying. They’re perhaps even being incentivized to do so. And, equipment like industrial controllers, that are expected to function for decades without replacement, are greatly impacted by this.
On a 100 MHz MCU the highly secure cryptography starts to look like a 200-meter Olympic event run by sloths. Do you have the patience for that?
Your only solution to this problem is to avoid it. That 6 second delay in connection is just too painful. You can’t be bothered. Just use HTTP and get on with it.
We have a situation where more security is really less.
By increasing the security requirements we are forcing people to bypass it.
To add to the problem, the security industry recognizes the risk that individuals will not request secure connections. Because, every connection that you apparently make is, obviously, to your account at Fort Knox. Many browsers now test a site for available security protocols and automatically, and practically irreversibly, force you into it. Regardless of your choice.
Could Edge be better accommodated?
Mainstream servers not only run at impressive clock rates, that are incredible at multi-tasking. You can imagine code for those machines handling thousands of essentially simultaneous requests. Getting that done in a way that is almost undeniably simultaneous. They work their multi-tasking and parallel processing magic and get the job done. Some web destinations even employ server farms where that processing load is distributed across teams of eager machines. Nobody waits at that domain.
The browser is also ingeniously designed to render your web destination in the blink of an eye. To do that it not only reaches out to retrieve the requested webpage, it simultaneously requests that page and everything it references. In fact it might even request stuff that you haven’t yet asked for but might with another click. Just to please you. Click and bang it is there!
Typically several persistent secure connections to the destination server are leveraged in that effort. Your leading-edge top-of-the-line computer reaches out across the web with dozens of virtual highly reliable tentacles attempting to challenge some highly-parallelized website behemoth. The result is the almost instance appearance of the media-laden extravaganza that you were after. It is just gratifying. This is a party that those responsible for the boot sequencing any of the major operating system haven’t attended.
The high-end of the IoT and Edge Controller population also works to support multiple connections in an efficient manner. The individual devices with modest responsibility for monitoring and controlling tasks on the plant floor likely do not have that kind of muscle. While it might respond to a page request promptly, it will likely be a while before several simultaneously requested pages are all served.
Think for a moment what it would be like if each of those connections had to separately negotiate and perform all of that computationally exhausting cryptography. Thankfully TLS allows a secure connection to be resumed as another, sharing the work across multiple connections. Well, maybe.
There is a delicate balance here. Request a bunch of connections simultaneously and there won’t be any original negotiation to resume. They’ll all start negotiating. Secure one connection and then the others will follow if you time it right. But wait, naturally the nefarious folks have created a security risk in this. So the solution is again to not do it. They apparently assume that servers have lots of idle cycles in desperate need of purpose.
As the Edge Controller’s web interface loads giving that one step at a time experience, what does that reflect poorly on? What do you blame? I don’t think that you need to purchase more bandwidth.
Could Edge be better accommodated?
More and more Edge devices are capable of handling secure connections. The security negotiation completes in a fairly reasonable time. The browser might even then make use of the master secret across multiple connections addressing the cost in making those each individually negotiated.
In that process TLS Certificates are exchanged. Those are used then to authenticate the endpoints. Browsers and operating systems are each deployed with a acquired set of trusted root certificates. Every valid destination must supply a certificate that chains back to a trusted root certificate.
IoT devices and Edge Controllers are rarely have their own web domains. Their identity is often just a local IP address and IP addresses do change from time to time. A certificate for that type of device is often internally generated and self-signed. There is no chain of trust in the global TLS context.
When the browser encounters those certificates the assumption is that “Something has gone wrong”. It can only imagine that you have been fooled into traveling into uncharted territory where there be dragons. Warning lights flash and a screen designed to turn you back appears. If you want to progress forward past that point, if you decide to not heed the warnings, your effort is impeded by purposely obscuring the path.
That is by design. Apparently every site on the network must undertake the effort to obtain a trusted certificate.
And should you mange your way past that point, your connection is labeled clearly as “Not Secure”. But in fact it is fully encrypted and private. It is cryptographically secure. No one can see what your are doing. They cannot collect your username and password. The connection, according to the browser, really should just be labelled: “Not Trusted”. And, shouldn’t that be your choice?
Could Edge be better accommodated?
Every request forwarded by the browser takes an effort in parsing, retrieval and rendering. We’ve already talked about what impact security has on all of that. The mainstream web servers nevertheless get that done with amazing speed.
But the hardware range in Edge Computing leads to a wide range in response times. All for what amounts to be the same essential task. And so it is not surprising to find a few stragglers proudly crossing the finish line long after the cameras have left.
Considering the server farms handling the world’s browsing habit, response time statistics are heavily biased in their direction. Where do you draw a line in that skewed distribution to decide at what point something has gone wrong?
By design, the browser, after waiting for a bit, has to report that the site is not reachable and is not responding. After all that software intends to build and maintain your confidence. It wants you to know that it is working for you. It can only sit there so long before both you and it gets nervous. Eventually a timeout is reached and the disappointment is handed over to you.
Now those timeouts are configurable. That is, if you have the sense of adventure and are comfortable digging into low-level browser configuration. Even in getting to that point the browser makes it known that you are proceeding at your own risk.
The timeout event reflects poorly on the Edge Controller. And it shouldn’t. That device’s goal is to perform local monitoring and control. An Edge controller works to perform its primary duties with some level of determinism. Its design cannot be driven by a need to compete with the world wide web’s rapid response teams. That is not its priority.
Could Edge be better accommodated?
Basically browsers weren’t designed for this. While the browser architecture is impressive, their development occurs in a world focused on your safety. Their main goal is to keep commerce on the Internet secure and available.
For thirty years browsers mostly connected us to web servers built on increasingly powerful computers. Today they are just as likely to find themselves talking to an industrial controller, a gateway, a data logger, the JNIOR, or some other edge device whose priorities are entirely different.
The paradigm has changed. Edge computing is pushing the envelope even further. It has quietly become a first-class citizen on the network. Its presence has us recognizing that the tools we use everyday need to begin to acknowledge that not every URL points to another rack of servers in a climate controlled data center.
Browsers are quietly becoming the standard graphical user interface for Edge Computing. We can understand how the browser got here carrying assumptions from one world into another. And while your experience may vary, it is worth considering what impression the browser leaves—and whether that impression is a fair one.
Could Edge be better accommodated?
Perhaps it is time!