Hacker News Reader

Comment by aquabeagle | Hacker News Reader

Typical security industry contrarianism.

"Stop using that thing that mostly works as intended and is integrated into lots of email clients and systems, and has a number of independent implementations, and has the decentralized properties that match email."

"What should we use instead?"

"shrug You can send encrypted stickers in Signal, isn't that neat?"

If you're going to advocate for everyone to stop using something that they rely on, make sure there's a viable alternative for them to switch to first (or throw your weight behind making/enhancing one). Otherwise you're just telling people to stop using plastic straws and giving them shitty paper straws in exchange. People know they're bad but the alternatives are worse to them so they stick with the bad thing.

View on HN

If you consider PGP something that mostly works, and Signal the fringe contrarian view, then we have wildly different experiences around usability, and the relative popularity of those tools.

I couldn’t get any of my friends or family on PGP to save my life, and some of them are programmers. I am now at a 50/50 split in volume on Signal v WhatsApp, and most people I never even suggested it to. And they use it correctly (because that’s the only way you can).

Seriously: how is PGP something that mostly works, and how is Signal contrarianism? Isn’t it the other way around by now?

Signal is non-federated. That, alone, is a showstopper as an email replacement.

Open and federated protocols and services should be our target. It is hard designing them, but if we could do that in the past, we should be able to do so today.

Two replies about email replacement; I feel like we’re getting off track. Signal is for secure, end to end encrypted communication. Ideally that would be all communication, but that isn’t realistic in today’s world.

TFA merely says: if you were gonna use PGP, use Signal instead. It’s a trade off. While we target these open and federated protocols, let’s not throw people who actually need encryption today under the bus.

So to the question of replacing email: unless all your email is currently PGP encrypted, you don’t need to drop your email just yet.

> So to the question of replacing email: unless all your email is currently PGP encrypted, you don’t need to drop your email just yet.

You don't need to drop email at all. If you trade protocol openness for encryption, you are acquiring technical debt. How long are going to do this dance of switching between instant messenger protocols? ICQ -> AIM -> MS Messenger -> Hangouts -> WhatsApp -> Signal -> ???.

Open protocols (open in specs and federated in access) are the only way to stop this madness.

IMHO, Matrix currently has the best shot at becoming the standard for the open internet.

Those who value the freedom of choice should push for Matrix before Signal becomes the de-facto standard and is acquired by one of the tech giants looking to lock down control of communication.

Matrix is too dependent on it's only vendor in existence, their only server in existence has performance issues. Also, a monolith standard is hardly viable for federated networks, where all nodes can't upgrade all at once.

> [...], their only server in existence has performance issues.

This is either misinformed or disingenuous: https://www.hello-matrix.net/public_servers.php

All these server instances use the same server software, provided by the same vendor.

Ah, I did not realize you were referring to the software. In that case, there is also Construct[^1]. There are other implementations in the works, though progress is somewhat slow.

Synapse is much better with regards to resource usage these days, though. The RSS of my instance is 355M right now and the CPU usage is hovering around 0-10% (15-min server load ~0.5).

[^1]: https://github.com/matrix-construct/construct

Fortunately Signal is a well funded non-profit which reduces the likelihood of its acquisition significantly.

Anybody using keybase? I think they have excellent security, Superior to telegram and signal in some ways.

I wouldn't use keybase where I need reliability due to their vague TOS (that came into effect around the beginning of this year): They can ban you from their service if they deem your actions outside their platform unacceptable.

Interesting, I had to check their ToS and found this which seems a bit vague:

"[...]use the Services to store or transmit any inappropriate content, such as content that: (i) contains unlawful, defamatory, threatening, abusive, libelous or otherwise objectionable material of any kind or nature" [1]

(My emphasis)

[1] https://keybase.io/docs/acceptable-use-policy

Lots of pros

1) we use it as a slack replacement 2) git integration 3) stellar Blockchain payments 4) encrypted file sharing 5) great system for key management

In the past Google and Facebook supported xmpp(jabber) protocol. That was real step in right direction. You could use your client and OTR plugin to encrypt all communications. It all ended in 2015.

Do you have an opinion on why that happened?

(I think a lot of useful Signal properties are much harder to do with federation, but that’s a subtle enough problem that it warrants a long form post, not a HN comment. I agree that ceteris paribus federation is better than not—but c.p. is doing a lot of work there :))

