"The rigorous studies clearly show red-light cameras don't work," said lead author Barbara Langland-Orban, professor and chair of health policy and management at the USF College of Public Health. "Instead, they increase crashes and injuries as drivers attempt to abruptly stop at camera intersections."

Comprehensive studies from North Carolina, Virginia, and Ontario have all reported cameras are associated with increases in crashes. The study by the Virginia Transportation Research Council also found that cameras were linked to increased crash costs. The only studies that conclude cameras reduced crashes or injuries contained "major research design flaws," such as incomplete data or inadequate analyses, and were always conducted by researchers with links to the Insurance Institute for Highway Safety. The IIHS, funded by automobile insurance companies, is the leading advocate for red-light cameras since insurance companies can profit from red-light cameras by way of higher premiums due to increased crashes and citations.

And, of course, the agenda of the government is to increase revenue due to fines:

A 2001 paper by the Office of the Majority Leader of the U.S. House of Representatives reported that red-light cameras are "a hidden tax levied on motorists." The report came to the same conclusions that all of the other valid studies have, that red-light cameras are associated with increased crashes and that the timings at yellow lights are often set too short to increase tickets for red-light running. That's right, the state actually tampers with the yellow light settings to make them shorter, and more likely to turn red as you're driving through them.

In fact, six U.S. cities have been found guilty of shortening the yellow light cycles below what is allowed by law on intersections equipped with cameras meant to catch red-light runners. Those local governments have completely ignored the safety benefit of increasing the yellow light time and decided to install red-light cameras, shorten the yellow light duration, and collect the profits instead.

The cities in question include Union City, CA, Dallas and Lubbock, TX, Nashville and Chattanooga, TN, and Springfield, MO, according to Motorists.org, which collected information from reports from around the country.

Today I have been authorized to share with you some of the unique facets of the Mozy Awesome Process that until now have been tightly controlled trade secrets of Mozy, Inc. It all starts with giant robots (virtually perpetual sources of raw Awesome). We attach them to special Awesome Siphons of our own design and pipe the yield directly into our engineers’ development workstations. Further, peripheral Awesome needs are farmed from old He-Man reruns, a roomful of ninjas wailing on electric guitars, and our captive Happy Fun Ball.

The crude Awesome is skillfully transformed by Mozy engineers into powerful software and hardware configurations, then carefully inspected and regulated according to a host of eldritch acronyms: SWAGs, PMQs, PRDs, and the ever-inspiring CFRRCs. Once a successful creation is stamped with the Seal of Acronymic Approval for Mozy (SAAM), it is subjected to final endorsement by the mystical, revered Mozy Leprecorn*. Finally, a highly trained team of Box Monks put the new Awesomery into place in the Mozy systems, where it becomes available to you, the user.

Our rigorous Awesome Enforcement Policies and Magical Oversight have brought us to what we believe is the most Awesome-efficient development process in the world of backup software.

Be safe,
Paul Cannon
Mozy Software Engineer

*Leprecorn (noun): a rare but phenomenal creature; half Unicorn, half Leprechaun, and all magical.

Visit Mozy now for a great reliable online backup service, I use it myself.

Vote for Mozy
Lifehacker is currently holding an online backup showdown. Show your love for Mozy. Vote now.

Future presidents can learn a lot from all this -- do exactly what the Bush Administration did! If the law holds you back, don't first go to Congress and try to work something out. Secretly violate that law, and then when you get caught, staunchly demand that Congress change the law to your liking and then immunize any company that might have illegally cooperated with you. That's the lesson. You spit in Congress's face, and they'll give you what you want. The past eight years have witnessed a dramatic expansion of Executive Branch power, with a rather anemic push-back from the Legislative and Judicial Branches. We have extensive surveillance on a mass scale by agencies with hardly any public scrutiny, operating mostly in secret, with very limited judicial oversight, and also with very minimal legislative oversight. Most citizens know little about what is going on, and it will be difficult for them to find out, since everything is kept so secret. Secrecy and accountability rarely go well together. The telecomm lawsuits were at least one way that citizens could demand some information and accountability, but now that avenue appears to be shut down significantly with the retroactive immunity grant. There appear to be fewer ways for the individual citizen or citizen advocacy groups to ensure accountability of the government in the context of national security. That's the direction we're heading in -- more surveillance, more systemic government monitoring and data mining, and minimal oversight and accountability -- with most of the oversight being very general, not particularly rigorous, and nearly always secret -- and with the public being almost completely shut out of the process. But don't worry, you shouldn't get too upset about all this. You probably won't know much about it. They'll keep the dirty details from you, because what you don't know can't hurt you.

