I've had a similar thought in the past. I was thinking about the feasibility of a law being introduced where each company making over a certain amount of money per year must begin a VDP (and optionally a BBP) so that security flaws can be reported to them easily. This can easily be done by simply opening up security@companydomain and using security.txt (https://securitytxt.org). Reports must receive a response in N days, where N is calculated based on available staff, resource allocation, and revenue of the company. If they don't receive a response after N days, this can be escalated to some government agency which can take action against the company for failing to respond to a report on time.
Companies can and do get away with arguing that they have a "lawful basis" to collect whatever data they'd like. It's unfortunate.
IANAL, but the law seems a bit vague to me, and it appears that companies use that vagueness to their advantage. Maybe I'm just not articulating my arguments correctly.
> Otherwise, just assume everything you do online is public and act accordingly.
This is such a depressing reality. It's also what governments want you to believe. If you aren't able to speak your mind about anything anonymously, then you won't be able to, say, spread ideas that go against them.
Admitting defeat at all and not even trying to teach people about privacy results in the "I don't care, what's the point?" attitude that plagues many people today.
I use Snusbase (https://snusbase.com). They've been around since around 2016 and haven't had any issues legally - they're the longest-standing data breach search engine besides HIBP, as far as I know.
Hashes can be cracked, and end users won't understand how to create password hashes to check which one was leaked. Plus, salts exist.
Passwords shouldn't matter anyways. Use a password manager and be done with it. The real issue is metadata which can't easily be changed - phone numbers, addresses, and the like. If any of that data is leaked, it becomes much harder to contain impact. You can't move addresses every time your address gets leaked online.
I wish that were the case, but because of there being barely any consequences for breaches, it's much more profitable to store everything you can and sell it to the highest bidder. Make it a huge risk to store data, then companies will start treating data like a live hand grenade.
I'd also add a third issue to this list: data retention. Too many companies I've dealt with have privacy policies that state something to the tune of "we'll hold onto your data for as long as required" without giving much of an explanation as to how long "as required" is.
I find it very hard to trust any email service that claims to be E2EE without an audit by a reputable firm like Cure53 or Trail of Bits.
I signed up to give it a brief test and immediately noticed that emails are returned from the server in plain text. This means that the emails are decrypted on the server, which defeats the entire purpose of E2EE. The encrypted email contents and metadata should be returned to the user and decrypted on the client.
It's also painfully obvious that the entire thing is vibe-coded. While that in itself isn't an issue, it raises scrutiny. If the author doesn't have a full understanding of the code their LLM generates, some nasty bugs could be lurking.
I'm not sure how I haven't heard of this yet. There have been too many times I've wished I could convert a command-line script to a native application easily for me not to try this.
Kudos for the public disclosure. Too many people haven't been happy with MSRC and it's starting to boil over (see the Nightmare Eclipse situation, too). Maybe all of these disclosures will cause them to do some introspection and realize they're the problem. I highly doubt that, but one can dream.
It seems pretty trivial to just add a check in the agent's tool call to determine if the email is actually the one on file (or one that has previously been on file). I'm not sure why it's taking them so long to remediate.
The bug still exists - two of my friends have lost access to their accounts as of an hour ago. They've partially recovered but are unable to change their passwords, so their accounts are still technically in the hands of the attacker(s).
The original 2FA did not get thoroughly bypassed, because otherwise I would've lost my username, so that's false - at least, based on my experience.
However, there are separate vulnerabilities that allow for 2FA to be bypassed on Instagram. I assume they were chained to take over specific high-value accounts. The 2FA removal happens as a service - most people charge around $1,000+ - so it wasn't viable for most lower-value accounts. Anything that was worth over $1k probably had the bypass applied to it.
I suggest you try signing into your Instagram account via the app or website to check if you've been compromised. It could very well be a bot trying to obtain your recovery method hints but you could've also fallen victim to this exploit, especially if you have a short or valuable username.
If there's no recovery email address set, or that email has expired, there are no recovery methods to verify with. The account is locked "for good". I use quotes because in some cases I've been able to recover Gmail accounts with similar characteristics by simply trying often on my home IP address using Google Chrome.
It's against Meta's terms to buy and sell accounts, thus the bank would never do such a deal unless you structured it a certain way: create a business, the account becomes property of the business, then Chase buys the business and thus the account. This is how certain Twitter accounts were sold a long time ago. $10k for @chasebank (which is what I assume your handle is) is quite good regardless, though.
Meta's aware and tries their best to act on it, but the real solution is simply not hiring outsourced support workers. It's really that simple. They have the money to hire people in-house for good wages, which would solve the root issue: the outsourced workers are desperate for money and gladly will take bribes.