Is there some reason to believe it didn't happen (mostly) for the reasons stated by the respective parties at the time? 'federated' is often brought up as an unalloyed good so casually but as you point out yourself, there's a huge overhead, conceptually, operationally, etc.

I'm still using ICQ...

> Signal is for secure, end to end encrypted communication. Ideally that would be all communication, but that isn’t realistic in today’s world.

Do you seriously believe that ALL communication working through a single proprietary non-federated service would be a good thing? !

I’m having a hard time believing just how polar opposite of my point people are taking me, I must be explaining myself very, very poorly.

Let go of the idea of “good”, nothing is currently good. Everything is terrible. The only thing that’s “good” is a federated, open, and secure in practice protocol (I.e. not just for people who use it properly, but for people who is it full stop. Like HTTPS, for example.) Today, we don’t have that. Let’s work towards that. Let’s make it happen tomorrow.

But today: federated or secure, pick one. (See TFA)

Meanwhile , there are people , today, with a real need for encryption. (See TFA) A need that transcends our long term plans. These people look at what “techies” do and say, and they imitate it. That’s the way of the world.

It is currently PGP. That is not secure, in practice when used by those people (see TFA). Therefore, we need to stop using PGP, use Signal for now, until we have an actually good solution that is better than Signal and PGP.

That’s the summary of the article.

Nobody is talking about replacing all email. Nobody says the status quo is good. Heck, nobody is really arguing for Signal, as much as arguing against PGP, and signal winning by default. That’s all.

We’re all on the same side here, guys. It’s just a matter of temporary compromise.

> We’re all on the same side here, guys. It’s just a matter of temporary compromise.

I get that, and I actually agree with you on almost this whole comment. The problem of the temporary compromise on Signal is that I don't believe it is temporary. Signal is actually good enough to prevent the transition to the optimum. Being non-federated, Signal will always have a single point of failure, but this will get masked until it is eventually exploited.

But if you rule out Signal there isn’t another choice for the users in question.

There is not a federated messenger that provides the same security as Signal.

Your argument reduces to (for the user segment under question) “don’t use electronic because I value federation”.

I value it too but that seems incredibly selfish.

> There is not a federated messenger that provides the same security as Signal.

Actually, there are federated messengers that provide better security and privacy than Signal. Yes, XMPP ones. They might not have the same convenience yet, yes, because they are not tied to phone numbers, but don't even get me started by trying to say that tie to phone numbers is a plus.

Name a federated message tool that is more secure than signal for a user who is not a tech expert and whose life is potentially on the line.

Conversations, Xabber, Chatsecure. Any of these is more secure than Signal: they are not tied to phone numbers (means: way more privacy), work with TOR easily, and starting a secure conversations is no more difficult than 'add contact' (enter contact XMPP id) -> 'press lock' -> you're ok, chat is private, and your phone number is not exposed.

Actually, this phone number thing is the main reason why I find it hard to suggest using Signal to anyone who's life is on the line.

Can you explain why any of this is more secure than signal with sealed sender? What is the privacy impact of tying to a phone number, beyond the one bit: I have signal?

As far as I can tell, sealed sender leaks less metadata than omemo currently does, which makes tor etc. Mostly irrelevant. Plus, I'm not going to fuck up signal, while I will misuse Tor.

Tying to phone numbers makes identities expensive.

What's the threat model that requires multiple identities?

From privacy point the standard is using separate identity for every action, if possible. - That's also a major bummer for Briar.

That's not a threat model, and not generally possible (or even desirable) with something like a messaging app. So again, what is the threat that you wish to address that you believe is only solvable with multiple identities?

This is an important question, because cryptographic repudiation and secured metadata prevent most of the dangers that I can think of, but I might be missing some.

If your life is actually on the line you are better off doing some research on how to use PGP properly. Otherwise you have no good way to know if you will end up with something strong enough to use against state actors. The simplicity and strength of PGP is hard to beat. Riseup.net has an entire section mostly about OpenPGP:

* https://riseup.net/en/security/message-security

The actual article were commenting on right now is literally about why this doesn’t work. That’s the whole point of the article.

One example (from the article) is other people accidentally replying to your encrypted messages in plain text, including the entire reply history.

