Finding Zune-Fi: Ina Fried of News.com wanders the polite streets of San Francisco in search of Zune connections over Wi-Fi. She finds a few, and has a good experience. One cafe owner sees the ease with which she can stream music and calls it cool. She can't connect at the long-running Google-sponsored free Wi-Fi at Union Square, however, which means the Wi-Fi likely has an accept button that must be pressed. Surely Microsoft could insert a little technology that would allow a browser-free acceptance of terms? Probably involves Yet Another Protocol: the Wi-Fi Terms Browser-Free Presentation Protocol (WTBFPP).

Kodak adds interesting Wi-Fi enabled all-in-one: The new Kodak ESP 9 is a multi-function printer (fax, scan, print, copy) that connects to a network via Wi-Fi or Ethernet. The $300 device spits out 30 pages per minutes in color, 32 ppm in black only. Kodak claims that the model line to which the ESP belongs uses ink in a vastly more efficient manner than the "average of comparable consumer inkjet printers."

OnStar will soon include the ability for the police to shut off your engine remotely. Buses are getting the same capability, in case terrorists want to re-enact the movie Speed. The Pentagon wants a kill switch installed on airplanes, and is worried about potential enemies installing kill switches on their own equipment.

Microsoft is doing some of the most creative thinking along these lines, with something it's calling "Digital Manners Policies." According to its patent application, DMP-enabled devices would accept broadcast "orders" limiting capabilities. Cellphones could be remotely set to vibrate mode in restaurants and concert halls, and be turned off on airplanes and in hospitals. Cameras could be prohibited from taking pictures in locker rooms and museums, and recording equipment could be disabled in theaters. Professors finally could prevent students from texting one another during class.

The possibilities are endless, and very dangerous. Making this work involves building a nearly flawless hierarchical system of authority. That's a difficult security problem even in its simplest form. Distributing that system among a variety of different devices -- computers, phones, PDAs, cameras, recorders -- with different firmware and manufacturers, is even more difficult. Not to mention delegating different levels of authority to various agencies, enterprises, industries and individuals, and then enforcing the necessary safeguards.

Once we go down this path -- giving one device authority over other devices -- the security problems start piling up. Who has the authority to limit functionality of my devices, and how do they get that authority? What prevents them from abusing that power? Do I get the ability to override their limitations? In what circumstances, and how? Can they override my override?

How do we prevent this from being abused? Can a burglar, for example, enforce a "no photography" rule and prevent security cameras from working? Can the police enforce the same rule to avoid another Rodney King incident? Do the police get "superuser" devices that cannot be limited, and do they get "supercontroller" devices that can limit anything? How do we ensure that only they get them, and what do we do when the devices inevitably fall into the wrong hands?

It's comparatively easy to make this work in closed specialized systems -- OnStar, airplane avionics, military hardware -- but much more difficult in open-ended systems. If you think Microsoft's vision could possibly be securely designed, all you have to do is look at the dismal effectiveness of the various copy-protection and digital-rights-management systems we've seen over the years. That's a similar capabilities-enforcement mechanism, albeit simpler than these more general systems.

And that's the key to understanding this system. Don't be fooled by the scare stories of wireless devices on airplanes and in hospitals, or visions of a world where no one is yammering loudly on their cellphones in posh restaurants. This is really about media companies wanting to exert their control further over your electronics. They not only want to prevent you from surreptitiously recording movies and concerts, they want your new television to enforce good "manners" on your computer, and not allow it to record any programs. They want your iPod to politely refuse to copy music a computer other than your own. They want to enforce their legislated definition of manners: to control what you do and when you do it, and to charge you repeatedly for the privilege whenever possible.

"Digital Manners Policies" is a marketing term. Let's call this what it really is: Selective Device Jamming. It's not polite, it's dangerous. It won't make anyone more secure -- or more polite.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

