Look at the list of customers, most of them should be able to build their own service.

Instead they bought API access without the leastest of due diligence, putting their customers and their reputation at risk.

Additionally, the merging of different customer’s data by the processor is probably not GDPR-compliant (even if access control was in place).

> most of them should be able to build their own service.

Isn't the hard prt the connectivity bit i.e. negotiating with the various telcos? I once saw a telco use a third party SMS vendor for messaging their own customers for an app - because setting it up internally was too much of a hassle.

No, the hard part is having to secure all these little random services that I've now built. Why would I not just pay for someone whose job it was to worry about this instead?

So you say, that for Google, Amazon, Facebook, Microsoft, which are among those costumers, it is too hard to negotiate with the various teclos?

Not in the US at least for those companies, but the world is a big place and this other comment https://news.ycombinator.com/item?id=40935323 mentioned places like Gambia and Burkina Faso... It just makes sense to outsource local delivery to companies that are better connected locally.

It's not their core business, which is why they let SMS aggregators deal with it and merely switch inbetween those.

Yes, and there are multiple levels of aggregators. For example, in a past life, I built SMS APIs and back-ends, including ones used by smaller telecoms to enable their subscribers to send/receive SMS. (We were pretty small, and only accounted for something like 0.5% if US SMS traffic)

We connected to multiple aggregators. It's been a few years, but the big players in the US (Verizon, AT&T, Sprint, T-Mobile) were split between different aggregators. It was a similar situation in Europe.

A big part of working with a new aggregator was a full review of security and privacy, and that became even more important as we began the process of being acquired by an F100 company.

I'm still trying to figure out why messages were stored in S3 buckets to begin with. That's an architecture choice that makes little sense to me, especially since the limited size of SMS makes them pretty space efficient.

We at MakePlans were affected by this breach as we use Twilio. We are not using Twilio Verify (their 2FA api) but rather handle 2FA SMS ourselves in our app using Twilio as one of our providers. So the CCC definition of this being only 2FA-SMS is incorrect, it was all SMS sent through this Twilio third party gateway that was exposed to a limited set of countries (France, Italy, Burkina Faso, Ivory Coast, and Gambia).

GDPR is not necessary applicable here. An SMS gateway is most likely classified as a telecom carrier, and thus any local telco laws would be applicable and not GDPR. That applies only to the transfer of the SMS though, so for example a customer GUI of sent SMS would be out of that scope.

(And before someone tells us that SMS 2FA is insecure I would like to point out that we use this for verification purposes in our booking system when a customer makes a booking. So for end-customers, not for users. It is a chosen strategy for making verification easy as alternatives are too complex for many consumers. All users however authenticate with email and password, and have the option of adding TOTP 2FA).

I think 2FA via texts is better than no 2FA. But only if you do not make the texts world readable.

Apart from that, to me it seems justifiable to follow a risk based approach. Booking systems up to a certain value/amount, fine. Online Banking and health related services, thank you, no.

It's not really 2FA even. More like a magic link (which is what we use for verification via email). The customer has no password, just verifies using a code via sms/email.

Passwordless, so to speak. Does it help with conversion rates?

It’s for the booking site so most visitors come to make a booking thus conversion rate would be high generally. We never had passwords there so can’t compare conversion rates.

For signups to our app (to get an account with a booking site) we require a password.