‘There isn’t really another choice:’ Signal chief explains why the encrypted messenger relies on AWS

Comments

• who@feddit.org ⁨6⁩ ⁨hours⁩ ago

  “The question isn’t ‘why does Signal use AWS?’” Whittaker writes. “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.”

  To me, this reads like sophistry.

  What happened here is a predictable result of Signal’s design. They chose to build a centralized messaging system. This made things significantly easier for them than a distributed design would have been, but it has its drawbacks. Having single point of failure is one of them. (In this case, that single point is Amazon.)

  Trying to direct the public’s focus onto cloud providers instead of acknowledging this fundamental shortcoming in their design is, frankly, disingenuous. Especially coming from someone in Whittaker’s position.

  While we’re at it, let’s also acknowledge that centralized design in messaging networks are problematic not just because of (un)reliability, as seen here. It’s also a single point of attack for any entity seeking to restrict, shut down, or track people’s communications with each other. End-to-end encryption cannot solve those problems.

  source

  • KairuByte@lemmy.dbzer0.com ⁨3⁩ ⁨minutes⁩ ago

    I get your point, but that comes with a whole host of other problems. Take a look at Lemmy for instance, decentralized, yes. But also prone to problems stemming from that same decentralization.

    source
  • artyom@piefed.social ⁨16⁩ ⁨minutes⁩ ago

    It also creates a single point of attack for any entity seeking to restrict, shut down, or track people’s communications.

    That’s what relays are for.

    source
  • possiblylinux127@lemmy.zip ⁨6⁩ ⁨hours⁩ ago

    Signal is user friendly and reliable

    While I don’t agree with some of their choices they do have a point here.

    source
• NGram@piefed.ca ⁨8⁩ ⁨hours⁩ ago

  It is true that there really isn’t another cloud provider that they could choose. All of the other cloud providers (major and minor players) are prone to the same sort of systemic failure. But it isn’t true that they didn’t have another choice.

  The solution to service failure is redundancy. Making the redundancy as different as possible makes it even more resilient. In this case, that would be having redundant servers on other cloud providers which can be used in the event that the main one fails. Even better if they can use all of them simultaneously to share the load and let failover happen more gracefully.

  source

  • NaibofTabr@infosec.pub ⁨8⁩ ⁨hours⁩ ago

    Right, OK, but Signal sustains itself on charity.

    source

    • NGram@piefed.ca ⁨7⁩ ⁨hours⁩ ago

      I don’t think that’s necessarily incompatible with what I suggested. They could just leave the backup servers offline until they’re actually needed which shouldn’t cost them anything (or at least not much; some cloud providers charge for a VM’s storage usage regardless).

      Assuming that Signal’s servers were designed by competent engineers, the engineering cost to make a change like this shouldn’t be that bad. Though judging by Whittaker’s comments, that may be a bad assumption.

      source
  • possiblylinux127@lemmy.zip ⁨6⁩ ⁨hours⁩ ago

    That is very pricey

    source
• scytale@piefed.zip ⁨8⁩ ⁨hours⁩ ago

  Yes, but you can have redundancy though. Obviously it comes with a cost, and I don’t know if Signal can afford it.

  source

  • r8KNzcU8TzCroexsE2xbWC@lemmy.ca ⁨6⁩ ⁨hours⁩ ago

    They can’t afford what they have now

    source

    • TacoButtPlug@sh.itjust.works ⁨5⁩ ⁨hours⁩ ago

      That was… enlightening. I can’t imagine the scaling they had to do from day 1 to now.

      source
• noname_yet2077@lemmy.world ⁨9⁩ ⁨hours⁩ ago

  Signal was down? Didn’t even noticed

  source