While I agree with your general line of reasoning, these numbers look considerably worse when adjusted for deaths/MWh or YPPL/MWh.

In addition, 70 years may be too short of a time period for evaluation. AFAIK, nuclear plants aren't designed to withstand war, and we also haven't see that many plants retire.

(1) Your average user would not be able to implement this hack. Technical users would have to research/experiment/tinker and/or wait for other technical users to do the same and publish their results. This buys time (see point 2).

(2) It makes the drone maker look good and reduces the risk of kneejerk legislative responses.

(3) Anyone who modifies their device to do this will receive the blunt of the blame. Blame will be apportioned less to the manufacturer, the regulations, or the general concept of consumer drones and more to the individual. Instead of being portrayed as a drunken fool doing something dumb but ultimately harmless (like the guy in the recent White House incident), the media will portray them as a shady hacker with possible terrorist intentions.

(4) Prosecutors who want to hang the operator out to dry will probably find more legal hooks to do so, since the operator intentionally disabled a "security" feature.

(1), (2), (3), and (4) are all good things for the manufacturer, who's market lives or dies by legislative and regulatory edict. That makes this worth doing, even if there's a jillion ways of undoing it.

The cost is paid for by some combination of shareholders, employees, customers, and insurers. You can't really say what that combination is. If you magically eliminated all ATM thefts/fraud, most of that benefit would go to either shareholders or top-level management. However, if the labor market were tight, that benefit might go to higher salaries for ordinary employees. Then again, if competition is fierce, the savings might be used to lower fees or pay higher dividends on interest-bearing accounts. Perhaps something more complex would happen, like hiring additional programmers so more work process could be automated, thereby resulting in layoffs for other personnel. All of these outcomes have more complicated second level effects, since they would ripple through the economy at large.

What you can say is that we as society pay at large, since the damage to the machine/building is a net loss for humanity, and the effort of participants (police, bank personnel, ATM designers, and even the burglars themselves) could have been better spent on their next best opportunity cost. (The one exception might be if these were subsistence burglars, in which case the overall cost to humanity can be harder to calculate.)

Easily solved:

BUY NOW!! Super-fast-ultra-speed internet** is available in your area!!

