Heartbleed showed that a monoculture, particularly one relying on poorly written and barely reviewed code is a bad thing. OSS or not. That the source code was fixed so easily just highlights to me how the heartbeat feature it was never properly reviewed or tested, and how people using openssl or incorporating it into their products never questioned it. The many eyes argument fails when you realize how few qualified programmers looked at the code. Given how wide spread openssl is, getting that fix rolled out to all the s/w and h/w that have it embedded is a nightmare. Just think of the Billions being spent to audit and test across enterprise networks, and update all that software.

Sure openssl will get more scrutiny for a while, but it doesn't fix the underlying fallacy that OSS automatically means quality code regardless of whether its commercial, free, or otherwise licensed. Or that OSS projects quite often have a shoestring budget, lower quality programmers, and less far less review than closed, proprietary software.

This is true, and exactly how this was found by Codenomicon. Having access to the source code actually makes it far easier to turn the bad behavior into a working exploit, particularly for something like buffer overflows. Although in this case, there wasn't much work needed as the bad behavior was returning the contents of memory in response to a bad parameter.

The irony is that the openssl authors chose to roll their own malloc implementation instead of using the default, trusted one which would have likely crashed instead of facilitating the leakage of memory. (I still blame the fundamentally flawed nature of C for even allowing this)

http://www-nrd.nhtsa.dot.gov/P...

An NHSTA sponsored study says at any given moment during the day, 5% of Americans are driving while using a cell phone.. The study has some caveats - it relied on phone surveys, visual road-side observations, and only goes up to 2011, so may be significantly under-reporting cell phone usage. I estimate that number is closer to 10% based on casual observation while driving. So in a two -car accident that gives a 10% chance of a cell phone used in one of the cars. If the real cell-phone usage number is closer to 15%, then the 26% number is meaningless as it's typical of the overall population regardless of cell phone use.

When I see a stupid driving move, the person is invariably holding a cell phone to their face, talking and gesticulating wildly while they're the only person in the vehicle (hands-free), looking down at something (texting or dialing), or it's a woman putting on makeup while driving.

Didn't the power industry say the same thing? Never, ever, assume the network is safe and not internet accessible if you don't own the network.

How exactly do you "backup" a bitcoin to protect it from theft? Backing up the coin info does zero good if someone already managed to effect a transfer of that coin. It's no more helpful than having a copy of your last bank statement after someone cleaned out your account (expect perhaps for FIDC insurance might payout on the loss).

Certainly, you're an idiot if you only keep the information in one place and risk losing it due to a simple HD crash. Safety of the coins from accidental loss was the allure of these exchanges. No-one really considered the theft aspect hard enough.

So has anyone tracked those coins to see where they went? The good (or bad) aspect of bitconis is their traceability. Did they eventually end up buying goods or getting cashed out somewhere?

Citing PCI compliance don't do much. After all, look at how badly the credit card companies are doing with intrusions and compromises.

Really? Tampering with the DNS root servers is something that everyone would notice. It's not something NSA would be likely to start tampering with. Manipulating DNS at local levels perhaps, but certainly not at the root.

I'm more concerned about US Govt manipulation of DNS at the behest of corporations for copyright enforcement by killing websites. We've already seen that happen

Near as I can tell, most of the technology flow (at least recently) is in the other direction, i.e. now that extremely low loss mirrors, etc are available they are upgrading LIGO to use them. Obviously they have a special use case and deserve kudos for developing their own fabrication techniques and applications of the technology.

The "big payoff" hasn't happened yet and isn't clearly defined. What exactly would the payoff be? I can see how correlating an observed perturbance as measured by this large scale interferometer with xray telescope data from an observed cosmic event could lend credence to therories about gravity waves.

They've sunk over a billion into the Hanford and Livingston observatories. The LIGO observatories from 2002 to 2010 were only operational for a very small fraction of the time, plagued by equipment problems, never acheived the design sensitivity, and NEVER detected anything useful. Most of their data was contaminated by local noise, including the highway a few miles away. They blindly collected terabytes of raw data that has never been fully analyzed and they have minimal local data analysis capability.

Now NSF is pouring even more money into it in the hopes they can improve the sensitivity and actually detect something? At best they might record a perturbance that is correlated between multiple sites (they also partner with an Australian site I believe), of which the value of that data is still debatable.

I wish the NSF would pull the plug on this waste of resources and invest in something more useful like cleaner nuclear power.

You do realize that performing https proxying and packet inspection to protect against malware is not the same thing as actively recording the sessions right? Regardless of whether they are proxying via MITM, they can still record the urls visited.

Also, the exact situation that the OP was attempting (a VPN that could expose the internal network) is one reason for using https proxying and filtering.

Um no, code review didn't find this - at least not the people that are supposed to. The bad guys apparently found and have been using this bug for quite some time. So obviously the black hats are more motivated to review the code than the white hats.

But then you can't have a smart car with a moisture sensor and rain detector to automagically turn the wipers on for you. Although, I have gotten spoiled by not having to remember to turn on/off the headlights. Same deal for interior lights, - you could go with the old school mechanical switches but it is nice to have them turn on at the appropriate times and turn them selves off if your toddler left the light on and you didn't notice.

Brakes and steering are still mechanical, btw.

The only thing AFDX has in common with ethernet is the mac layer. It's incompatible with and looks nothing like standard tcp/udp you normally see running around on ethernet nowadays.

There are multiple busses in vehicles already, separated by function. Engine controls are usually on a higher speed can bus, stuff like the speedo and body (lights, doors, etc) on a low speed can bus. I can see adding a third bus for entertainment type stuff such as the radio sat nav, wireless hotspot etc.