Credential stuffing is an attack which is well known and that organizations like 23andme definitely should have in their threat model. There are mitigations, such as preventing compromised credentials to be used at registration, protecting from bots (as imperfect as it is), enforcing MFA etc.
This is their breach indeed.
I don't think it's you, it generally is a bad practice to have multiple processes inside a container. It usually defeats most of the isolation, introduces problems with handling zombie processes (therefore you need an init) and restarting tools when they crash (then you need something like supervisord, which I guess this image might use - I didn't check). Each software adds dependencies, which can conflict (again defeating the idea of containers), and of course CVEs. Then you have a problem with users etc.
So yeah, containers are generally not meant to be used this way. The project might be cool but I would be very uncomfortable running it like this, especially if that's going to be my primary email, with all the password resetting capabilities etc.
Credo anche che il massimo numero di caratteri sia configurabile per istanza, no? Su infosec.exchange credo sia 10000 per esempio. Questo, a mio avviso, è molto meglio dei thread (che sono un workaround).
Dude, we already know education is expensive in US, you don't need to actively show it to the world. We get it.
This misses the point in my opinion. The point of a protocol is to establish a set of rules that need to be followed, that's it. After this, it can be managed in many ways, it can be open or it can be closed, etc. The fact that ActivityPub is "engineered from the ground up to support multiple apps with different functionality" it's because ActivityPub is an open protocol. Every protocol is designed to support whoever implements it. This doesn't have any inherent "the protocol (changes) will suit everyone" or "everyone will be able to keep up with it" property, though. If changes to a protocol happen very fast, apps that are compatible today - and can be compatible tomorrow too - still need to implemented those changes, or at some point they will not be compliant anymore. This is not because the protocol loses the property of supporting multiple apps, but because a protocol still needs to be implemented, which is responsibility of the consumers, which requires time.
So my point was to challenge OC perspective that since ActivityPub is designed to support multiple apps, then there is no risk that it gets messed up and breaks compatibility with those apps (because it's generic) due to - in this case -Threads influence. This is just nonsense, in my opinion.
Absolutely. Your email has an image? Maybe spam. Your email does not have an unsubscribe link, even if has nothing to do with transactional emails? Spam. Your email is from an address or domain which did not send many emails before? Spam.
It feels the meme from parks and recreation.
And you can't reliably even know if your message was received or not, the only way to do that is asking directly through some other channel...so the fact that email is open is essentially just an empty quality.
I don't know what is going to happen, and as I said, I don't even care that much to be honest.
Blast radius of what? How does that affect existing Mastodon instances?
It does if this happens gradually, when instances bleed users to Threads because it has "more features"/works better/etc.
I’m optimistic because I think open alternatives are generally better and will win long term.
Good for you, I am not sure what this optimism is grounded on, but I lost it completely. I think the battle is already lost, and open solution can -at best- represent a niche corner of the internet. People are used to things that are addictive and create expectations that are unrealistic for services run with budget at 4 digits top. There is no going back, in my opinion. Either way, this is very much besides the point of my argument, which was that email is exactly an example of how big companies can take over "open" protocols with them being left "open" but effectively having 99% of users on 2/3 providers, and a very high entry barrier which renders the "open" nature of the protocol just a formality.
which is engineered from the ground up to support multiple apps with differnent functionality (hence me writing this in Kbin and others reading it in Lemmy and being able to link it and follow it from Mastodon)
I mean that's basically what every protocol is. ActivityPub abstracts concepts, that apps implement in their own way (for example the concept of group). If you manage to deliver changes, even improvements, to the protocol, apps need to keep up and comply with it. This is what means "drifting towards the corporate actor". I propose changes to the protocol to a rate that only me (the corporate actor) can keep up with. This way only my users will have certain features and eventually some apps will become incompatible with the recent version(s) of the protocol.
Email an open standard? Sure, on the surface it is. Running your own mail server and getting your emails delivered to gmail/outlook users? Good luck.
Who cares what the form is, if the substance is the problem?
Same with web. To this day, nobody besides google has the possibility to compete in the browser space. So much shit was added to the web standards, that you need an incredible amount of resources to produce a modern browser engine (I am talking one that users can use for their daily stuff, not lynx). You have chrome, you have all the chromium clones, you have Firefox which is anyway paid by google, and you have safari. Period.
No really relevant for my point, but I assume that preventing them to be effectively part of the fediverse, can reduce the blast radius of their changes, since they will be (more) isolated.
If they are on the other hand fully part of the fediverse (I.e. nobody defederates them) many people may be incentivised to move to "that instance" because it will realistically have better availability and in the future might have more "features", which is exactly the kind of extensions to the protocol that other won't be able to keep up with.
I personally used to care more in the past, I don't now that much, but I can definitely see the potential danger.
To be honest, not a great argument, considering that the hidden magic that Google and a handful of big players do, specifically in relation to spam, is what made emails substantially an oligopoly. Today if you want to run an email server, you need to jump 20 hoops to hope your email will ever reach the mailbox of someone on Gmail. Emails were supposed to be a distributed protocol too...
The fact that they did not enforce 2fa on everyone (mandatory, not just having the feature enabled) is their responsibility. You are handling super sensitive data, credential stuffing is an attack with a super low level of complexity and high likelihood.
Similarly, they probably did not enforce complexity requirements on passwords (making an educated guess vere), or at least not sufficiently, which is also their fault.
Regarding the last bit, it might noto have helped against this specific breach, but we don't know that. There are companies who offer threat intelligence services and buy data breached specifically to offer this service.
Anyway, in general the point I want to make is simple: if your only defense you have against a known attack like this is a user who chooses a strong and unique password, you don't have sufficient controls.