Tag: device design

The Sonos debacle has raised questions about our personal tech’s life cycle

Article Sonos multiroom system press picture courtesy of Sonos

Sonos extend support for legacy products after backlash | PC World

From the horse’s mouth

Sonos

A letter from our CEO (Blog Post)

My Comments

Recently, Sonos sent some shivers around the Internet regarding their multiroom audio products’ life cycle.

This started with them installing a “Recycle” mode in their speakers and other devices, which would effectively take the devices out of action, with it being tied in to a rebate on new devices if the old equipment was returned to them for e-waste recycling.

It worried some social media users because they want to keep the extant equipment that functioned properly going for as long as possible, including “pushing down” older equipment to secondary areas, selling it in to the second-hand market and giving to friends, relatives and community organisations while they upgrade to newer Sonos gear. Here, they really wanted the Sonos device to be detached from the user’s Sonos account and prepared as if ready to set up within a new system for whenever it is given away or sold.

Then this past week, Sonos raised the prospect that multiroom-audio equipment made prior to model-year 2015 won’t get software updates after May 2020. This wasn’t conveyed properly in that the affected equipment won’t benefit from feature updates but will benefit from bug-fixes, security updates and anything else to do with software quality.

There was also issues raised about a Sonos-based multiroom-audio system that consists of the legacy equipment as well as newer equipment, which is a result of someone effectively “building-out” their system by purchasing newer gear. An example I referred to in an article about the IKEA SYMFONISK speakers which work on the Sonos platform is to use the SYMFONISK speakers as a low-cost way of adding extra speakers for another room like the kitchen while you maintain the Sonos speakers in the areas that matter.

The concern that was raised is the availability of software-quality updates including incremental support for new or revised API “hooks” offered by online-audio services; along with the ability for the devices to stay functioning as expected.

Then there was the issue of logically segmenting a Sonos multiroom audio system so that newer devices gain newer functionality available to them while older devices keep the status quo. At the moment, a Sonos multiroom system which works across the same logical network is divided in to logical rooms to allow speakers in one room to play the same source at the same volume level. Here, it may be about determining the upgradeability based on the existence of newer speakers in a room, where older speakers in the same logical room work as “slave” speakers to the newer speaker.

What is being called out here is how long a manufacturer should keep new software available for the equipment and what kind of updates should be available for equipment that is long in the tooth. It focuses especially on keeping the older devices function at an expected level while running secure bug-free firmware. Let’s not forget how older and newer devices can coexist in a system of devices based on a particular platform while providing consistent functionality.

This is more so where the equipment can enjoy a long service life, something that is expected of kit that costs a significant amount of money. It applies also to the fact that people build out these systems to suit their ever-changing needs.

Companies that observe the Sonos debacle could look at the mistakes Sonos made in properly conveying the issue of feature-update cessation for older products to their customer base. As well, they would have to look at how Sonos is tackling the issue of maintaining software quality, stability and security in their devices’ firmware along with catering to the reality of platform-based systems that have a mix of older and newer devices.

Germany to set a minimum security standard for home-network routers

Article

Telstra Gateway Frontier modem router press picture courtesy of Telstra

Germany has defined a minimum standard for secure broadband router design

Germany proposes router security guidelines | ZDNet

From the horse’s mouth

BSI (German Federal Office for Information Security)

TR-03148 Secure Broadband Router 1.0 (PDF)

My Comments

It is being identified that network connectivity devices and devices that are part of the Internet-Of-Things are being considered the weakest point of the secure Internet ecosystem. This is due to issues like security not being factored in to the device’s design along with improper software quality assurance when it comes to the devices’ firmware.

The first major incident that brought this issue to the fore was the Mirai botnet attack on some Websites and dynamic-DNS servers through the use of compromised firmware installed in network videosurveillance cameras. Recently in 2016, a similar Mirai-style attack attempt was launched by the “BestBuy” hacker involving home-network routers built by Zyxel and Speedport.There was a large installed base of these routers because they were provided as standard customer-premises equipment by Deutsche Telekom in Germany. But the attempt failed due to buggy software and the routers crashed.

Now the BSI who are Germany’s federal information-security government department have taken steps towards a baseline set of guidelines concerning security-by-design for these home-network routers. It addresses both the Internet-based attacker sithation and the local-network-based attacker situation such as a computer running malware.

Key requirements

Wi-Fi segments

There are requirements concerning the LAN-side private and guest Wi-Fi segments created by these devices. They have to work using WPA2 or newer standards as the default security standard and the default ESSIDs (wireless network names) and Wi-Fi passphrases can’t relate to the router itself like its make or model or any interface’s MAC address.

As well, guest Wi-Fi and community / hotspot Wi-Fi have to be treated as distinct separate logical networks on the LAN side and they have to be “fenced off” from each other. They will still have access to the WAN interfaces which will be the Internet service. The standard doesn’t address whether these networks should implement client-device isolation because there may be setups involving a requirement to discover printers or multimedia devices on these networks using client software.

Router management

The passwords for the management account or the Wi-Fi segment passphrases have to be tested against a password-strength algorithm when a user defines a new password. This would be to indicate how strong they are, perhaps through a traffic-light indicator. The minimum requirement for a strong password would be to have at least eight characters with at least 2 each of uppercase, lowercase, number and special characters.

For the management account, there has to be a log of all login attempts along with lockout-type algorithms to deter brute-force password attacks. It would be similar to a code-protected car radio that imposes a time delay if the wrong passcode is entered in the radio. There will be an expectation to have session-specific security measures like a session timeout if you don’t interact with the management page for a certain amount of time.

