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.
> 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.
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.
Even if you have a lawful basis for collecting data, in theory the GDPR is in theory restricting you to only use it for that basis, delete it as soon as you don't need it anymore, have a plan on how to store and handle it, and requires you to follow best practices when doing so. Backups, encryption, regularly testing the technical and organizational measures that protect the data are in theory all mandated. Also, on the topic of this post, notification of data breaches when they occur
But enforcement is just laughable. Even on easy to observe issues like which data is collected
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.
Which usually means until the financial incentives to remove the data outweigh the incentives to keep the data. Data is more valuable than database storage costs, thus there is no incentive to remove the data. Policies should therefore be in place to punish unnecesary data retention.
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 wild about this benchmark. There are well-known firms (definitely not saying that about Trail! no experience at all with the other one here) that issue public-facing audit docs that read the same no matter what the project scope was.
If you're keying off 3rd party assessment, which is sane, you should be evaluating the combination of the testing team (the best firms will publish reports with the names of the consultants on them) and the scope and depth of the results. The company shouldn't matter; the scope should matter a lot.
A meaningful security assessment for an "E2EE mail service" is nosebleed expensive.
Did not expect this post to get all this attention. I've done a little digging and found the operator on X. Had some DMs and he(?) said that they've had 1 black box and 3 white box audits. I'm not going to speak for anyone, so maybe you can ask them directly.
I don't really care beyond continuing to nudge people away from this idea of "seal of approval audits", which have been an industry curse for decades. I don't think E2EE email is a good idea to begin with.
I guess we need to coin a new term, something like VibeE2EE. As in "we asked to make something E2EE but we have no idea what it has made, nor we asked anyone to audit it (because it wouldn't pass a code review, let alone security audit)"
The E2EE claim is BS, unless qualified by saying that the platform supports GPG-encrypted emails only. Proton makes the same claim and it’s just completely false. E2EE is not possible with existing email protocols.
The main point they try to make is that once emails land, the platform itself can't read them because they immediately encrypt it with your key, of course, this process is impossible to know for sure. And of course, using PGP or whatever is already a secure medium on all email providers, nothing to really solve here.
Even as some says, even if Cure53 or whatever respectable company does an audit, it still guarantees nothing. Only real way today is with Enclave with proper implementation of attestation and more, anything running server-side can't be checked.
It's quite disappointing that we find many good developers today that still trust ToS of a service as if it was any form of real security, it worth nothing outside of the legal aspect, ToS has nothing to do with code.
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.
I am not sure if this is still the best approach. They did not even try to submit based on expected "low" ranking when comparing to existing XSS submission. They should at least try or let them know many days before disclosing. You never know.
It's not just based on that, if you read the linked report from 2023 (https://blog.ammaraskar.com/vscode-rce/), I had a bug with the exact same impact of token exfiltration (It did need one additional click on the VSCode interface). They marked it as low severity, fixed it silently, didn't acknowledge that it had security impact and did not provide me any credit much less a bounty.
I thought that the general issue was that they ignore the submissions and do not fix them - but the actual problem is that they give different severity and may not give fame or money? I think disclosure for those reasons is highly in gray area from ethical perspective. Regardless if it was clearly in the scope of the bug bounty program or not. That is distinct problem and does not justify public disclosure without warning with enough time.
Its not just one issue they mishandled. It is a pattern. I think this makes sense if you believe long-term security requires leadership change at MSRC.
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).
Yeah, it seems another ATO bug has popped up. I haven’t looked too much at it personally, but I hope Meta plans on taking their Meta AI Support Assistant offline until it undergoes far more rigorous security review.
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.
reply