Peter Seebach ([mailto:crankyuser@seebs.plethora.net?cc=&subject=Ease-of-use or marketing-driven sabotage] crankyuser@seebs.plethora.net) Freelance writer 17 December 2003
Abstract: Recently, a router vendor configured its product to occasionally redirect HTTP requests to a product ad Web site and defended the action as an "ease-of-use" feature. In this installment, cranky Peter Seebach discusses why this type of design is wrong and the technical (and ethical) problems it can cause.
Imagine you have a network product, perhaps a router let's say, and you've crafted a feature you think people might like. You might embed something in the documentation about it or perhaps even enclose a glossy brochure with the product. Alternately, you might want to just sniff network traffic and, about once every eight hours, redirect a randomly selected HTTP (you know, the Hyper-Text Transfer Protocol, the protocol used to browse the Web) session to an ad for your product.
Belkin just started doing this with one of their wireless routers.
Note: This column ran with the name "Company X", because IBM wasn't comfortable running the whole thing with Belkin's name. I am.
The intent is obviously to sell a product to home users. However, commercial users might also install this product or one like it. Lots of people use computers. Lots of people use networks. Lots of people use wireless routers.
Imagine, if you will, a carefully crafted and meticulously implemented system which uses a wireless network to exchange information. It's designed to run in a fairly stable environment, so it doesn't do a whole lot of error-checking or second-guessing. It does, however, use HTTP to transfer data.
So in this system, every eight hours a randomly selected device from a set of devices will receive a Web page that's an ad instead of snagging useful, business-related information. The results can range from amusing (maybe it's an airport departure schedule listing) to inconvenient (maybe you're in a hurry at the airport) to fatal (maybe it's a piece of medical equipment).
The idea -- that it could be okay to reroute a user's request without any kind of permission or confirmation -- is a strange one. What if the user was trying to communicate with a bank or otherwise had private or secret information in the HTTP request?
Of course, you can conveniently opt-out. As always, opt-out is a cop-out. It's like the police telling you that they can't arrest someone for assaulting you until you tell them to stop hitting you. But that's not the scariest part.
What's really scary is how the opt-out feature works. When you click on a link in the advertisement, your router stops redirecting you to the ad. And how does it do this? The server sends a packet that changes that particular configuration option.
In a Usenet post, a representative of Belkin explained how to change the configuration option locally, in case your firewall blocked the special message that changes the configuration setting. By default, the machine at the Web site for Belkin can change the configuration of your router if it knows where your router is.
That's right. Something can be sent to your router from outside of your network which will change its configuration. How many other settings can be changed remotely? Can you disable this? These are hard, and as of now, unanswered questions.
So how do reps for Belkin answer this criticism? The initial response is probably not what you might have hoped for. In the same Usenet post in which the remote configuration "feature" was disclosed, a Belkin employee provided a few details.
One detail was that information gathered when you registered went to a third party, rather than to Belkin. A second item was that the design goal was to provide ease-of-use for product registration.
So, the users of your router experience one unexpected redirect every eight hours. Until you tell your router to stop doing it. And even then, if you're on a secure network, you may have to manually go in and reconfigure the router. Instructions for this were posted to Usenet, but apparently nowhere else.
This post was deleted from the archives about two days after it was first posted to Usenet. It was replaced by a shorter message explaining that Belkin agreed an issue existed and that a firmware update fixing this would be made available shortly.
This idea was approved once. The fact that someone in control thought this was a good idea once means that it might happen again.
Without knowing why and how this happened (or the intentions behind this kind of reasoning), I'm not sure what to think about statements that the issue is resolved. Do the people at Belkin see the same issue that I do? Are software actions that go beyond the advertised intent of software merely an ease-of-use issue?
This highlights that users really need to be able to trust their hardware. The traditional assumption is that hardware is trying to do what it's supposed to do -- conform to specifications, route packets, store data, whatever. All of the reliability features of the Internet depend on some degree of good faith. Just as VeriSign's SiteFinder caused a certain amount of technical trouble, Belkin's ad-routing feature raises some issues. The worst part for users is the difficulty of working around such a feature. If I send an HTTP request to a site and the request doesn't complete, the TCP/IP software on my computer is supposed to know that the request failed so it can try to resend. And it won't do this if the router gives it bad data.
If it's possible that hardware might perform a questionable act, then users need a way to verify that the hardware is performing the acts that they bought it for. That pretty much means reviewing the source code for the router's firmware -- the software it has recorded on a little chip, which tells it what to do.
Ken Thompson did a wonderful presentation once, titled "Reflections on Trusting Trust," in which he demonstrated that you cannot trust code that you don't have complete control over. His demonstration involved building a C compiler which introduced a backdoor into a system-authentication routine. You might think you could just check the compiler source, but you see, the code also inserted itself into the C compiler whenever it found itself working on the compiler. As a result, the code could be removed from the compiler and an inspection would reveal nothing suspicious.
Consider the implications of this for a router. It has code to load new firmware software. How do you know that this code is trustworthy? You don't. You can't. The only defense you have is the assumption that router vendors are trustworthy.
But, then, if vendors were always trustworthy, you wouldn't need to examine the code in the first place.
This week's action item: Ask a handful of network technicians what they would think of a router behaving in this way. Is the response generally positive or negative?
Photo of Peter Seebach Peter Seebach would like to be able to trust hardware manufacturers' software, but sometimes their misguided actions speak louder than their apologetic words. If you'd like to talk about product trust, you can reach him at [mailto:crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.