First, let me say what I knew about the SDL going in: no policy can anticipate every situation; you have to make tradeoffs; the details matter; the big picture matters; you need tools; you need human insight; you need management support; and we’re never going to be perfect. All of the things you’ve read in this blog are true, and they really shouldn’t be controversial. Since joining SQL, I’ve learned a lot about SQL Server too, and what it means to ship a product - but that’s outside the scope of this blog. So instead, I’ll try to describe three real experiences that illustrate things that shouldn’t be controversial either, but aren’t usually covered under the rubric of security.  They are crucial nonetheless.

Security is not the point, it’s the needs of the customer. It’s easy to believe that security is the point of producing a product. It’s not. We won’t produce an insecure product, but the primary driver for a product team is to produce a valuable, useful product. Yes, security is a big part of that, but security is not a goal in and of itself.  For example, one of the areas of fierce competition in enterprise database products is performance, and we have to balance security with  performance. One of the ways we do that is by verifying data we receive really well, but only when necessary. We define clear trust boundaries, and check the data thoroughly once on the way in, and then work very hard to enforce those trust boundaries.

I first encountered this in SQL when I helped review threat models for the database engine. The engine trusts that the data on the disk was written correctly by a trusted entity (with checksums to guard against random errors), and enforce that. Instead of a slavish adherence to the principle of total mediation or defense in depth, which, when taken to its extreme would say to “check everything, every time,” we are hard core about making the right checks, but only the right checks.

I will note that it is not an either/or choice between security and performance – it is possible to do both. Indeed, I would say that doing one without the other is pointless, but to get both 1) world class performance, and 2) world class security,  you have to understand your data flows really well, and make detailed decisions.

Be polite, but don’t be afraid: Job interviews at Microsoft can be challenging. When I interviewed for this job, my final interview was with a very senior architect. The subject of integer overflows came up, and he asked me to describe the problems and solutions. So I started writing some code on the whiteboard. After about 10 minutes of describing my approach to integer overflows, he said to me, “What if I were to tell you that’s a really bad solution, and the interview is over?”

My heart sank.

But instead of rolling over, I said, “well, that’s a bad outcome, tell me why.” He proceeded to attack my solution on several grounds, including being unreadable and unmaintainable, and he proceeded to describe his solution to the problem. Now, this was a very serious, very senior technical architect, and I was in a high pressure, asymmetric situation. So, not willing to be intimidated, but unable to attack back, I pointed out several shortcomings of his solution, politely, but firmly. And we spent the next 40 minutes talking about various aspects of the problem, and me defending my solution, which I think was credible. I don’t know if he agreed with my solution or not, really, but I suspect it might have been a test to see if I would cave. Or maybe he thought it really was a bad solution, I don’t know. But I got the job.

As a security professional, you’re always going to be at a technical disadvantage when you’re reviewing another team’s components. They designed and implemented the system. You are an outsider, and it is absolutely impossible to understand the system to the degree as the people who built it. Nonetheless, you’ve got to find a way to ask hard, probing, impolite and sometimes even uninformed questions without being threatening or insulting, or undermining your own credibility.  

Be polite, be firm, put your ego in a box, and ask questions until you understand.

“It should work” is not a good answer:  We take the giblets problem very seriously, and managing giblets can be quite difficult at times. And in SQL, we have lots of giblets. We consume things from Windows, and Office, and Visual Studio, and others, and we provide giblets to other teams as well. In fact, we provide components that other teams use to build the giblets they provide to us – we consume our own giblets!

And as it happens, one of the components we use was updated recently. Even though it would get serviced through Microsoft Update, we want to ensure we have the latest and greatest version of any component we ship. But to consume the latest and greatest version of this particular component would require some small updates to either our installer or theirs. So we met with the team that owns the giblet in question to try to divvy up the work, and to avoid schedule disruptions on either side.

There was a lot of back and forth about various things to try, and we continued to refine a solution until we had reduced the problem to a single issue. 

