This is definitely a fair concern, and something that we have thought thoroughly about, but let me clarify some things:
Our architecture makes jurisdiction less relevant than it would be for a traditional email provider. All email content, subjects, attachments, contacts, etc are encrypted client-side, locally, before they reach our servers, and you hold the keys, not us.
If we ever were to receive a legal request, we could only hand over encrypted blobs and routing metadata (sender/recipient addresses, timestamps), the same metadata any email provider in any country would have.
Yes, we did see the thread shortly after it was posted, and we did move the restricted email address validation to the server side. The client-side check is still there in the UX layer, but it is no longer the security boundary. Thank you for bringing it up here.
Hi HN. We have been building a quantum-safe, end-to-end encrypted email service where we, by design, cannot read your mail. Very few encrypted email services have post-quantum cryptography in production that works with any encrypted email provider, not just their own users. Client-side encryption with post-quantum cryptography, zero-access architecture, fully open source under AGPL v3, our servers are located in Germany. We have officially released, and you can create your account at: https://astermail.org/
We built Aster Mail because we wanted end-to-end encrypted email that's actually private. All encryption and decryption happens client-side. We encrypt email content, subjects, contacts, folder structure, search indices, timestamps, and attachment data before anything touches our servers. Minimal routing metadata (sender/recipient addresses) is required for SMTP delivery, but we encrypt everything we can beyond that. On top of standard PGP, we include post-quantum cryptography by default, protecting against store-now-decrypt-later attacks.
Aster's feature set includes things like: free aliases & ghost aliases (auto-generated anonymous addresses), free custom domains, encrypted contacts with device syncing, burn-after-read messages, scheduled send, email snooze, encrypted search, and subscription management.
We ran a closed beta since early Feb and have gone through 150+ revision cycles based on tester feedback, so the product is stable and feature-complete. The entire codebase is public on GitHub and licensed under AGPL v3, and our team is here in the comments to answer questions about how it works.
Longer term, Aster is building a full encrypted communications suite with drive, chat, and authenticator. Aster Mail is currently available on Web, Windows/Mac, Linux, and will be available soon on iOS/Android.
Side note, since it'll come up: "why not just use Proton?" Proton's architecture exposes metadata to the server, which means it can be handed over in response to legal requests, and has been, repeatedly. Aster encrypts email content, subjects, contacts, and most metadata client-side. Between Aster users, we use a Signal-inspired protocol (X3DH + Double Ratchet + ML-KEM-768) that provides forward secrecy, so even if keys are compromised in the future, past messages stay protected. External emails use RSA-4096 PGP. Our architecture is designed so that even under legal compulsion, there's very little useful data to hand over.
We're not anti-Proton. We just think there should be an alternative that actually protects users' privacy and is practical, in an increasingly monitored world.
The "just buy another one" argument only works if the alternatives are even comparable. For a lot of people, macOS is a hard requirement and not a preference, so telling them just to buy a framework that runs Linux ignores that entirely. Right to repair regulation doesn't force Apple to make a worse product it just requires that the parts and repair information are available.
The real frustrating part is that Cloudflare's "definition" of suspicious keeps changing and expanding. VPN users, privacy-first browsers, uncommon IP ranges, they all get flagged. The people most likely to get caught by these systems are exactly the ones who care most about their privacy, and not the bots that they are apparently targeting.
So the stable state here is all humans eventually being locked out? (Bots are getting better every day; I doubt the same is true for all humans, including those with weird browsers or networks unwilling to install some dystopian Cloudflare "Internet passport".)
But hey, at least some bots are also not making it past Cloudflare!
Or else a player too big to be blocked moves into the space with a service that provides some/all of the privacy benefits, but declines to offer the other undesirable aspects of VPN (e.g. location shifting to circumvent local restrictions)
To the contrary, people running botnets or AI scrapers are likely going out of their way to mimic ordinary web traffic from consumer devices. Ultimately, these measures will only affect users who are trying to protect their privacy and security, and will be ineffective at stopping bots.
> The people most likely to get caught by these systems are exactly the ones who care most about their privacy, and not the bots that they are apparently targeting.
In my brief experience with abuse mitigation, connections coming from VPNs or unusual IP ranges were very significantly more likely to be associated with abuse.
It depends on your users. VPNs aren’t common at all, even though you hear about them a lot on Hacker News. For types of social sites where people got banned for abuse (forums) the first step to getting back on the forum was always to sign up for a VPN and try to reconnect. It got so bad that almost every new account connecting via VPN would reveal itself as a spammer, a banned member trying to return, or someone trying to sock puppet alternate accounts for some reason.
The worst offenders are Tor IP addresses. Anyone connecting from Tor was basically guaranteed to have bad intentions.
I heard from someone who dealt with a lot of e-mail abuse that the death threats, extortion, and other serious abuse almost always came from Protonmail or one of the other privacy-first providers that I can’t remember right now. He half-jokingly said they could likely block Protonmail entirely without impacting any real users.
It’s tough for people who want these things for privacy, but the sad reality is that these same privacy protections are favored by people who are trying to abuse services.
> In my brief experience with abuse mitigation, connections coming from VPNs or unusual IP ranges were very significantly more likely to be associated with abuse.
Correlating these factors with abuse implies that you already have methods of identifying abuse per se, independently of these factors. Is there no feasible way of just blocking the abuse itself when it begins, or developing much more proximate indicators to act on?
> The worst offenders are Tor IP addresses. Anyone connecting from Tor was basically guaranteed to have bad intentions.
Do you handle this by blocking known Tor exit node IPs entirely, or just adding hurdles to attempts to post from those IPs?
> It’s tough for people who want these things for privacy, but the sad reality is that these same privacy protections are favored by people who are trying to abuse services.
But naturally P(A|B) and P(B|A) are two different things.
How does the Tor network counter abuse? Like, say you're hosting a service on the Tor network, what does the Tor network offer if anything to defend against e.g. DDoS attacks?
Sure, but if the service keeps getting overwhelmed (financially or traffic-wise) or compromised (not even necessarily in the security sense but in the semantic purpose sense, like via spam floods on a message board) due to a lessened capability to combat abuse, then the user is worse off all over again, no?
All it would solve then is laundering Tor traffic from being probably malicious to being reputationally ambiguous. Though for a within-network service, that's probably assumed anyways - hard to run a Tor service if you assume all Tor users are malicious, that would be nonsensical.
Which VPNs are people using that actually care about the user's privacy? Most of them don't, sell their home IP to buyers, sell their DNS history to others, etc. Worse, some of them could require invasive MITM cert stuff most users will just click yes through.
I have yet to see a use case for VPNs for the casual internet audience, and for a tech savvy user, their better off renting through some datacenter or something, which at that point is hardly a VPN and more home IP obfuscation. All the same downsides, and at least you get real privacy.
I'm forced to use a VPN to occasionally check my US bank account, since a foreign IP address is obviously a harbinger of unspeakable evil (while the friendly Youtube advertised neighborhood VPN is obviously evidence of pure intentions).
ProtonVPN with bitcoin which you get from a monero swap is a good idea for complete privacy if you want port forwarding.
MullvadVPN is also another great one.
I have heard some good things about AirVPN, but I can absolutely attest for mullvad and to a degree ProtonVPN (Just with Proton, depending upon your threat model, do make the necessary precautions like buying with monero for example)
There are others, but mostly its the 2-3 that I trust.
How do you square "complete privacy" with the fact that you're authenticating to these VPNs with a persistent username or other credential and are then sending traffic through them, both from an IP address that might identify you, and to services that you authenticate against?
Best case, the VPN learns your residential IP and the names of every HTTPS host you connect to (if not your entire DNS traffic as well); worst case, they collude with any of the services you use (or some ad tracker they embed) and persistently deanonymize your account.
> How do you square "complete privacy" with the fact that you're authenticating to these VPNs with a persistent username or other credential and are then sending traffic through them, both from an IP address that might identify you, and to services that you authenticate against?
IIRC, Mullvad allows anonymous accounts, allows payment in cash and via other methods that don't link PII to the transaction, and claims not to log inbound connections.
>Most of them don't, sell their home IP to buyers, sell their DNS history to others, etc. Worse, some of them could require invasive MITM cert stuff most users will just click yes through.
Source? I haven't seen any evidence that the major paid VPN providers engage in any of those things. At best it's vague implications something shady is happening because one of the key people was previously at [shady organization].
This is definitely the right question. A list of failures without any baseline won't tell you anything. You would need the same exercise for human-written code at a comparable scale before drawing any conclusions at all. Without it, it's just confirmation bias.
The actual scariest part isn't that the AI got it wrong... it's that nobody felt the need to verify the AI. A tip from an anonymous caller can get investigated and found out if its true or not, and a match from a facial recognition system apparently does not. People haven't built better investigative tools they've just built better ways to skip around the investigation.
Post-quantum crypto is a good example of this. Lattice-based schemes were theorized in the 90s, but they took decades to actually reach production. The math existed, the hardware existed, and the ideas for making it work were just not there yet.
MoE feels a lot more like engineering to me. You're routing around the problem rather than actually solving it. The real math gains are things like quantization schemes that change how information is actually represented. Whether that distinction matters long term probably will depend on whether we hit a capability wall first or an efficiency ceiling first.
The asymmetry is what makes this very interesting. The cost to inject poison is basically zero for the site owner, but the cost to detect and filter it at scale is significant for the scraper. That math gets a lot worse for them as more sites adopt it. It doesn't solve the problem, but it changes the economics.
Our architecture makes jurisdiction less relevant than it would be for a traditional email provider. All email content, subjects, attachments, contacts, etc are encrypted client-side, locally, before they reach our servers, and you hold the keys, not us.
If we ever were to receive a legal request, we could only hand over encrypted blobs and routing metadata (sender/recipient addresses, timestamps), the same metadata any email provider in any country would have.
We maintain a warrant canary at https://astermail.org/notices/canary.txt, and we have a full transparency report at https://astermail.org/transparency. We have never received a secret government subpoena, national security letter, or a gag order to date.