I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.

Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.

Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"

Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:

The long, laborious setup:
git init

Saving changes:
git add --all .
git commit -m "This is what I did."

Undoing changes before saving them:
git reset --hard
git clean -fd

Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.

Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!

That's a depressingly accurate statement.

Everyone seems to forget that the Rocketdyne F1 motor's fuel pumps alone had 55,000 horsepower, used for nothing but to pump kerosene into the main combustion engine, and use the exhaust from that gas generator to protect the nozzle extension from the much hotter temperatures being created by the rest of the motor.

This is the single most powerful thing ever created that didn't use a nuclear isotope to make the power. Yeah, it was pretty complex.

Thanks for the insult. It hardly stung.

Unless you worked at Netscape in the mid-1990s, no insult was intended.

All I meant is that by the very early 1990s, we (and by "we" I mean people smarter than me; I was clueless at the time) had a pretty good idea that CAs wouldn't work well outside of real power hierarchies (e.g. corporate intranets). But then a few years later the web browser people came along and adopted X.509's crap, blowing off the more recent PKI improvements, in spite of the fact that it looked like it wouldn't work well for situations like the WWW.

Unsurprisingly, it didn't work well. Organizing certificate trust differently than how real people handle trust, 1) allows bad CAs to do real damage, and 2) undermines peoples' confidence in the system.

A very nice way of saying this, is that in hindsight, the predicted problems are turning out to be more important than we thought most people would care about. ;-) It's almost as though now (no fair! you changed the requirements!!) people want SSL to be secure.

Keeping the same organization but with new faceless unaccountable trust-em-completely-or-not-at-all root CAs won't fix the problem. Having "root CAs" is the problem, and PRZ solved it, over 20 years ago.

I expect you to start the project shortly.

It's a little late to start, but I do happen to still be running an awful lot of applications (web browser being the most important one) which aren't using it yet.

He was obviously talking about building your own hardware. Did you really think his parts list of "A small controller, an LCD display and a keyboard," was in reference to writing an alternative to OpenBSD?

How does Diffie-Hellman key exchange provide identification of the other party? .. It is not possible to determine who the other party is

It's possible. It requires an extra piece beyond the DH, but that extra piece isn't PKI. The user is the trusted introducer. The user looks around and says "Yep, these are the only two devices physically here that I have ordered to peer, right now." They are identified by being in the right place at the right time, triggered by the user saying "Now." That's a pretty good way to do things unless you're just totally surrounded by spies.

Self-assessment is the method used by the vast majority of small businesses, and they're often not even required to do even minimal work to get started. The acquiring bank will just set them up an account and start the ball rolling after Farmer Bob buys a cheap swipe terminal off eBay for the weekend Farmer's market and signs a couple papers. For those organizations that aren't self-assessing, they get to deal with the fact that QSAs often can't even agree on what some requirements mean in principle, let alone when applied to their specific circumstances. Show three different QSAs the same architecture and documentation, get three different reports. That ROC? That's good for toilet paper by the time the QSA pulls out of the parking lot. Don't believe me? Have a data breach and watch Visa roll in with auditors who won't leave until they find a reason to fail your compliance. That's just how the game is played.

All that said, people just declaring that they are PCI DSS compliant is actually exactly what happens. You tell the acquiring bank that you're PCI compliant (either via SAQ or QSA/ROC). If you've met certain levels of activity, the acquiring bank may pass along some paperwork regarding your audits to certain payment brands who require it. They then effectively state that your paperwork appears to be in order and begin processing your credit card transactions. At no point do they declare you PCI DSS compliant and they will most certainly toss your ass to the wolves the second there's a whiff of trouble. And even if they did say you were compliant at filing time, any QSA will tell you that any minor change, lapse, or mistake can completely alter the state of your compliance. From the PCI SSC website: "There are three steps for adhering to the PCI DSS – which is not a single event, but a continuous, ongoing process."

In other words, yesterday you might have been compliant, and tomorrow you might be compliant, but today (always of course the day of the breach), you're non-compliant.

This depends entirely on the organization and their acquiring bank's requirements (ultimately the acquiring bank is the only one who matters, but most reasonably organizations develop their own process to ensure they're covered as much as possible). For many small businesses, they're often times just buying a cheap terminal and swiping away. The acquiring bank isn't pressing them for details of their security measures and they're often completely clueless about any requirements they're supposed to be meeting. They aren't bringing in a QSA. Even if they were, bring in three QSAs to any decently sized organization and get three different opinions about your scope and your compliance measures. Half the fun of PCI assessments is determining what the requirements mean, how they apply in your specific instance, and where scope ends. But the point is, there's no issuing authority to say that you're PCI compliant. There's no governing body certifying anyone. The only thing that's actually there are the contractual relationships between the merchant and the acquiring bank and the contractual relationships between the acquiring bank and the payment brands.