At this point, there was an air of hope in the room. If the idea actually worked, we had a solution at relatively low cost. But would it work? When the question of “will this work” comes up, all eyes turn towards test managers.

Our general manager was looking right at our test manager and she asked, “Will that work?” The test manager looked across the table at the development manager from the other group, and said, “I don’t know. That depends on their level of confidence in the behavior of their component under these conditions.”

Now, all eyes were starting at the dev manager, and the room got quiet. A somewhat sheepish look came over his face, because he knew the answer he was about to give would be unsatisfactory. He said, “Well, I’m not a tester, I’m just a developer, but it should work.”

At which point the room erupted into hysterical laughter.

“It should work” means “I think so, but we have to test it.” And that means the whole battery of tests for each of the affected components, across all of the supported platforms. And that has to be scheduled in test labs. To be clear, this wasn’t a lack of confidence in the developer, quite the contrary, he was laughing along with everyone else. We just know that writing software to satisfy all the scenarios in which our software is deployed requires far more testing than can reasonably be performed on a single desktop system.

So the tests were scheduled, the developer was proven correct, and we’re picking up the latest version. Even seemingly simple changes require a lot of testing.

So, that’s what I’ve learned: security isn’t the be-all-end-all,, things are really complex and hard to understand, and you don’t really know if anything works until you test it. None of which should be controversial, but none of the central ideas in the SDL are controversial either. The hard part is putting theory into practice, and recognizing that no venture is risk free, despite the natural inclination of security engineers to avoid any risk whatsoever. In this, I am reminded of one of my favorite books, “To Engineer is Human: The Role of Failure in Successful Design,” by Henry Petroski. He writes, “No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts [and are] constantly striving to do more with less. [] The engineer always believes he is trying something without error, but the truth of the matter is the each new structure can be a new trial. [] Such is the nature not only of science and engineering, but of all human endeavors.”

Today I logged into to the blog-o-sphere to read this polite, but shocking, post by Chris Martins, Progress Apama,  The Power of the Apama Name.   

The post is shocking to me because it appears that StreamBase was blatantly abusing and violating the Apama trademark in a Google Adsense marketing campaign.

I find this hard to believe, and wonder if someone else, not StreamBase, was actually running this Adsense campaign.   I cannot imagine StreamBase doing something so ethically and legally wrong.    I hope that what we are seeing is an attack on StreamBase’s integrity and not an actual Adsense campaign by StreamBase.

From a legal perspective, StreamBase is liable for any loss of business or damages to Progress by wilfully violating the Apama trademark.

Frankly speaking, if StreamBase was responsible for this Adsense campaign memorialized in Chris’ post, then StreamBase owes Apama at a minimum, a public apology. 

To me, it's basic politeness. Providing internet access to guests is kind of like providing heat and electricity, or a hot cup of tea. But to some observers, it's both wrong and dangerous.

I'm told that uninvited strangers may sit in their cars in front of my house, and use my network to send spam, eavesdrop on my passwords, and upload and download everything from pirated movies to child pornography. As a result, I risk all sorts of bad things happening to me, from seeing my IP address blacklisted to having the police crash through my door.

While this is technically true, I don't think it's much of a risk. I can count five open wireless networks in coffee shops within a mile of my house, and any potential spammer is far more likely to sit in a warm room with a cup of coffee and a scone than in a cold car outside my house. And yes, if someone did commit a crime using my network the police might visit, but what better defense is there than the fact that I have an open wireless network? If I enabled wireless security on my network and someone hacked it, I would have a far harder time proving my innocence.

This is not to say that the new wireless security protocol, WPA, isn't very good. It is. But there are going to be security flaws in it; there always are.

I spoke to several lawyers about this, and in their lawyerly way they outlined several other risks with leaving your network open.

