I'm guessing it went something like this:

NSA: "Nice products you have! We'd like to license $10m of it please for our own use, but could you make this algorithm the default in the configs? It would save us a lot of headaches in our configurations and it's the best algorithm to use!"

RSA sales people: "OK! Sounds like you know what's best and your money is always good, of course!"

A different era. They might have actually thought the NSA were honestly helping. Back then the NSA was probably perceived as being as much about hardening encryption as breaking it.

Yes, there's nothing magical about it. All you'd need to do is find somebody who trusts you to pay them back and you effectively make a bet with them. They don't even need to own any Bitcoins themselves. For example, I might agree to give you today's value of 5 bitcoins but you'd need to pay that back to me within, say, 6 months and when you do so you have to pay what the value of bitcoin is at the time. Depending on how savvy and how much the other person trusts you, they may want you to put up some amount of cash in an escrow so you can't flake on them and run with the money without finishing the deal.

The government doesn't care when you trade bitcoins amongst yourselves, but if you *exchange* them either way for government currency, there are problems. In this case, you can trade USD for Bitcoins, and that's a big red flag.

Recovering the merchandise aside, can the company claim this as a loss for tax/insurance purposes?

...get car sick.

What about keeping a drive/Time Capsule in a locking mailbox at the curb? Of course, power might be an issue, but maybe slip a 12V line up into the box from the yard lighting to power it, or even some solar cell set up although you don't want to attract too much attention that something electronic is happening in there. If nothing else, it could be a convenient place to swap or grab backups as needed that is relatively 'off site'.

Exactly. When you ask the 20 somethings if it was appropriate, they would probably say 'sure'. Ask the exec and he'll probably say, 'no, unless there are special circumstances... like mine'.

I found the opposite to be true. The older demographic (who tended to be higher up) were the ones who took more frivolous calls during meetings. The 20 somethings usually left their phones at their desk. I suppose the younger people questioned might say they think that it is OK for the older folks to do that while if you ask the older folks they would agree that it isn't appropriate but they do it anyways.

I think that can be all well and good for a 'study' except for the last flip comment at the end: "And if you’re an older worker annoyed at what you believe to be rude behavior, just remember, it’s not you – it’s them!" The researchers clearly don't know how to interpret their own data objectively. The study was asking what people thought would be appropriate, not what they actually do!

Can we finally get a Mod total score above 5 yet on /.? This one would go to 11!

They have. We're still waiting for the classical computers to finish to compare answers. Should just take a few eons. Then we'll know it works.

You can do what Alain Aspect did which was to show that statistically a system can show the repeatable statistical measurements (using Bell's Theorem) that indicate that entanglement is happening. Then let the system/computer do it's thing with some confidence that entanglement is in play.

How is this different than a software vulnerability and security through obscurity, etc.?

I think to begin with, most software vulnerabilities aren't exploited to cause immediate death of (most likely) innocents. There's also no 'fix' for this (e.g. no software update to everybody's genome, but maybe a vaccine can be developed).

Similar to some other horrible chem/bio/nuke weapon formulas, yes, it should be properly redacted.

I think you can also document in a way that is also up to date. For example, do you document the who/what/when/why for version commits? Sure. Do you put in-line comments in the code, e.g. "We need to revise the code below at some point to account for ABC"? I hope so. Do you have a stash of reference scripts/how-tos so you don't have to reinvent how to do semi-routine complex actions, like deployment? What about an active system to keep track of to-dos, priorities and who they are assigned to, what happened, how they were accomplished? Even email history can be effective documentation.

Otherwise, I would agree that documentation in the form of a bulk document which is probably already flawed at 1.0 and easily outdated is mostly a waste of time. (Past the mental exercise of the person writing it, perhaps.)

as crazy does.