Nonsense - the article comes across more weakly by taking a personal tone.

It's a technical article. You can like it more or less because of its tone, but if you're an engineer, you should be persuaded (or not) by the content, not the persuasiveness of the writing.

One shouldn't have to filter personal bullshit to be able to read technical content.

And? Perhaps one does in this case. If you're technically competent, you should be able to evaluate the claims in the article regardless.

I think the unfortunate side of this is it "feels" like there is an agenda, regardless of if that's the case or not. Technical basis aside, one generally wouldn't write a white paper on this format.

I'm not technically competent. At least as far as crypto goes. But I can understand things like "shortens the time needed for a brute force attack" quite fine. And many non technical people can do the same. By littering this article with petty personal bullshit, he commits the same sin as cryptocat: failing to inform users.

So what? He's not providing an encryption tool for LGBTQ activists, like Cryptocat claims to do. The bar he needs to meet is lower. Unlike the Cryptocat team, he is not actually obligated to inform Cryptocat's user base; regardless, he's done them a huge service by donating his time to finding vulnerabilities.

I agree.

They say you should write to your audience and this feels like the author did and it’s targeted at an audience - that, well, is not HN.

I wish it had been targeted at HN - as then I would have read it. But after the first couple of sentences I gave up - and waited for people with more fortitude, to read the doc and report back here. (Thanks to everyone who did that.)

It is difficult, to say the least, to conceive of some Platonic ideal of "the content" of a written work without being influenced, positively or negatively, by the style of the writing. Your profession does not make you immune to this.

This is a software engineering discussion. The "content" is links to diffs, plus sentences describing the diffs. If you can code, you can read the diffs and the sentences and reconcile them. If you can't, I concede, you probably can't do much more than talk about the "tone".

While I can't say I've ever looked at the source wouldn't most be able to imply that, even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

I get there are many others ways to skin this... However the author is at least trying and providing. As a prior comment stated, there are a lot of very good people in the security/crypto/dev realm in this very thread that have provided some awesomely D-bagish feedback.

>> even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

Easier to use does not imply better in this space. In fact it may be worse than not providing a product at all because it encourages people to think they have a secure channel when in fact it's trivially breakable.

> wouldn't most be able to imply that, even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

But in this case it's popular because it's easy to use than other systems and not because it's more secure than other systems.