While none thought you could be successfully prosecuted just because someone else used your network to commit a crime, any investigation could be time-consuming and expensive. You might have your computer equipment seized, and if you have any contraband of your own on your machine, it could be a delicate situation. Also, prosecutors aren't always the most technically savvy bunch, and you might end up being charged despite your innocence. The lawyers I spoke with say most defense attorneys will advise you to reach a plea agreement rather than risk going to trial on child-pornography charges.

In a less far-fetched scenario, the Recording Industry Association of America is known to sue copyright infringers based on nothing more than an IP address. The accused's chance of winning is higher than in a criminal case, because in civil litigation the burden of proof is lower. And again, lawyers argue that even if you win it's not worth the risk or expense, and that you should settle and pay a few thousand dollars.

I remain unconvinced of this threat, though. The RIAA has conducted about 26,000 lawsuits, and there are more than 15 million music downloaders. Mark Mulligan of Jupiter Research said it best: "If you're a file sharer, you know that the likelihood of you being caught is very similar to that of being hit by an asteroid."

I'm also unmoved by those who say I'm putting my own data at risk, because hackers might park in front of my house, log on to my open network and eavesdrop on my internet traffic or break into my computers. This is true, but my computers are much more at risk when I use them on wireless networks in airports, coffee shops and other public places. If I configure my computer to be secure regardless of the network it's on, then it simply doesn't matter. And if my computer isn't secure on a public network, securing my own network isn't going to reduce my risk very much.

Yes, computer security is hard. But if your computers leave your house, you have to solve it anyway. And any solution will apply to your desktop machines as well.

Finally, critics say someone might steal bandwidth from me. Despite isolated court rulings that this is illegal, my feeling is that they're welcome to it. I really don't mind if neighbors use my wireless network when they need it, and I've heard several stories of people who have been rescued from connectivity emergencies by open wireless networks in the neighborhood.

Similarly, I appreciate an open network when I am otherwise without bandwidth. If someone were using my network to the point that it affected my own traffic or if some neighbor kid was dinking around, I might want to do something about it; but as long as we're all polite, why should this concern me? Pay it forward, I say.

Certainly this does concern ISPs. Running an open wireless network will often violate your terms of service. But despite the occasional cease-and-desist letter and providers getting pissy at people who exceed some secret bandwidth limit, this isn't a big risk either. The worst that will happen to you is that you'll have to find a new ISP.

A company called Fon has an interesting approach to this problem. Fon wireless access points have two wireless networks: a secure one for you, and an open one for everyone else. You can configure your open network in either "Bill" or "Linus" mode: In the former, people pay you to use your network, and you have to pay to use any other Fon wireless network. In Linus mode, anyone can use your network, and you can use any other Fon wireless network for free. It's a really clever idea.

Security is always a trade-off. I know people who rarely lock their front door, who drive in the rain (and, while using a cellphone) and who talk to strangers. In my opinion, securing my wireless network isn't worth it. And I appreciate everyone else who keeps an open wireless network, including all the coffee shops, bars and libraries I have visited in the past, the Dayton International Airport where I started writing this and the Four Points Sheraton where I finished. You all make the world a better place.

This essay originally appeared on Wired.com, and has since generated a lot of controversy. There's a Slashdot thread. And here are three opposing essays and three supporting essays. Presumably there will be a lot of back and forth in the comments section here as well.

To me, it's basic politeness. Providing internet access to guests is kind of like providing heat and electricity, or a hot cup of tea. But to some observers, it's both wrong and dangerous.

I'm told that uninvited strangers may sit in their cars in front of my house, and use my network to send spam, eavesdrop on my passwords, and upload and download everything from pirated movies to child pornography. As a result, I risk all sorts of bad things happening to me, from seeing my IP address blacklisted to having the police crash through my door.

While this is technically true, I don't think it's much of a risk. I can count five open wireless networks in coffee shops within a mile of my house, and any potential spammer is far more likely to sit in a warm room with a cup of coffee and a scone than in a cold car outside my house. And yes, if someone did commit a crime using my network the police might visit, but what better defense is there than the fact that I have an open wireless network? If I enabled wireless security on my network and someone hacked it, I would have a far harder time proving my innocence.

