http://www.wired.com/2014/04/o...

We can still break into the systems we "need" to break into, without keeping a full hand of all possible vulnerabilities. To reduce our overall exposure to risk, it makes sense to disclose most of these to vendors for patching, maybe some with a delay. Our government can buy up vulnerabilities from Exodus, then release them -- Exodus gets paid, we get somewhat better security all around, and the NSA gets a few last holes to work with.

There are situations where one could sue anonymously ( http://www.legalmatch.com/law-... ), and they should still have copyright protections ( http://commons.wikimedia.org/w... ) but proving themselves to be the actual authors and have standing to sue might be difficult?

Competition. Invisible Hand. Selective pressure from consumers who don't want a site with 80% screen real-estate devoted to ads, and subconsciously choose to spend their time on sites with (for whatever reason) fewer, better ads.
There are obviously limits and pressures already at play, or every site would be nothing but a wall of ads, because "more profit."

I'd like to opt out of the untargeted ads. I don't so much mind relevant, possibly-useful advertising -- I don't feel like it wastes my time so much, or even, in a way, creepily insinuates I would be interested in things I'm totally not. As long as the targeted advertising is done right, I'd rather have it. The more accurate such advertising gets, the more value-per-print it can generate, and therefore the less overall advertising will be required to sustain the "free" services we use. One well-chosen ad is worth dozens of spammy ones.

Or ... could we get the big advertising systems to allow us to pay them, centrally, to remove ads across all the sites they print on? And have them just forward a portion of the money to the sites themselves, just as they would have paid them to print an equivalent number of ads, while serving me nothing but 1px placeholders?

And other people are trying to resurrect/fork it, trying to get all the legal ducks in a row to meet the requirements of the license.

I've been curious how the original anonymous developers would be able to enforce the terms of their previous license ... even if they had some means of proving in court that they really were who they claimed to be, and had the right to sue, they would lose their anonymity in the process, which is of some value to them.

The anonymity of the developers is a double-edged sword, in this kind of product. It temporarily makes it harder for intelligence agencies (or organized crime) to put pressure on them, but long-term, is it worthwhile? Either their identities will be found out and used against them, or their continued anonymity will be used against the project by at least casting down on the trustworthiness of the project. Ownership of crypto keys (software signing keys) is a pretty good stand-in for identity, except that our laws don't have the same respect for them as for other cases of identity-theft -- they're "just data", to be handed over, and possibly abused.

(Doubting the usefulness of anonymity in no way endorses the likes of Microsoft, and their line that having an established identity entrains reputation, and the desire to protect said reputation in turn guarantees trustable software. At least with TC we have source, and a hopefully independent audit, and that's perhaps the most important piece in the end.)

Ugh. I'm one of those developers who would be affected, as I have custom FF extensions deployed for a mid-size client. We don't use the "Enterprise" FF though. I suppose we might have to switch, and deploy FF updates differently, just to keep the ability to run extensions (that have no business being uploaded to anyone's store, as they're entirely site-specific.)

I worked as a programmer for the sales & marketing arm of a cell company, 6 years ago. It was quite clearly stated (internally) that they wanted to get out of the subsidy business, but they couldn't. They were too small to take the risk of being the first or only to do so in their market. So long as other carriers were offering subsidies with their contracts, making the move would be suicidal. We probably weren't the only company in that situation, but unless you could come to some grand bargain, nobody was going to move first.

So does that mean you're suggesting the safest course would be to:
    (a) tell everyone to shutdown ALL OpenSSL-backed services, urgently.
    (b) after 1 day, tell everyone they can bring their 0.9.8 services back online.
    (c) after 1 day, tell the remainder that it's okay to come back online, with heartbeat disabled.
    (d) have the patch ready for distribution around this time.
?

I agree with the caution. TBD:
    (1) there's the risk that telling admins to shut everything down, all versions, without telling them why, will cause them to ignore the notice
    (2) while these services are shutdown, what will admins do instead? will they use insecure services because "the show must go on"?

Yes. You don't have to notify people of the exact flaw and how it can be exploited, to help them protect themselves while waiting for a patch. The immediate response should have been to tell people to disable heartbeat, or barring that, shutdown their affected systems. Yes, it would suck, but since you don't know for sure that the exploit is known only to the researchers, you should assume it's in the wild, and this is the only safe thing to do in the interim. (Could this be used as a form of DoS? Sure, if sysadmins get used to wholly shutting down services anytime there's a warning from anyone, or if the partial shutdown of one service in fact makes another service less secure. TBD.)

All this discussion of disclosing to OpenSSL first, letting them patch, giving distros time to get updates ready ... ignores that the moment OpenSSL goes to fix the bug, the patches are public. Attackers waiting to see a flaw in OpenSSL would be monitoring version-control regularly, to see if any given patch looked interesting. While your distros are being quietly told to get updates ready, the attackers are analyzing the patch to see what kind of bug you fixed, knowing that, because there's radio silence, sites are vulnerable.

Making a big stink about it is the only way to make sure sites actually get updated, anyway. Distros and whatnot having updates available does not get those updates installed. We don't have auto-update on any servers. As was discussed recently, many sysadmins have to submit patches to change-control boards for approval, and if there's not a furor over the issue, there's no emergency approval.

So:
    (a) a blitz identifying only the versions affected and what to do about it,
    (b) a patch release sufficiently delayed to give end-users a chance to shutdown affected services,
    (c) a blitz about the availability of the update, which people will care about more because they've already had to take action to protect themselves, and are possibly sitting in a shutdown state.

Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it

That's not at all unique to TrueCrypt. If someone guesses a user's password, it's the user's fault they used the same password elsewhere.

Password-strengthening before encryption is not the same as salting & hashing passwords for later authentication, where rainbow tables and "guessing" a password makes sense -- we're not talking about storing the resulting strengthened password where it could directly attacked ... unless, maybe, perhaps you're trying to say this is stored in-memory while the system is running, and that's the kind of attack you're trying to describe? I don't see why the strengthened password would even need to be kept in memory once it's used to unlock the real keys, which TC will need at runtime for crypto. Having to re-fetch the real keys based on the password at every i/o would be prohibitively expensive.

I mostly agree with you, although the article does also mention the murkiness surrounding the "dark pools" that banks run your order through first, where they could have the opportunity to trade against you, before forwarding to exchanges. The big exchanges might be vulnerable only to the multi-exchange exploit that is the meat of this article, but the "dark pools" are implied to have their own, different shadiness going on. Sadly, this piece doesn't explore that enough -- possibly because insufficient light has been shed on the issue to date. Investigations are in order.

Defamation laws, as far as I see, only cover the negatives, not the positives. You can have all the fake praise you like, as long as there's no fake complaint. Statements of "our service is great" are not the same as "my experience was terrible" -- there's an expectation that vague statements from a company may be misleading (bluster) while not really wrong in a verifiable sense, but with specific customer stories, we expect them to be accurate, fact-based. Ads may use actors, but they generally have fine-print identifying them as interpretations of, re-enactments of, or syntheses of multiple, actual customer letters.

Whether the reviews are true or not may very well depend on the identity of the supposed reviewer. If it's in the form of "they destroyed my carpet", the cleaning service could either try to prove that this has not happened to any customers ever, or that this review did not come from a customer to whom it actually happened. If it's not a real customer, then it's probably a competitor, and at that point, it's very much libel -- purposefully spreading lies for the purpose of damaging someone else's reputation. Reviews like this really do matter to a small business. If they reveal the identities and discover it was a real customer and a real experience, there's nothing legally they could do to remove it, because it wouldn't be libel, and would be protected. But they also can't do anything about it now, until they prove it's false, which requires them to reveal identities.

The alternate solution might be for all review systems to say "this review is anonymous [better: not a verified identity], so the person being reviewed really has no opportunity to face his accuser, so you should take this with a really big grain of salt". And maybe not even count it in the averaged star-rating. And then you've just killed their business model, because the identity/registration stuff is such a hurdle.

Amazing that when they run this kind of automated tool on a project of this importance and breadth, this is ... the only vulnerability it found?

This doesn't invalidate "many eyes" at all (as some are claiming here) -- the fact that a bunch of reviewers didn't find this one bug is unfortunate, but if "many eyes" had really failed, I would have expected automation to find dozens or hundreds of bugs.

Really? Because I'm pretty sure the standard conservative argument is that if you create an obstacle, people will always "find a way", and in fact you should purposefully do so. Don't give them food or shelter, and they'll magically educate and empower themselves.