This is what TFA is about. PGP is not safe for people who actually need encryption.

Here's the Signal version of the riseup.net article:

> Purchase a modern android or iOS device and install Signal. Your communications are now secure.

Given the security provided by signal, why do I need to understand the message authentication schemes, private key management, keyservers, versions, etc.

> The simplicity and strength of PGP is hard to beat. Riseup.net has an entire section mostly about OpenPGP:

Given that, in practice, basically no one's use of PGP provides security or privacy beyond what I get when using Gmail or Outlook, I beg to disagree.

How in god's name can you claim that a 6 page article describing the ~20-30 steps to correctly set up a keyring (oh and then keep up your opsec for the life of your communication because pgp doesn't provide forward secrecy and the protocol makes it possible to transfer plaintexts unencrypted) is simpler than "Install signal, and send messages"?

They're secure right up until the point someone with the ability to do so spoofs your phone number.

And yeah, Signal will detect that and inform the other side that "security number has changed". At which point they'll promptly confirm the new one, because they don't understand its purpose anymore so than private key management etc - because they simply installed the app from the store, and expect it to "just work".

> Signal will detect that and inform the other side that "security number has changed"

Specifically, it will say "Your safety number has changed...This could either mean that someone is trying to intercept your communication, or that <other party> reinstalled signal."

Even for a layperson, if they have reason to be concerned about a powerful attacker that's reason enough to stop.

I have switched quite a few casual users to Signal by now, and in my experience, none of them have paid any attention to those regardless. They don't even bother asking the person through some other channel - just confirm the new number.

Assuredly, but most people aren't actually that concerned about state sponsored attacks on their communications, and for those people Signal is still as good as (or better than) PGP email, but they can safely ignore these notifications because, well, the likelyhood (and the risk due to) a state sponsored attack is relatively low.

Signal can't work on an air gapped system. So it is entirely subject to all the available attacks on the rest of the system it is running on. Someone risking their life no the overall security of something like, say, a smart phone is not being wise.

Something like Signal is OK for most people, particularly if they trust the Signal company. But when things get serious you have to:

1. Know what you are doing.

2. Keep the device that is doing the encrypting as separated from the rest of the world as possible.

> Signal can't work on an air gapped system

If this is the kind of thing you're resorting to claiming, we're well beyond reasonable forms of argument, and so I think it's safe to say that you agree that signal is better.

No communication protocol works on an air gapped system, and a modern Android or iOS device is going to be secure enough that you really don't need to use a special device for your messaging.

The riseup article doesn't mention anything about using a special device for your secure messaging, so I'm not sure why you think it's so important all of a sudden.

You mean gmail?

> TFA merely says: if you were gonna use PGP, use Signal instead.

The article mentions Magic Wormhole, age, and Signal, IIRC.

So ergonomics trump security for you. That's fine. Stop telling people that they can safely follow your lead, because you've prioritized things other than their safety.

An incremental evolution may cause us to get stuck in a local maximum. You are correct that the incremental step is necessary. You are ignoring that this incremental step sets us onto a path of closed protocols. In time we'll be worse off.

So that's two things you think we should prioritize over people's safety: ergonomics and technological progress. You're digging the hole deeper for your argument.

Only one. I never mentioned ergonomics.

That's what federation is. All else being equal, you'd prefer people use less secure messaging so that you can have greater choice of clients and servers, and run your own server.

I don't get the implication between federation and ergonomics. Federation is the ability for competing providers to operate in the protocol space. Does it lead to better ergonomics, worse ergonomics?

I don't think it impacts ergonomics.

What federation does is:

a) Remove the single point of failure present in Signal;

b) Promote competition between service providers.

None of these can be argued against.

Note that I'm not defending we stick with email. I'm defending we shouldn't move to a non-federated protocol. That fixes one thing and breaks another. Choose xmpp, matrix, design a better messaging protocol, ... Just don't take a step forward when facing the abyss on the merits of taking forward steps.

They can be argued with, easily. But we don't reach that argument, because it has nothing to do with safety. You make choices in favor of "federation" and "progress" because your life is not on the line when you send messages. That's fair! Most people's lives aren't on the line! But when we talk about messaging security, we have to consider the users for whom secure messaging is intended: people who really are entrusting their lives to software.