It's not a pointless semantic game because it's the unspoken risk for anyone accepting credit cards. Since there is no official PCI certification and since there is no agreement between QSAs on what the requirements mean in principle (let alone in practice in a specific organization's situation), the PCI SSC gets to stick the claim up on their website that no breach has ever occurred in a PCI-compliant vendor. Best of all, each individual payment brand actually gets to decide what requirements have to be met in which situation by which type of vendor doing what type of business at what scale and via which medium. The ambiguity and the leverage the payment brands hold allows them to arbitrarily decide who is and who isn't compliant at any given moment.

So you keep on doing your documentation and your testing processes (and you should, it's good practice), but if you think for a second your customers are somehow protected from Visa, Mastercard, etc in the event of a breach, you'd best think again. It's a shell game designed to ensure that whenever things go south, the payment brands are never the ones left holding the bag.

I'm surprised California would even be in the running. Land is expensive, taxes are high, and cost of living is among the highest in the country.

By contrast, Arizona and Nevada have cheap land, low taxes, and low cost of living plus low labor costs.

California's main asset is its technology population, plus access to sea ports.

Should be interesting to see who wins. I would have thought that Mr. Musk would prefer to place his plant in a low cost region like Malaysia or south China, but I guess there are logistical and political reasons to keep it in the home country.

It's a small part, but it's a part. I think Snowden has done his fair share of trying to inform laymen and stir up giving-a-fuck. If he wants to switch to working on tech, he could accomplish nothing and still come out far ahead of the rest of us. ;-)

The existence of a decent open-source router can't do much against a U.S. National Security Letter.

While we certain should care enough to force our government to stop being our adversary, there will always nevertheless be adversaries. You have to work on the tech, too. Even if you totally fixed the US government, Americans would still have to worry about other governments (and non-government parties, such as common criminals, nosey snoops, etc), where you have no vote at all. You will never, ever have a total social/civic solution which relies on, say, 4th Amendment enforcement to keep your privacy. I'm not saying your chances are slim; I'm saying they're literally 0%.

Furthermore, getting our tech more acceptable to layment acually would correct some of the problems inherent with NSLs, improving the situation even in a we-still-don't-give-a-fuck society. If you do things right, then the person they send the NSL to, is the surveillance target. The reason NSLs (coercion with silence) works is that people unnecessarily put too much trust into the wrong places.

For example, Bob sends plaintext love letters to Alice, so anyone who delivers or stores the love letters, can be coerced into giving up the contents. OTOH if they did email right, then if someone wanted to read the email Bob sent to Alice, they'd have to visit Bob or Alice. That squashes the most egregious part of NSLs, where the victim doesn't even get to know they're under attack.

That's true whether we're talking about email, or even if Bob and Alice get secure routers and VPN to each other. One of them gets the NSL ordering them to install malware on their router.

A nice step ahead would be the establishment of a new set of root certificates...

The lesson of CA failure is that there shouldn't be root authorities. Users (or the people who set things up for them, in the case of novices) should be deciding whom they trust and how much, and certificates should be signed by many different parties, in the hopes that some of them are trusted by the person who uses it.

If you want to catch up to ~1990 tech, then you need to remove the "A" in "CA."

Because there's absolutely no way for Orion to dock with something else that has yet to be developed, launched separately, meant to support a longer mission.

Right?

Rendezvous with an asteroid is about the same as rendezvous with another small orbital body, like a space station. You match your orbital plane, and then you plot a point of intersection between your orbit and the target. You match velocity and orbit with a maneuver when you get close. You then get nice and close, and do what you're gonna do (take pictures, grab on, etc.).

As with all things, the devil is in the details. But we've gotten really good at rendezvous - we've been doing it in orbit since the 1960s in Gemini, we've done it in lunar orbit. There's no reason to say that rendezvous with a giant lump of rock would be any different - it's just crunching the math on how much delta-V is necessary, and then building hardware to get it done.

Clicked (thought submitter screwed up the link and linked to a page that links to the article, rather than linking to the article), expecting to find a story about a forgotten A2000: maybe someone walked into an office in 2014 and saw that one was in use. Or someone knocked down a wall in 2014 and found one bricked up but still powered up. Instead, found a page telling everyone what A2000s are. Duh. Where's the "forgotten" part? All that I can tell that was forgotten, is that the writer forgot his elementary school spelling and punctuation lessons.