The web browser is ubiquitous. Most PCs, tablets and smartphones have at least one version installed, and the choices cater for any operating system and device. The vast majority are free-of-charge, many have functions designed to appeal to certain user groups, and when content is loaded the layout and functionality will appear (or should appear) in the same way regardless of the package used. However, are they the best approach for security interfaces? Benchmark considers the pros and cons of internet browsers.
[dropcap]T[/dropcap]he web browser is a rather remarkable piece of software. It offers more flexibility than most proprietary graphical user interfaces, and is backed by a wide range of additional technologies. These add functionality to ensure that the software delivers a vast range of information in a variety of constantly evolving media. What really sets the browser apart from other interface packages is that nearly every user of a PC, tablet, smartphone or other connected device will have access to one!
The options for web browsers are manifold. Every company offering an operating system will have its own browser, as will many of the major service and content providers. Open source code organisations also offer them, as do large revenue-based on-line sales companies.
Whilst all the browsers have some differences, usually in the way a user interacts with them, they all do the same job. The software effectively acts as an interactive viewer for a diverse number of media. Browser software is free-of-charge, at least in financial terms, and it is commonly distributed.
All browsers read mark-up language and other code to establish a structure and framework, and then pull in a wide range of elements to create an interactive web page. Because of the diverse elements that can be used in web design, browsers have to be able to manage text with styling and formatting, images, video, audio, scripts and actions, data, automated processes, user interactions and a range of other logical events.
Web browsers have evolved significantly in recent times, and are no longer the limited viewing platforms of the early days of the web. Because of on-line interaction, browsers increasingly have to support complex and real-time transactions, and also must do so securely.
Security is a significant issue with browsers, not least because the companies that provide them need to be trusted. The browser is often tailored to deliver additional content and services which generate revenue, and as such a security flaw can be costly – in terms of lost customers – for the provider.
Browsers cannot be limited with regard to technologies supported either, and need to be constantly developed. This does not just mean keeping up with advances; the browser providers also sink a great amount of resources into countering threats too.
Browsers have become a pivotal part of modern communications, and the interactivity they deliver is set to grow. However, the browser should not be considered solely as a tool for viewing web pages. Its capabilities are far more impressive than that, as it can manage local sites too.
Given the flexibility on offer, it stands to reason that if a security device included an on-board server holding mark-up language and code to generate a GUI, it could be displayed – and interacted with – via a standard web-browser.
When a user connected to the device, either via a LAN or a WAN, the pages could be accessed using the browser. This would then allow configuration, control and usage from any browser-enabled device. Savings could be realised in terms of installation time, maintenance and cost of ownership.
For example, this approach would remove the need for dedicated software to be loaded on to a workstation. In turn, this would eliminate licensing costs, whilst also allowing connectivity from any device on the network.
Software updates would be simplified, as once the security device was running a new version, all users would in effect be updated.
On paper, a move to browser-controlled systems seems to be a significant step forwards for many applications.
Theory and reality
Whilst the theory of using web browsers as a GUI for security systems is all well and good, the reality can be a little different. Browser providers are concerned with internet activity for the masses, rather than system control for the security sector! The focus on security and risk management means that on occasions, they change software characteristics in a way that can adversely affect other uses.
By way of an example, it’s worth considering how browser changes affected installers and integrators using networked cameras and codecs.
When cameras and codecs are used as a part of the system, they are invariably connected to a VMS, a security appliance or a NVR. Whilst these give some degree of control over the attached device, few give full access to all elements of configuration. As a result, the devices typically include an integral web server which hosts the various configuration pages. These are accessed via a direct link with the device, using a web browser.
Because it is necessary to view the video stream and subsequent changes made to it during configuration, most manufacturers include video drivers. As many manufacturers have standardised on Microsoft Internet Explorer due to its widespread use, the drivers are often in the form of Microsoft ActiveX elements. These are loaded from the camera to the browser, enabling it to display the captured video stream in the appropriate format. ActiveX controls extend the functionality of the browser, and works with Internet Explorer as well as other programs in the Office suite.
Sadly, ActiveX elements have been used for nefarious purposes, and can take control of many computer functions.
As a result, and to ensure user confidence, Microsoft recently changed the way Internet Explorer handles ActiveX controls and other plug-ins. The result was that many found that accessing devices no longer worked as it had in the past. Issues were sporadic. Some manufacturers’ drivers still worked whilst others didn’t. Also, differing results occurred depending upon the browser build.
There was a simple workaround, but it took time for that information to be shared, and many manufacturers didn’t update manuals or issue technical bulletins. One manufacturer told Benchmark that at the time they saw a spike in returns with no fault found.
Suppliers of browsers will constantly develop more secure solutions. The result of this is that certain drivers, plug-ins and add-ons could be suddenly restricted if the browser manufacturer believes that risks may impact on its reputation.
The security sector is, to the suppliers of browsers, not significant enough in terms of revenue to be consulted or pre-warned of such changes. They will also point out that we use browsers in a less traditional way!
In theory, the use of browsers makes great sense, but in reality installers and integrators are at the mercy of changes implemented at the drop of a hat.
A support issue
Whilst the use of browsers can create issues which are outside of the control of the security industry, this doesn’t mean that the approach should be shunned. That would be akin to throwing the baby out with the bathwater. Instead, the industry must adapt to ensure that the potential disruption from any changes is minimised.
The security sector needs to learn from the IT industry. IT manufacturers issue regular technical bulletins and often run secure webpages which are updated with issues and troubleshooting advice on a daily basis. If security manufacturers choose to use browsers as an integral part of their system, then they need to ensure that they not only keep installers and integrators updated with browser-related information, but that they act swiftly if and when changes occur.
If a system is based upon a browser, then installers and integrators must ensure the manufacturer will support it too!