**Up to 1Mbps or beyond!
(And oh yeah, we'll still hijack DNS NXDomain responses, throttle Netflix/bittorrent, keep connectivity records, and spy on your traffic w/o a warrant.)

I see someone read Anathem.

If you don't have to have any features, then yes, you can make your software very, very secure. :-)

The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.

Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.

No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.

Hey, if your point is that too many PHB's and programmers think "managed" is a cure-all, I won't stand in your way. What I'm saying is that managed is a huge win for security.

By contrast, the most common security problems are any situation where you silently expect the programmer to manually preserve some invariant (e.g, never allocate memory without a plan to deallocate it, never deallocate if anything else holds a pointer to it, never write to a buffer without checking bounds, etc.). Managed languages eliminate C/C++'s largest (and most critical) attack surface.

Now sure, I agree that they don't eliminate all attack surfaces. Security is hard. Java/C# have their own "manual invariants", such as always escaping/parameterizing SQL. ASP.NET Forms have a nightmarish arrangement where some controls/properties auto-escape HTML and others don't. Crypto primitives are widely available but poorly explained. Multi-threading is a minefield. But even here, the industry can eliminate the widest number of security issues using secure-by-default design. In C# for instance, EF/Razor/TPL make it (1) easier to accomplish programmer intent while also (2) making it harder to break low-level invariants.

Office macros and PHP are some of the most hilariously bad designs in computing history. By necessity, any programming language worth its salt will let you make farcically bad decisions.

As a Google developer, he can probably just throw clusters of auto-recycling web servers at the problem. Aside from opening avenues for DOS attacks, the consequences of this sort of problem (e.g., not knowing how your GC works) have more to do with performance/reliability than security (albeit the 3 are intimately linked).

Something we can probably both agrees on is that there's no substitute for knowing how things work. However, the reality is that most programmers don't care and even those who do have a limited mental budget for complexity. So there's also no substitute for being able to eliminate sources of complexity that are ancillary to the task at hand.

Apparently, your experienced C developer is still leaving holes for arbitrary execution, despite all of the tools (fuzzing/NX/ASLR) targeting this specific issue. Managed languages (like Java and C#) give you a "secure-by-default" memory and execution model that's a lot harder to accidentally mess up. The more "stuff" (languages, libraries, operating systems, etc.) that's secure-by-default, the less security holes we will have.

Remember how cellular "feature phones" used to make an audible "ker-click" sound when you took a picture, and there was no option to turn it off? And how the gym prohibited all cameras in the locker room? Folks were worried about these increasingly ubiquitous cameras. Then smartphones came along and the cameras truly were ubiquitous and everyone sort of gave up... you can turn off the fake shutter sound now and that man in the corner staring down at his cellphone probably isn't trying to take a perv shot of you (probably).

I'm not defending Google here, or arguing that Glass is a good thing. Rather, that it's possible Glass will become socially acceptable once people get over the novelty of it. If I were advising Google, I'd tell them to add a prominent LED to the front of the Glass that glowed red when the camera was being used. Then people would "know" if you were recording or not.

The drawback, of course, is that this negatively impacts augmented reality (AR) applications, which are one of the big promises of Glass-like devices. In AR, the images are analyzed to detect faces/landmarks/surfaces/whatever in order to draw reminders/factoids/whatever in the user's field of vision. For instance, maybe Glass could be showing a mechanic the relevant portion of the service manual when he stares at $VEHICLEPART. Google could make it so that the LED doesn't light up when the camera is being used for non-recording purposes. The drawback to that is that Glass is then just one software hack away from being able to record covertly (e.g., without lighting up the public-notification LED)... so it'd really be better to stick with the first approach and hardwire the LED to the camera sensor.

Of course, you're still being recorded/tracked by a panopoly of public CCTV's, license plate readers, websites, and various other data cabals.

As a C programmer, you maybe haven't bought into OOP, templates, exception handling, metaprogramming, or other such features that C++ brought to the systems programming scene. Maybe, like Linus Torvalds, you've tried C++ and think it's a horrible language.

I myself agree with you (or rather, Linus)... except I'm coming from the applications world (C# mainly), where those nice features (that C++ popularized well and implemented poorly) are bread-and-butter techniques. I want to do systems programming with objects, exceptions, namespaces, reflection, etc., *but* I'm not willing to weather C++ for them, nor am I willing to drop down to C. Ergo D, except it doesn't really have a viable ecosystem at this point. :-( (And, like you said, JavaScript/Java/C#/Python/etc are fast enough for the vast majority of applications.)

Mainly, it's a systems programming language, meaning that it gives the programmer fine-grained control over memory and operations so that you can write operating systems, drivers, and high-performance applications. This is relevant because, aside from the two biggies (C and C++), there aren't a lot of other languages in this space. I mean, there's Objective-C (which sort of half-asses it), and recently Go and Rust arrived on the scene. All the other popular languages are pretty much for scripting (Python, JavaScript, PHP, etc.), or running atop a managed virtual machine (Java and C#).

As for what it offers... it's basically a re-invention of C++. No, no... it's deeper than that. It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.

Unfortunately, D has struggled to gain wider acceptance. It fractured it's community when D version 2 broke backwards compatibility with D version 1, and the forums (which run on a dedicated Usenet server, FFS) are filled with endless commentary about what does and doesn't work in the latest point release of the DMD compiler. Bright and Alexandrescu have certainly designed a compelling language, but they seem (from my distant vantage point) to be mired in implementation details... yeah there's a standard library and everything, but the surrounding ecosystem (standards, tutorials, tools, IDE's, API's, packaging, etc.) hasn't made the leap to that sort of functional minimum you see with (for instance) node.js or Haskell's "batteries included" experience.

TL;DR - D's a super awesome low-level language, but it's not yet a platform.

Check that make-a-law impulse. A desk job is just about the safest thing you can do (assuming you don't have to travel for work). Very little chance of suffocating a mile underground (mining), disappearing into the sea (commercial fishing), losing a limb (logging, mill works), or routine exposure to carcinogens (many factory jobs). (Obligatory slideshow: the twenty deadliest jobs.)

That's not to say OSHA should have no concern but office workers (which they do)... just that it should be proportional to the risk involved.

Read this brief on the perils of both sitting and standing, and then check the references at the bottom. Notably, standing all day leads to varicose veins and puts a strain on your circulatory system.

Just generally, the factory production line taught us long ago that holding the same pose or making the same motions all day long will have chronic repercussions. (If you ever have to work an assembly line, hope it's in a factory that practices job rotation so your tasks are varied over time.)

If we're going to stick to simple arguments: governments kill more people than terrorists; ergo, they are the greater threat.

Of course, if you want a more sophisticated argument, then you need to go back to democratic principles. Separation of powers, checks and balances, due process, and so forth. It's always about power and preventing too much of it from pooling in one place. No matter how noble government objectives are at the current moment (which you seem to have some charmingly naive assumptions about), you don't want to setup bad power structures or the next thing you know some low-level spook will be defacto dictator of your republic.

Alternately, you could point out that all this spying and intrusion on civil liberties is an enormous waste of money. The government could save wayyyyy more lives by focusing on cancer, heart disease, and vehicular deaths. Heck, poisonings are the second leading cause of accidental deaths, but nobody's insisting the government watch you take your meds or make you lock up your cleaning supplies.

And I don't know what you mean about slashdotters turning a blind eye to Facebook and Google... we bitch about that all the time too.

But with strong crypto it's secure enough that the 3rd party can see (or alter) your communications. Obama and Cameron and (undoubtedly) all other future leaders want to strip away this protection using the force of law to change how crypto products are designed. You will live your life under the state microscope and, as always, the proper prerogatives of government will be twisted to cover up incompetence and serve the powerful few instead of protecting the dignity of the individual.