Other requirements for device management will include that the device management Webpage be only accessible from the main home network represented by the primary private Wi-Fi segment or the Ethernet segment. As well, there can’t be any undocumented “backdoor” accounts on the router when it is delivered to the customer.

Firmware updating

But the BSI TR-03148 Secure Broadband Router guidelines also addresses that sore point associated with router firmware. They address the issue of updating your router with the latest firmware whether through an online update or a file you download to your regular computer and upload to the router.

But it is preferred that automatic online updates take place regarding security-related updates. This will most likely extend to other “point releases” which address software quality or device performance. Of course, the end-user will need to manually update major versions of the firmware, usually where new functionality or major user-interface changes take place.

The router manufacturer will be required to rectify newly-discovered high-severity security exploits without undue delay once they are notified. Here, the end users will be notified about these software updates through the manufacturer’s own public-facing Website or the router’s management page.

Like with most regular-computer and mobile operating systems, the use of software signatures will be required to authenticate new and updated firmware. Users could install unsigned firmware like the open-source highly-functional firmware of the OpenWRT kind but they will need to be warned about the deployment of unsigned firmware on their devices as part of the deployment process. The ability to use unsigned firmware was an issue raised by the “computer geek” community who liked to tinker with and “soup up” their network hardware.

Users will also need to be notified when a manufacturer ceases to provide firmware-update support for their router model. But this can hang the end-user high and dry especially if there are newly-discovered weaknesses in the firmware after the manufacturer ceases to provide that software support.

The standard also places support for an “anti-bricking” arrangement where redundant on-device storage of prior firmware can exist. This is to avoid the router from “bricking” or irreversibly failing if downloaded firmware comes with software or file errors.

Other issues that need to be addressed

There are still some issues regarding this standard and other secure-by-design mandates.

One of these is whether there is a minimum length of time for a device manufacturer to continue providing security and software-quality firmware updates for a router model or series after it is superseded. This is because of risks like us purchasing equipment that has just been superseded typically to take advantage of lower prices,  or us keeping a router in service for as long as possible. This may be of concern especially if a new generation of equipment is being released rather than a model that was given a software-compatible hardware refresh.

Solutions that could be used include open-sourcing the firmware like what was done with the Linksys WRT-54G or establishing a known-to-be-good baseline firmware source for these devices while continuing to rectify exploits that are discovered in that firmware.

Another is the existence of a logo-driven “secure-by-design” campaign directed at retailers and the general public in order to encourage us to buy or specify routers that are compliant to this standard.

An issue that needs to be raised is whether to require that the modem routers or Internet-gateways supplied as standard customer-premises-equipment by German ISPs and telcos have a “secure-by-design” requirement. This is more of an issue with Internet service provided to the average household where these customers are not likely to fuss about anything beyond getting Internet connectivity.

Conclusion

The BSI will definitely exert market clout through Europe, if not just the German-speaking countries when it comes to the issue of a home network that is “secure by design”. Although the European Union has taken some action about the Internet Of Things and a secure-by-design approach, they could have the power to make these guidelines a market requirement for equipment sold in to the European, Middle Eastern and African areas.

It could also be seen by other IT bodies as an expected minimum for proper router design for home, SOHO and SME routers. Even ISPs or telcos may see it as an obligation to their customers to use this standard when it comes to specifying customer-premises equipment that is supplied to the end user.

At least the issue of “secured by design” is being continually raised regarding home-network infrastructure and the Internet Of Things to harden these devices and prevent them from being roped in to the next Mirai-style botnet.

Voice-driven assistants at risk of nuisance triggering

Article

Amazon Echo on kitchen bench press photo courtesy of Amazon USA

A problem that showed up with the Amazon Echo’s always-listen behaviour was nuisance triggering for the laughter command

Voice control is no laughing matter | Videonet

My Comments

An issue that has been raised recently is the risk of a voice-driven assistant like Apple’s Siri, Amazon’s Alexa, Google’s Assistant or Microsoft’s Cortana being triggered inadvertently and becoming of nuisance value.

This was discovered with Amazon’s Echo devices where you could say “Alexa, laugh” and Alexa would laugh in response. But if this was said in conversation or through audio or video content you had playing in the background, this could come across very creepy. A similar situation was discovered in 2014 with Microsoft’s XBox when there was a voice-search functionality built in to in and you would wake it by saying “XBox on!”, This was aggravated if, for example, a TV commercial from a consumer electronics outlet was playing and the adman announced a special deal on one of these consoles by saying something like “XBox On Special” or “XBox On Saie” which contain this key phrase.

Similarly, we are starting to see “voice-driven search” become a part of consumer electronics and this could become of an annoyance whenever dialogue in a movie or TV show or an adman’s talking in a TV commercial could instigate a search routine during your TV viewing.

But there are some implementations of these voice assistants that don’t start automatically when they hear your “wake phrase” associated with them like “Alexa” or “Hi Siri”. In these cases, you would press a “call” button to make the device ready to listen to you. This typically happens with smartphones, tablets, computers or smart-TV remote controls.

On the other hand, some of the smart speakers like Google Home use a microphone-mute button which you would activate if there is a risk of nuisance triggering. In this mode, the device’s microphone isn’t active until you manually disable it.

Google Home uses a microphone-mute button to control the mic

Personally, I would still like to see some form of manual control offered as the norm for these devices, preferably in the form of a “call” button with a distinct tactile feel when pressed. Then you would see a different light glow or other visual cue when the device is ready to talk to. Here, the user has some form of control over when the device can listen to them thus assuring their privacy.

Here, the article underscored the role of speech as part of a user interface that integrated one of many different interaction types like touch or vision. This then provides different comfort zones that the user can benefit from when using the device and they then rely on what’s comfortable to them.