This is not to say that the new wireless security protocol, WPA, isn't very good. It is. But there are going to be security flaws in it; there always are.

I spoke to several lawyers about this, and in their lawyerly way they outlined several other risks with leaving your network open.

While none thought you could be successfully prosecuted just because someone else used your network to commit a crime, any investigation could be time-consuming and expensive. You might have your computer equipment seized, and if you have any contraband of your own on your machine, it could be a delicate situation. Also, prosecutors aren't always the most technically savvy bunch, and you might end up being charged despite your innocence. The lawyers I spoke with say most defense attorneys will advise you to reach a plea agreement rather than risk going to trial on child-pornography charges.

In a less far-fetched scenario, the Recording Industry Association of America is known to sue copyright infringers based on nothing more than an IP address. The accuser's chance of winning is higher than in a criminal case, because in civil litigation the burden of proof is lower. And again, lawyers argue that even if you win it's not worth the risk or expense, and that you should settle and pay a few thousand dollars.

I remain unconvinced of this threat, though. The RIAA has conducted about 26,000 lawsuits, and there are more than 15 million music downloaders. Mark Mulligan of Jupiter Research said it best: "If you're a file sharer, you know that the likelihood of you being caught is very similar to that of being hit by an asteroid."

I'm also unmoved by those who say I'm putting my own data at risk, because hackers might park in front of my house, log on to my open network and eavesdrop on my internet traffic or break into my computers. This is true, but my computers are much more at risk when I use them on wireless networks in airports, coffee shops and other public places. If I configure my computer to be secure regardless of the network it's on, then it simply doesn't matter. And if my computer isn't secure on a public network, securing my own network isn't going to reduce my risk very much.

Yes, computer security is hard. But if your computers leave your house, you have to solve it anyway. And any solution will apply to your desktop machines as well.

Finally, critics say someone might steal bandwidth from me. Despite isolated court rulings that this is illegal, my feeling is that they're welcome to it. I really don't mind if neighbors use my wireless network when they need it, and I've heard several stories of people who have been rescued from connectivity emergencies by open wireless networks in the neighborhood.

Similarly, I appreciate an open network when I am otherwise without bandwidth. If someone were using my network to the point that it affected my own traffic or if some neighbor kid was dinking around, I might want to do something about it; but as long as we're all polite, why should this concern me? Pay it forward, I say.

Certainly this does concern ISPs. Running an open wireless network will often violate your terms of service. But despite the occasional cease-and-desist letter and providers getting pissy at people who exceed some secret bandwidth limit, this isn't a big risk either. The worst that will happen to you is that you'll have to find a new ISP.

A company called Fon has an interesting approach to this problem. Fon wireless access points have two wireless networks: a secure one for you, and an open one for everyone else. You can configure your open network in either "Bill" or "Linus" mode: In the former, people pay you to use your network, and you have to pay to use any other Fon wireless network. In Linus mode, anyone can use your network, and you can use any other Fon wireless network for free. It's a really clever idea.

Security is always a trade-off. I know people who rarely lock their front door, who drive in the rain (and, while using a cell phone) and who talk to strangers. In my opinion, securing my wireless network isn't worth it. And I appreciate everyone else who keeps an open wireless network, including all the coffee shops, bars and libraries I have visited in the past, the Dayton International Airport where I started writing this and the Four Points Sheraton where I finished. You all make the world a better place.

This essay originally appeared on Wired.com, and has since generated a lot of controversy. There's a Slashdot thread. And here are three opposing essays and three supporting essays. Presumably there will be a lot of back and forth in the comments section here as well.

EDITED TO ADD (1/15): There has been lots more commentary.

EDITED TO ADD (1/16): Even more commentary.