4 ms·
You can tell that Whittaker isn't an engineer. WhatsApp grew to much larger scale than Signal: self hosted, not on cloud. Running Erlang and FreeBSD. Telegram
by qcnguy 1y ago
You can tell that Whittaker isn't an engineer.
WhatsApp grew to much larger scale than Signal: self hosted, not on cloud. Running Erlang and FreeBSD.
Telegram grew to much larger scale than Signal: self hosted, not on cloud (dc IPs here: https://docs.pyrogram.org/faq/what-are-the-ip-addresses-of-telegram-data-centers https://docs.pyrogram.org/faq/what-are-the-ip-addresses-of-t...). They set up their datacenters carefully to make it hard for governments to access data via legal mechanisms, something Signal didn't bother with.
Threema, similar concept to Signal: self hosted, not on cloud.
Every other messaging app before these bunch? AIM, ICQ, MSN Messenger, iMessage... self hosted, not on cloud.
The idea there is no choice should be hyperbole but it seems she might really believe that. It says a lot that Signal is run by such a person.
- croes 1y ago>make it hard for governments to access data via legal mechanisms, something Signal didn't bother with. No legal mechanism can access proper encyrpted data, something Telgram has to bother
- qcnguy 1y agoGovernments can order the company to push out a new client that turns off decryption for that user, or give them metadata logs (which encryption doesn't help for). Both legal and cryptographic strategies have to be used together.
- 0xy 1y agoSignal is not a project led by strong engineers in general, I realized as much when they had a class of bug that should not have been possible in a well-architected app (UI and state were disconnected resulting in random private images being sent to random contacts without your knowledge, an unforgivably bad incident that revealed slop code in the UI).
- mmooss 1y agoThere are interesting questions to pose - what are the differences and why not follow those paths. Signal is a different application and organization, which has different requirements and resources - for example, they can't optimize performance by sacrificing security, and they have limited resources. It's hard for me to imagine Signal, with already constrained development resources, devoting people, time, wealth and attention to building a private cloud - they would have two businesses, cloud and private communications app. And to match AWS would be pretty difficult - how about scalability for the days when Signals load shoots up? I wonder how these other organizations do it - some clearly have far greater resources than a non-profit with almost no revenue streams. But you're kidding yourself and everyone else to state an answer. It's amazing how HN commenters love to use leading FOSS projects, like Signal and Mozilla, as targets for their performative takedowns - it causes real harm to the most important projects around. Taken seriously, the parent comment's arguments contain no engineering, and their foundation is a lot of assumptions and arrogance: No engineering is required to understand those arguments. No competent practicing engineer would offer a serious opinion about an organization and technical issue that they haven't directly examined. The assumptions are a long list: The totality of reasons that Signal has, as an organization, to choose AWS. The people who made the decision:likely others at Signal were heavily involved, and the CEO's role is unknown to us - maybe just approval - and possibly it was before Whittaker was there. Signal having unlimited flexibiliy in requirements and resources to optimize for this issue. The arrogance is that we know better than Signal's CEO and team members, who are intimately familiar with the project, the organization, its requirements, its resources. The parent doesn't address most of those essentials. But maybe the parent is performative - that's not illegal, but ugh, pick on the big guys; punch up, not down.
- qcnguy 1y agoWe do know better than Signal's CEO because Whittaker's statements are false. She said: > The question isn’t "why does Signal use AWS?" It’s to look at the infrastructural requirements of any global, real-time, mass comms platform and ask how it is that we got to a place where there’s no realistic alternative to AWS and the other hyperscalers > Which is why nearly everyone that manages a real-time service–from Signal, to X, to Palantir, to Mastodon–rely at least in part on services provisioned by these companies Which is both dishonest and stupid. She's claiming it's impossible to run an app like Signal outside of public cloud despite all her main competitors doing so. That's why she lists a bunch of non-competitors to try and support her argument. So it's ironic you say it's arrogant for us to judge their requirements, because we know their requirements. Signal's design is fully open and the requirements of such platforms are well known. It's rather Whittaker's thread which is the height of arrogance. Her response to criticism of downtime is to be "concerned" at the ignorant users who don't "understand" the "concentration of power" and to "explain" to people why it's impossible to do better even as her competitors all do it. It's practically gaslighting.
- mmooss 1y agoYou're picking apart a few comments made in a moment; that's indicative of nothing (except the person picking them apart). > we know their requirements. Signal's design is fully open and the requirements of such platforms are well known. You're kidding yourself. 'Open' doesn't mean you understand them on a level to draw real engineering conclusions. Smart people would wonder at the questions you raise, and ask people who do know. Maybe someone from Signal is around here - but who would respond to someone that calls them stupid?
- qcnguy 1y agoWhittaker's comments weren't "made in the moment", they were posted in a big thread on Mastodon where she had all the time in the world to write them. But I guess you see that her comments are embarrassing to Signal, otherwise why invent excuses. The Mozilla/Mitchell Baker vibes are strong here. It indicates a lot about Signal that its leadership doesn't understand who their competitors are (she thinks its Palantir?!), nor the basics of running a messaging service, nor even what her imagined competitors really do. X runs its own datacenters, Palantir is running in every cloud. They don't support her argument. And I've worked on two web scale products with billions of users, both of them had 5 9's uptime. HN is full of people who have. This stuff isn't rocket science. The first reply on Mastodon points out that even Tor has better uptime than Signal. She's saying this stuff because of her social background, not technical reality. It's just AWFL activist buzzphrases strung together, the sort of rhetoric that served her well in the past to climb the ladder. She's "concerned" and "surprised" that angry users don't understand the "power" of Amazon which "bodes poorly for our ability to craft reality-based strategies capable of contesting this concentration". She acknowledges "the high stakes use cases of many who rely on Signal" but has no interest in meeting those high stakes by driving the execution of an ordinary HA/multi-cloud/multi-region project, of the type that happens all the time in any bank. That's impossible, literally "there isn't really another choice", and also unnecessary because Signal is a mobile app so it depends on Android and that's the same thing as a depending on a cloud (what?). Her conclusion: "my silver lining hope is that AWS going down can be a learning moment", by which she means a learning moment FOR OTHER PEOPLE. Can you imagine Mark Zuckerberg or Pavel Durov crying about Amazon and demanding that their outage be lesson to their users? It's unthinkable. They'd be in the conference rooms with the engineers figuring out how to ensure it never happens again. They might publish a public post mortem to build confidence. That's because they are engineers. Whittaker isn't so she publishes heart emojis and expresses concern at how little sympathy she's getting. No, this is 100% bad news for Signal. It's got totally feminized leadership that responds to the orgs own mistakes with demands for empathy, not fast paced engineering.