While that’s true, but there’s no indication of Microsoft brute forcing with million of combinations.
The article you link says Microsoft is only trying a few obvious passwords: the filename, and words found in the plaintext message.
Proper encryption isn’t just about using a strong algorithm. It’s also about proper key management, ie not sending the password in the clear via the same channel as the encrypted files.
ZIP isn’t a good way to encrypt, but what Microsoft is doing is simply reading the email, and decrypting zips with the password found in the email body.
All encryptions schemes can be trivially broken if you have the key. It’s not even breaking, it’s just normal decryption.
Scientists don’t have to explain why they’re leaving twitter. The reasons should be obvious to anyone familiar with Twitter.
Journalists need to explain why they’re still on Twitter, given that platform has so much bots, trolls, hate and lack moderation.
Quite the contrary.
Password hashing is standard nowadays.
When a database is compromised, brute forcing hashes is necessary to recover passwords, and the short ones are the first ones to be recovered.
Taler is closer to an EMV card alternative, rather than a cash alternative.
Hopefully cash remains. But regions and businesses are already starting to go cashless, so I’d rather have Tale as an option.
Would Taler be more resilient than a typical EMV/AmEx card? It’s designed as an online payment system but it’s less centralised, so that could help.
It’s already an attractive project due to its privacy feature, and due to it being more regulation-friendly that cryptocurrencies. If it’s resilient enough it could act as a digital cash.
Science Based Medecine is a fine source, and has a very high rating, but more sources are welcome.
The Author is Steven Novella, an actual human, a medical doctor, and associate professor at Yale. He’s not a chatbot.
Thanks for the explanation. I’m considering Matrix but will hold off, at least until v1.11 or v1.12 solves the unintended CDN issue described in another comment here, cf https://matrix.org/blog/2024/06/20/matrix-v1.11-release/#continue-reading
I’m interested into the technical details, not actual URLs. How come servers cited in the video keep hosting/seeding chatrooms despite closing corresponding accounts? Is this impossible due to Matrix’s design, or is it poor moderation from server admins?
About URLs: the author is absolutely right to blur these. The only people he should be sharing this is police, or maybe admins if they’re not aware of the abuse on their server.
That’s the first time I hear of Matrix having this issue.
I’m curious to know more, but the video only cite an anonymous source. Are there evidence or more technical details available regarding this?
Scams, identity thefts, manipulation through targeted ads (eg Cambridge Analytica), malware delivered via ads
Don’t waste time trying to reason them. If you’re not able and willing and sue them to enforce the GPL license, the company won’t care.
You should directly informe one of the organisations mentioned previously, they may have a lawyer and experience fighting this kind of fight.
Best you can do youself is collect evidence that they’re distributing modified GPL software, and write a precise description of the issue, to help these organisations kickstart their investigation into the GPL violation.
Okay, I misinterpreted your comment.
Having a backup at a cloud provider is fine, as long as there is at least one other backup that isn’t with this provider.
Cloud provider seems to do a good job protecting against hardware failure, but can do poorly with arbitrary account bans, and sometimes have mishaps due to configuration problems.
Whereas a DIY backup solution is often more subject to hardware problems (disk failure, fire, flooding, theft, …), but there’s no risk of account problem.
A mix is fine to protect against different kind of issues.
That would indeed be a good backup strategy, but better be specific. “Offsite” may be interpreted in different ways.
They had backups at multiple locations, and lost data at multiple (Google Cloud) locations because of the account deletion.
They restored from backups stored at another provider. It may have been more devastating if they relied exclusively on google for backups. So having an “offsite backup” isn’t enough in some cases, that offsite location need to be at a different provider.
Wrong choices happen when there’s deletion of useful historical data, motivated by short-term cost saving.
Wrong choices also happen when there’s unnecessary creation on data, such as logging and storing everything, just in case, with a verbose level.
Storage can be cheap in some cases, but high-availablility high-performance cloud storage is very expensive. Anyway, it’s not infinite.
The way to keep useful data is to be strategic and only store relevant logs. Fine tune retention policy especially for fastest growing data. Storing everything on high-cost storage, without smart retention policy, could lead to deleting git data to make place for a mix of debug logs and random shit.
Different groups and people are calling SpaceX a dominant launch provider and even a temporary monopoly.
Space is different from other sector. That’s doesn’t make it immune from the risk of monopoly.
I hope they succeed. Access to space shouldn’t depend on a single company, especially one owned by Musk.
Link to other sources are welcome.
I searched for sources and picked this article as it’s both relatively exhaustive, and one of the firsts ones published on this topic.