It's helpful to compare secure messaging to medical software. If we were talking about the software that controls the radiotherapy machine, no rational person would would have any priority other than safety. But of course almost nobody interacts with radiotherapy software, and everyone interacts with messaging software, so it's hard to see the connection. But it is there.

So, it is not about ergonomics or any other argument, except for security in an undisputed altar. I disagree with the principle, but personal principles are not challengeable. We'll have to disagree.

Just keep in mind this principle is personal, not shared with you by everyone. For example, I distrust security by central organizations, like Signal.org. They're an amazing target for bad actors.

Correct: in this particular problem domain, safety is the overwhelming priority, just like we don't care about the UX framework or the open source-ness of radiotherapy machines.

You should care about opensourceness of personal medical devices like pacemakers and insuline pumps though. Precisely for safety concerns.

Haha this comment must be maximum HN. Hats off!

Nobody talked about usability or widespread adoption.

Article was targeted at people who are using PGP and urged them to stop using it without, offering a viable alternative and the parent comment called it out.

> Nobody talked about usability or widespread adoption

This directly contradicts the original comment.

> Article was targeted at people who are using PGP and urged them to stop using it without, offering a viable alternative and the parent comment called it out.

The article has an entire section explaining alternatives. The first link in the article [1], also written by the same author, has an even longer list of alternatives. It's hard to miss.

[1] https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

If you consider PGP something that mostly works, and Signal the fringe contrarian view

We're talking about email here, so yeah, the number of encrypted emails I've received with PGP is non-zero and through Signal is zero.

There's a lot of good things to say about Signal, but if it should replace email:

How do I export it for long time storage and for auditing?

Edit: to avoid confusion, I read in the help files that I can export my chats, but it seems clear that those exports are only supposed to be imported into another instance of Signal.

I don't think Signal should replace email. I don't think email is going anywhere.

Edit:

So, your point over the last couple of years can be distilled down to:

- use Signal if you need actually secret mesaging.

- otherwise: anything goes, including iMessage and email.

- don't participate in security theatre

(Was:

------ So, again if I read correctly:

- unencrypted mail good,

- encrypted mail bad

------

But this is a not so subtle reference to Animal Farm and while it is probably funny it goes far beyond what I mean. )

I don't think either are good options. I was reading on here recently about the $2.1M that the US gov paid (indirectly) to Signal, with the implication of the associated compromise of integrity. And PGP is so labyrinthine that most of the mail tools implementing it had been compromised for more than a decade. [1]

Whatsapp? It's owned by Facebook, as we know, and I wonder if we can believe that we put on there is actually safe. I think that would be naive.

[1] https://arstechnica.com/information-technology/2018/06/decad...

Hi, I'm having trouble finding any information on the 2.1M that you said the US gov paid Signal Foundation. Do you have a source? I'd love to know if this is true.

