The CCC definition of this being only 2FA-SMS is incorrect though. It was not only Twilio Verify (2FA API) that was affected, it was all SMS sent through this vendor.
It is not but CCC is indicating that this provider was only used for 2FA. Sorry I was getting a bit ahead of myself here, this was earlier exposed as a breach of Twilio's vendor (IdentifyMobile). In the case of Twilio they offer an API for 2FA, Twilio Verify. I wanted to clarify that this breach was not only for 2FA, Verify API in the case of Twilio, but for all SMS sent through IdentifyMobile.
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.
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.
* The exposed data included mobile number, message content, SMS timestamp.
* Only France, Italy, Burkina Faso, Ivory Coast, and Gambia were impacted.
Twilio support also provided a CSV file listing the message SIDs for my account that were exposed. Unfortunately they say they cannot associate the message SIDs with recipient numbers. And I cannot either, as I have configured short log retention period (out of privacy concerns, ironically) :-/
Yes I received more info as well. Apparently they think that GDPR does not apply to them in this case. Good luck with that.
"To answer your questions:
1. Only France, Italy, Burkina Faso, Ivory Coast, and Gambia were impacted by this incident, only the traffic sent to these countries.
2. To provide you more context, Twilio’s carrier partners are not considered to be Twilio's processors (or Twilio's customers' subprocessors) under the GDPR because carriers transmitting communications content (i.e., Customer Content) are not considered to be processing the personal data contained in the communication. There are a number of reasons behind this positioning:
• “Disclosure by transmission” is called out in the GDPR definition for 'processing' rather than transmission without disclosure.
• A processor role does not fit the nature of telecoms services and the telecoms value chain; Confidentially (and security) of communications is safeguarded by the ePrivacy framework.
• Guidance from the EDPB specifically covers “telecom operators” and does not specify a role for the carrier with respect to the content of the communication.
• Communications content merely transits a communications network or service, without significant processing being involved as confidentiality of communications prohibits the carrier from gaining access.
• Any other position would be impossible to implement given the complexity of the telecommunications value chain, with many parties involved in the origination, transit, and termination of communications content."
The email is unfortunately lacking in some details. Does this include all messages sent through Twilio or just in the country of this provider?
And why is this carrier storing messages on an S3 bucket? I don't see why they should store messages at all after the message has been processed, storing metadata should be sufficient for their records. It would be definitively be problematic according to GDPR, if IdentifyMobile is a Briths company then similar privacy laws should be in place?
I had the same thought. Apple has a lot of "stickiness" for their customers - whether you think this is due to superior technology or just marketing is debatable. Meanwhile, raw computing power is fundamentally fungible and there's a lot of incentive to undercut NVDA's offerings. The only question is how long it will take to do so.
> superior technology or just marketing is debatable
“Superior customer experience” is missing from this. I don’t care if the processor in the iPhone is the fastest or not, or if it has 8Gb of RAM vs some Samsung and I care even less about marketing.
Apple is only sticky to those who buy into the ecosystem. Those whose a single Apple device (or 2) without paying for any Apple service are not trapped in the walled garden
Yes, but we are in 2024. Our expectations of products have changed, and especially after their fresh look on their email product, I hoped they had a new take on corporate chat as well.
If you take some of the public slack channels, campfire fits the better.
Look at Elixir's slack for example. Since it's a free tier, you can't view older messages that can be beneficial to someone. And Elixir's slack channel is not going to need fancy workflows, web hooks for CI, gitops capabilities et all.
Your expectations might have changed. Most users are quite happy with core chatting features. And in the case of Slack those features have become a bit too intrusive and disorganised, so that is one of the selling points of Campfire.
> Custom elements aren’t “semantic” because search engines don’t know what they mean.
Lots of good points in this article but I don't think this is an issue. IMHO custom elements shouldn't be used to define content, we have standard elements for that, it should be used for rich interactive components. For example a datepicker. If there is content in the element then I do not see how search engines would interpret it any different than a normal div, or even better the custom elements should define content appropriately such as <my-component><article>text</>
The CCC definition of this being only 2FA-SMS is incorrect though. It was not only Twilio Verify (2FA API) that was affected, it was all SMS sent through this vendor.