Safe from what?

I woke up this morning to a headline news story on CBC's website: Is your baby monitor safe? According to a literal reading of Betteridge's law of headlines, the answer to this question should be "no", although if you consider the spirit of the law — as a commentary on sensationalist journalism — then the answer should probably be "yes". To me, neither answer makes sense, because the question itself doesn't make sense.

What does it mean for a baby monitor to be safe? Some things are clearly essential: It should not explode; it should not release significant quantities of dangerous gasses; if it's designed to be placed within reach of a baby, it should not pose an electrocution or choking hazard. Less obviously, if it has data or power cables, those should be arranged to avoid effecting tripping hazards. On the other hand, it's far from clear if privacy is an essential component of "safety". Does it matter if someone within range of your wireless network can listen to your baby crying? Probably not — anyone that close to you has likely heard far more of your baby's crying than they want already. Similarly, unless you never leave home, video of your baby sleeping is readily available to anyone who passes you in the street.

The word "safe", like the word "secure", covers a wide range. Is a Tesla car safe? For most people driving through the streets of Vancouver, it's very safe. But if you're driving through a war zone, having a vehicle which is designed to protect you from bullets and shrapnel is probably more important than having a vehicle designed to protect you in a head-on collision. The answer to whether a vehicle — or a baby monitor — is safe isn't yes or no; it's another question: "Safe from what?"

I spent seven years as Security Officer for the FreeBSD operating system, and over the years I wrote somewhere around a hundred advisories for vulnerabilities in FreeBSD. We used a consistent format: Background, Problem Description, Impact, Workaround, Solution. Of these sections, the Impact was always the section I wrote most carefully, and the section I advised users to pay the most attention to; and it usually had a consistent format: "An attacker who..." (description of attacker, e.g., "has an account on a system", or "can connect to your wifi network") "can ..." (description of what the attacker can do, e.g., "gain superuser privileges", or "listen to your baby crying"). Both of those clauses were essential in order for users to decide whether they wanted to update their systems: If there are no attackers whom you're worried about (say, if all of your code runs as root and the vulnerability is limited to nonprivileged users), or you don't care about what attackers can do (say, if the issue limits them to listening to crying babies), then you don't need to worry.

Of course, if you're building a product or supplying a service, you should be concerned about any attacker and any outcome which your potential customers could plausibly be worried about; after all, you're (hopefully!) in a better position to understand the safety and security properties of your product or service than your customers are, but you don't know exactly what attackers or outcomes they will care about. For the online backup service I run, this means being concerned not just about random attackers around the internet, but also considering myself as a possible attacker (since I might be coerced, legally or otherwise); and considering not just disclosure of backups, but also disclosure of whether particular data has been backed up (I call this the RIAA attack: "Has anyone backed up this MP3 file?") and also tampering with backups (can someone change the passwords in your backups so that they can break into your server after you restore from those backups?) as attacks I need to worry about — not because I think everybody is going to be worried about such attacks, but because someone might be.

But if you're simply assessing a product for your own use rather than building a product for a wide audience, you should know what you're worried about and what you don't care about. So don't ask "is this baby monitor safe"; ask "will this baby monitor allow any attackers I'm worried about to do anything I care about".

And if you're writing headlines, please stop using vague terms like "safe" or "secure". The role of a headline isn't, no matter what tabloids might suggest, to convince people to read an article; the role of a headline is to help readers decide if they want to read the article, and imprecision serves no purpose there.

Posted at 2015-09-02 23:30 | Permanent link | Comments
blog comments powered by Disqus

Recent posts

Monthly Archives

Yearly Archives


RSS