Tests by heise Security show that four of the six services tested were vulnerable to attack.

While all of the tested systems encrypt communication with the backup server using SSL, external attackers can sniff the access code as plain text by acting as a man-in-the-middle (MITM) if the locally installed backup software does not perform sufficiently rigorous checks on the authenticity of the server’s certificates. In the vulnerable systems, we were able to hijack the connection from the client software to the backup servers.

Four of six may not be a large test sample, but it does raise concerns about trust between customers and their service providers. If you’re providing or purchasing this kind of service, you might want to look into it closely to make sure your data is secure.

Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?

I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example.  The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.

But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.

You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season.  J

One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.”  He was not alone, I assure you.

Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.

Richard Derwent Cooke wrote,   “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”

At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.

To be effective, training needs to happen in an environment:

·         Where expectations are clearly set (the SDL sets specific minimum requirements).

·         People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).

·         Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).

·         Where management models the behavior (recall the original BillG TWC memo).

·         Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).

Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.

To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.

 By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even  decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects.  And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.

And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior.  Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .  

We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.

I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.

So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.

Quite clearly, web browsing from within these ISPs now depends on the correct functioning of the “Layer 7 switch” and Phorm’s “Anonymiser” machine. This should not be too much of a concern. Network engineers are used to designing out “single points of failure“. Thus, for example, the BT schematics obtained by The Register show parallel systems and cross-coupling of components, so that a single failure will not take out the system. Add in the fact that what are apparently single machines will almost certainly be clusters fronted by intelligent load-balancing devices, and the system is expensive, but extremely resilient.

However, there’s another rather less obvious issue that needs to be addressed.

The bouncing of all web requests back and forth with HTTP 307 redirections means that the system is critically dependent upon the correct resolving of the webwise.net domain. If, for whatever reason, the domain name system (DNS) didn’t return the correct answer when asked for the IP address of webwise.net, then everyone at that ISP would find that their browsing was seriously affected.

If the incorrect address came back as 127.0.0.1 then the customers wouldn’t be able to reach any websites at all — if it came back as the IP address of a machine in downtown St Petersburg, then that site could redirect their web sessions at will — and there’s likely some criminals in that city with some innovative ideas of what could happen next.

So the webwise.net domain has suddenly been promoted to become part of the Critical National Infrastructure (CNI).

The domain is currently hosted at GoDaddy, an american registrar. Last summer the rock-phish gang spent a week running phishing attacks not just against banks, as they usually do, but also against GoDaddy. The immediate reaction was that the criminals wanted to use captured credentials to purchase domain names for free — but wiser heads pointed out that with the login details for a GoDaddy account you were in full control of any domain names that had already been bought : the security of the websites of thousands of major companies (and a great many banks) was resting on the security of eight-character registrar login passwords.

However, firms that have considered the risk don’t buy $10 domain names, but spend rather more, and their registrar will insist on rigorous security checks before altering any details. We must obviously assume that webwise.net is not at risk from registrar phishing in this simplistic way.

The more likely way of subverting what webwise.net resolves to is called “DNS cache poisoning”. There are several ways of doing this (this Wikipedia article provides a helpful summary), most of which shouldn’t work if the ISP has configured their DNS server correctly.

However fundamental weaknesses in the DNS protocol (relying on 16bit values matching to show authenticity) means that DNS forgery attacks can only be made harder, not prevented altogether. Making it harder may currently be sufficient to make phishing attackers use simpler methods — but if the prize is the disruption of web browsing for millions of people…?

There are things that the ISPs can do to improve security — such as each of them making themselves authoritative for webwise.net, which should address the DNS forgery issue. Let’s hope that they haven’t overlooked this.

[[with acknowledgments to Matt Johnson and others involved in understanding this particular design risk]]