The OP is probably referring to financing that Open Whisper Systems (precursor to the Signal foundation) received from Open Technology Fund (https://www.opentech.fund/results/supported-projects/open-wh...) which according to the Wikipedia has ties to the US government (https://en.wikipedia.org/wiki/Open_Technology_Fund). I guess the idea was to provide encrypted means of communication to dissidents in US-hostile countries.

Though I think it is a moot point. Signal foundation is a US organization and its officers are US citizens. I don't think the US government will have any trouble coercing them to do its bidding regardless of whether it financed them or not.

I see. Since the PATRIOT act was put into place the US government can pretty much justify anything at this point so i tend to share the same viewpoint. Thanks for the sources man.

>None of the vulnerable programs enables verbose by default,...

So the compromise is mostly theoretical...

> Seriously: how is PGP something that mostly works

The entire Debian infrastructure is secured with PGP. PGP emails, PGP signatures, PGP encryption.

Seriously: it doesn't just "mostly work". It's rock solid battle tested for 20 years, and thousands of people use it without needing hand holding.

The topic here is “PGP in e-mail”, not PGP full stop. It’s all in the TFA, including a comprehensive list of reasons why it does not just work. Even with handholding, let alone without. If you disagree with any of those specific examples, please do elaborate, but at least address them. They’re good points.

Nobody is suggesting people switch to Signal for distributing .debs...

The author is not saying to stop using email. He wants you to stop pretending it can be secured. If people think that "works as intended" means their email communication privacy is secured, and their personal safety depends on it, then those people are in danger.

Basically, he argues you can't trust encrypted email for any content you would not also be fine to send over an TLS secured wire.

The title is "Stop Using Encrypted Email" though.

And you should. Because it’s pointless, as he demonstrated quite well.

That sounds congruent with both GP’s point, and the intent of the author.

Yes, which confirms the parent comment's point. Note the title refers to encrypted email, and not email in general.

That sounds awful close to advocating in favor of more plain text and less encryption.

It sounds like that, but because of how encrypted email actually works in the real world, it's actually the opposite.

That sounds like an extra ordinary claim that telling people to encrypt their email will cause more unencrypted emails.

Claims like that need extra ordinary support. Spend money on a study where one company employees are told to encrypt their work emails, with an other company being told to not encrypt their work emails. At the end of the study, see which one encrypts more.

Common intuition say that the one being told to not encrypt will not have more encrypted email conversation than the other. At worst both have the same amount, and at best the one being told to encrypt has more encrypted conversations because they are more security aware.

If it's an extraordinary claim, it's backed by extraordinary evidence. Modern secure messengers make it difficult (or even impossible) to accidentally send a plaintext message. Meanwhile, plaintext replies to encrypted emails are such a widespread phenomenon that practically everyone who has used them at any kind of scale has witnessed them. The reason those opsec lapses aren't newsworthy is because the underlying messages are unimportant, so nobody cares. Which is why it's important that people understand that almost all encrypted mails are LARPsec.

Failure in opsec does not prove that telling people to encrypt create worse security than explicitly telling people to not encrypt.

I do not see any extraordinary evidence that support your claim. It still sounds more like you are advocating for plain text, and since the encryption wars has been on going for the last 40 years it is worrying to see a new front being formed.

There are two requirements: Plain text should be banned from the network and sensitive data at rest in the hands of third parties should always be encrypted. Advancement in email security has gone forward enough that if both sides of a communication are running their own email server than the need for PGP has been made redundant. If however an untrusted third party is used by either side then the second requirement is not unfulfilled and sensitive data is leaked.

People can pretend that they don't have sensitive data and a single look at the company CRM, HR, customer registers and so on will show that it is really hard to operate a company without handling sensitive data which under GDPR has some real legal ramifications. A single email attachment and now a third party has a copy of that, and a data breach later at the service provider and a law suit happens. With that threat model and enough cases ending up in the news the cost of running unencrypted email goes up.

I'm not telling people not to encrypt. People should encrypt. I'm telling them not to encrypt email, because email is unsafe. You're going to have to engage with my actual argument rather than fleeing to abstractions.

I'm not the person you replied to, but there's no fleeing to abstractions here.

The point being made is that you continually fail to account for data at rest (among other things) in your arguments against encrypted email. Something doesn't have to be perfect to be useful. Most people don't need to fear for their lives if a single message leaks, but that doesn't mean they want plaintext copies of everything cached all over the place for who knows how long either.

> The point being made is that you continually fail to account for data at rest (among other things) in your arguments against encrypted email.

Encrypted email with PGP doesn't give you data-at-rest encryption, though. See https://efail.de ... or the fact that forward secrecy was not a design consideration when it was designed in 1990.

> Most people don't need to fear for their lives if a single message leaks, but that doesn't mean they want plaintext copies of everything cached all over the place for who knows how long either.

This is the heart of the argument. You need to treat email (encrypted, or not) as if there are copies cached all over the place forever. You should assume that about any email you send (again, encrypted or not). This is why it's called security LARPing ... if your argument is simply "I don't want people reading my stuff, it's private"... well, no one cares about your emails. But the moment they do start caring, they can go back and read all of your emails, encrypted or not.

PGP most certainly _does_ provide data at rest encryption. Efail isn't relevant here - it's a live exploit against an active target, not something that can be used against data at rest for which you lack the keys. And forward secrecy is hardly relevant to the point I made either (other than being a generally desirable feature).

> You need to treat email (encrypted, or not) as if there are copies cached all over the place forever.

That's my _entire point_. Assuming there are copies cached all over the place forever, I would strongly prefer that they were encrypted. How is this not an obviously desirable thing?!

> the moment they do start caring, they can go back and read all of your emails, encrypted or not

I do not believe that this claim is correct. Given a block of PGP encrypted text for which one lacks the private key, I am not aware of the existence of any practical attacks against the algorithm. If such an attack does exist, please point me to it - I would very much like to know about it.

Is Signal supposed to be more secure than point to point TLS?

That doesn’t sound correct to me, and makes me wonder what the complaint about email is.

TLS encryption over a relay network seems like state of the art security, and something I’d trust much more than Signal to hide my metadata — which is how you’ll actually get killed in a “life or death” situation.

Email-over-TLS provides encryption to your mail server, not to end-to-end encryption to the recipient of your email. That's what this entire discussion is about (and "encrypted email" in the article refers to PGP encryption, not TLS.)

> and has a number of independent implementations

Actually it's slightly more than that: it's standardised. Signal for all it's niceties isn't. Even if you did emulate it (and you can because it's open source), it's a moving target so there is no guarantee what works today would work tomorrow. AFAIK, all existing reimplementations are incompatible.

Worse, it's infrastructure is centralised. There aren't 10 different lookup servers you can use interchangeably and cross validate. There is just one, situated in one country, and it happens to be a country whose government intelligence agencies have a long and colourful history of infiltrating and compromising organisations just like Signal.

The other thing major different is the PGP ecosystem does have key validation system, and in my experience it is actually used. People go to key signing parties and take them seriously. Signal also has very good key validation of course, but nobody uses it.

So while it's true to Signal can let kids chat to each other securely, the reality is it that security is very weak because they don't want to go to all that tedious setup the PGP / X509 ecosystems wants them to do. When they start a chat with someone new, they don't get a warning that could be anyone unless they use Signal's inbuilt (and very well designed) validation system. I guess such a warning might get in the way of the "frictionless experience" seems to love about it. As a consequence, when someone changes phones they have no idea of the importance of porting their Signal identity across, and when the other end gets the "Warning: Person XYZ changed their identity" (or whatever the wording is) they just shrug ignore it ("they must have got a new phone"). And with that whatever security Signal does provide collapses like a house of cards.

If the security industry claims Signal provides the same security as GPG/PGP while being easier to use, all that tells you is how little the people claiming to represent the security industry know about security. (This isn't to say if you use it correctly Signal won't provide a similar level of security - it does. But they it becomes as burdensome to use as PGP.)

These are arguments about things other than safety. In discussions about whether things are "standardized" or "federated" or how their "ecosystems" look, the safety of actual people is an externality. That's especially so because the overwhelming majority of technologists with strong opinions about secure messaging never send a message that needs real cryptographic protection against a motivated adversary; the entire concept of safety is an externality to those people. But the real, life-or-death cases are not rare. It is malpractice to suggest that people entrust their lives (or their life's savings) to shoddy encryption so that other technologists can have a federated ecosystem of standards.

If this were and engineering discussion about tie rods holding elevated walkways in a downtown hotel, we'd have no trouble setting aside all the other arguments and recognize the core, overwhelming priority. But because our discipline is not an engineering discipline, despite pretending otherwise, we're forced to humor these frankly unethical debates.

>There is just one, situated in one country, and it happens to be a country whose government intelligence agencies have a long and colourful history of infiltrating and compromising organisations just like Signal.

Whereas that same agency is under fewer restrictions for targets hosted in other countries.

>the reality is it that security is very weak because they don't want to go to all that tedious setup the PGP / X509 ecosystems wants them to do.

Being tedious doesn't automatically improve security. See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html and https://blog.cryptographyengineering.com/2014/08/13/whats-ma... and https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...: see the section on why broken stuff there won't be fixed.

This, to steal a term from Paul Graham, is a lowbrow dismissal. You could make it without having read the article; in fact, there's no evidence in this comment that you have read the article at all. And the rebuttals to this comment are all in the article, which does not talk about "stickers" or require people to run Signal.

> Stop using that thing that mostly works as intended and is integrated into lots of email clients and systems, and has a number of independent implementations, and has the decentralized properties that match email.

I want to be sure I don’t misrepresent your point. By the thing that works as intended and has plenty of implementations, you’re referring to GPG/OpenPGP?

You seem to think poorly of Signal, but you don't give any reasons. What are they?

Reply on news.ycombinator.com