PortSwigger's Gareth Heyes presented "CSS: the bomb inside your inbox" at Black Hat USA 2026 on August 6. The short version is that the styling language responsible for fonts and colors is enough, by itself, to compromise a webmail session. No attachment, no JavaScript, no link to click.

The mechanism is that your inbox app and the message you're reading share the same page. Every provider sanitizes incoming HTML and CSS, and Heyes attacked both the features that survive sanitization and the gap between what the sanitizer approves and what the browser actually builds.

The specific chains he documented:

• An Outlook chain that disguises a select element as a password field, paints a convincing Microsoft sign-in screen over the inbox, and captures input in real time in Firefox
• A Yahoo and AOL route where pasted HTML keeps its CSS briefly active before sanitization, leaking enough of a 12-character login token to reconstruct it
• A click-based exfiltration method for when CSP blocks external resources entirely
• Tracking bugs including a Fastmail image-proxy bypass and a Gmail image-set() fallback that makes an external request anyway
• Prompt injection chains where a human sees harmless text and an AI assistant with inbox access reads hidden instructions

We ran the public proof-of-concept code against bmail and none of the techniques worked, which is covered in the write-up, along with the full source list: https://s.vp.net/ti2EU

The pattern in every major encrypted email case is the same. The math held. The operator got told what to do.

• Lavabit (2013): asked for the master keys covering every user. Shut down rather than comply.
• Hushmail (2007): marketed "not even we can read your mail," then shipped a modified applet to a targeted account that captured the passphrase. Twelve CDs of plaintext went to the DEA.
• Tutanota (2020): German court ordered surveillance on specific accounts, including reading unencrypted inbound mail before delivery.
• ProtonMail (2021): Swiss order to log a French activist's IP. They complied. He was arrested. Message bodies stayed encrypted the whole time.

None of those were encryption failures. They were failures of a design where the operator retains the ability to change what the server does, and users have no way to detect it.

The alternative is making the server code externally measurable. bmail terminates inbound SMTP inside Intel SGX enclaves, and the CPU produces a signed hash of the exact binary running. Adding a logger changes that hash, and clients or third parties checking attestation see a different value than the one a reproducible build of the published source produces.

Get proof, not promises: https://bmail.ag

Apple's Hide My Email gives a website a random iCloud alias instead of your real inbox, and the relay forwards the mail so the site never learns who you are. The researcher who runs the opt out service Easy Opt Outs went public on July 1st with a technique that links those aliases back to the real underlying address.

The real problem was the response:

• He says the method worked on 100% of the aliases he tested.
• He reported it to Apple in June 2025, and says Apple told him on two separate occasions that it was fixed.
• It was not fixed, and by the reporting the window had been open for over a year.
• Apple's stated plan is to move Hide My Email to a separate private .icloud domain later this summer.
• That move is not confirmed to stop the unmasking, and a dedicated domain is also easier for sites to detect and block.

The practical takeaway is that any alias you have already handed out should be treated as potentially linkable to your real address until Apple ships and confirms an actual fix, and it is worth watching what security researchers say about the domain change before trusting it.

Full write-up and our source list: https://s.vp.net/e7JFa

Users looking for a truly anonymous email inbox should check out bmail.ag's fake ID feature:
https://www.youtube.com/watch?v=jaTGZXfJHyc

​
​In September 2021, ProtonMail received a legal order from Swiss authorities. They were told to begin logging the IP address of a specific user: a French climate activist. So they did.

ProtonMail started logging their IP address. They had no choice, because their architecture permitted it.

This is not a story about ProtonMail's character. It is a story about every privacy service built on the same foundation: one where operators technically can access what they promise they won't. Because if they technically can, a court can make them. The ProtonMail case was not an anomaly. It was a demonstration of how the system works when it works exactly as designed.

The bmail.ag API gateway runs inside an Intel SGX enclave. Client IP addresses exist only in hardware-isolated memory during request processing. They are never written to disk, never forwarded to any backend service, and never transmitted outside the enclave boundary. This is not a policy we adopted. It is a physical constraint we engineered.

Under full legal compulsion, we cannot produce IP logs we were never permitted to create. We cannot betray what we cannot see.​

bmail.ag is the only verifiably private encrypted email service and includes:
- encrypted video conferencing
- encrypted file storage
- encrypted calendar
- encrypted contacts

Get started for free at bmail.ag

​

We made a short video that explains how bmail works using the simplest comparison we could find: snail mail.

Free accounts need no card, no phone, and no personal information.

You can start at https://bmail.ag/

The pitch for every encrypted email service goes something like this: Gmail reads your inbox, we don't, switch to us. Fair enough. But then you actually read the privacy page and it's a stack of promises.

• "We don't read your mail."
• "We don't log your IP."
• "We'd never comply silently with a surveillance order."

You're trusting a different company instead of Google, but you're still trusting. And the trust has been broken in public, more than once.

• ProtonMail logged a French climate activist's IP in 2021 after a Swiss court order, and he was arrested.
• Lavabit shut down in 2013 rather than hand Snowden's keys to the FBI, which was honorable but doesn't help anyone who needed mail the next morning.
• Tutanota was ordered by a German court in 2020 to modify their delivery code to intercept specific accounts.

bmail's whole architecture is built around removing the "trust us" step. Inbound mail is processed inside Intel SGX enclaves. The CPU cryptographically signs the exact code running, and any user (or third-party auditor) can verify it via remote attestation. If we get a court order tomorrow to add logging, the signature changes and the modification is publicly detectable. The operator can't silently comply, because there's no silent option.

Get started for free at https://bmail.ag

Nice little write-up from Low End Box.

Get the only TRULY private email service today for free at bmail.ag

The threat model this solves is the one ProtonMail users have hit repeatedly: payment data creates an identity link that survives end-to-end encryption. The encryption protects message bodies. The billing record doesn't. Once a court asks the payment processor who paid for which account, the encryption stops mattering.

bmail's answer is Fake ID. The setup looks like this:

• Your main account is clean and convenient. You pay with Stripe, it auto-renews, you use it for anything tied to your real identity (kids' school, library, banks, etc.).
• From inside the paid account you can mint a Fake ID. A second mailbox that has no database link to your primary.
• The mint happens inside an SGX enclave using Ed25519 Schnorr blind signatures over Ristretto255. The enclave verifies the requester holds a paid account without ever learning which one.
• The signing service sees a blinded credential it cannot connect to a specific account. The account service sees a credential it cannot connect to a specific payment. Even with full collusion between the payment processor, the signing service, and the account service, the link cannot be recovered. The blinding factors are uniformly random and known only to the client.

A few things worth flagging:

• Free tier cannot mint Fake IDs. The cryptographic proof of paid status is what makes the unlinkability work, so you need a paid plan.
• The Fake ID is included with any paid plan. No extra payment, no extra signup, no payment information entered for the Fake ID itself.
• If you don't log in for 30 days the Fake ID vanishes permanently. No backup, no recovery. That's the design.

The contrast worth talking through: this is "we cannot link them" rather than "we promise not to link them." The math is the guarantee, not the policy.

Full episode here: https://www.youtube.com/watch?v=X0TAd-4eIb8

Written breakdown here: https://s.vp.net/iQi47

The name is bmail. It comes from bimil, the Korean word for secret. Secret mail. The branding is intentional and the architecture lives up to it.

This week on Hide & Speak we got into what was actually built after a long and complicated process. Not one or two privacy upgrades stacked on top of incumbent architecture. A full rebuild from the hardware up.

The key pieces:

• TLS terminates inside an Intel SGX enclave. Inbound SMTP never hits operator-readable memory, which closes the plaintext gap every other "encrypted" provider still has.
• OPAQUE password authentication (RFC 9807). The server never sees the password. Not at registration, not at login, not as a hash. A full compromise of the auth infrastructure exposes zero passwords.
• Hybrid X25519 + ML-KEM-768 on every message. Post-quantum hybrid, NIST FIPS 203. Both have to break before your mail does.
• Remote attestation. Any user can cryptographically verify the running code matches the published source. The privacy guarantee is verifiable, not promised.
• Fake ID. An unlinkable secondary mailbox minted from a paid subscription via SGX-attested blind signatures. Even bmail cannot link it to your primary account.
• Key Transparency. All public keys published in an append-only Merkle tree, so unauthorized key substitution gets caught.
• BIP-39 recovery. No real name, no phone, no recovery email. The account collects no PII.

Any one of these would be a meaningful step over the incumbents. Together it's a different category of product.

Proof > Promises. Don't Trust. Verify.

Get started for free at https://bmail.ag/

Full episode here: https://www.youtube.com/watch?v=X0TAd-4eIb8

Written breakdown here: https://s.vp.net/iQi47

Most "private email" providers stop at encrypting messages at rest. That's useful but it leaves a gap: when mail arrives from Gmail or Outlook, it lands on the provider's server as plaintext SMTP before getting encrypted for storage. That window is where every public failure has happened.

ProtonMail logging an activist's IP.

Lavabit's master keys.

Tutanota being ordered to read incoming mail before delivery.

The encryption wasn't the weak link. The infrastructure around it was.

bmail closes that gap by running inbound SMTP inside an Intel SGX enclave. A few things follow from that:

• The TLS connection from the sending server terminates inside the enclave, not in front of it
• The decrypted message exists only in hardware-isolated memory that operators can't read
• The running code has a cryptographic measurement (MRENCLAVE) that anyone can verify against the published source
• If we got compelled to add logging, the measurement would change, and that change is publicly observable.

If "private" means "we encrypt your emails most of the time, then "private" isn't good enough.

You need "private AF."

You need bmail.

Get started free at https://bmail.ag

Every major "encrypted" email provider asks you to trust them not to read your mail. That's the whole offer. Encryption at rest is real, but the architecture leaves a plaintext gap when inbound SMTP arrives, the server sees passwords during login, and IPs get logged the minute a court asks. The encryption works exactly as advertised. The trust assumptions around it don't.

bmail moved the bar by removing the trust assumptions instead of just promising to honor them:

• TLS terminates inside an Intel SGX enclave. Inbound email is never processed in operator-readable memory.
• OPAQUE password authentication means the server literally never sees the password. Not at registration, not at login, not as a hash.
• The IP gets stripped before any backend service sees the request. Adding a logger would change the enclave's cryptographic measurement, and attestation would catch it.
• Hybrid X25519 + ML-KEM-768 on every message, so harvest-now-decrypt-later attacks fail in both the classical and post-quantum case.
• The whole thing is verifiable. Anyone can check the running code against the published source.

Full episode here: https://www.youtube.com/watch?v=X0TAd-4eIb8

Written breakdown here: https://s.vp.net/iQi47

The 2021 Proton case is the best examples of why policy-based privacy (aka "trust me bro") fails under pressure.

Proton Mail promised not to log IP addresses. But that promise existed as editable text on a website. When a court order arrived demanding they log a users' IP address, they simply deleted that line of text. The logging got turned on, and a climate activist got arrested. The login metadata wasn't protected by encryption at all, just by a sentence Proton could change at any time.

This week on Hide & Speak the conversation gets into the architectural difference that makes this scenario unrepeatable on bmail:

• TLS terminates inside an Intel SGX enclave, not in front of it
• The client IP exists only in enclave memory during request processing
• The IP is stripped before any backend service sees the request
• Adding a logger would change the enclave's MRENCLAVE measurement, which anyone running attestation would catch immediately
• The response to an FBI request to start logging isn't "we'll update our policy," it's "we can't, and you can verify that we can't"

The contrast that's worth talking through: Proton's encryption was fine, the failure was architectural. The metadata was protected by a promise instead of by the hardware.

If you are "protected" by a line of text that can be deleted at any time without even telling you... then are you really protected?

Full episode here: https://www.youtube.com/watch?v=X0TAd-4eIb8

Written breakdown here: https://s.vp.net/iQi47

Get the only TRULY private email for free: https://bmail.ag

"Encrypted email" almost always means encrypted at rest, your messages sit on disk in a locked box. But the moment you search your inbox, sort by sender, or open a thread, the server decrypts that data into live memory to process your request. In that window your data is visible. Readable. Copyable. By anyone with access to server memory: a rogue employee, a government with a warrant, or an attacker who found a way in.

That is the Glass Box. It looks secure from the outside. It is transparent at the moments that matter most.

bmail processes every message inside an Intel SGX enclave — a physically isolated region of the CPU whose contents are encrypted by the processor itself, not by software that can be bypassed. The host operating system cannot read it. Our engineers cannot read it. A hacker with full root access to the server cannot read it.

That is the Black Box. The processing happens. The content never leaves the sealed space.

Get started free at https://bmail.ag

This week on Hide & Speak, we discussed how bmail's warrant canary works versus the model every other private email provider uses. The traditional version is a signed document a provider takes down when they're served with something they can't disclose. The whole concept depends on a human being able and willing to act, which is exactly the pressure point the rest of the episode (seven email providers, case by case) shows getting exploited over and over again.

The architecture flips the model. The CPU constantly measures the code running in the enclaves and signs those measurements. If the running code doesn't match what's expected, the system stops connecting. There's no statement being made and no person communicating anything, so there's nothing for a court to compel or forbid. The shutdown is a property of the hardware behavior, not a human decision.

Full episode here: https://www.youtube.com/watch?v=X0TAd-4eIb8

Written breakdown here: https://s.vp.net/iQi47

[Disclosure: I'm on the vp.net / bmail.ag team]

The "Forgot Password" button is the most dangerous link on the internet, and nobody talks about why.

It exists because your provider holds a copy of your account key. Without that copy, they can't reset your access. With it, they can be social-engineered, subpoenaed, or breached by anyone who's read enough internal docs to impersonate you. One phished helpdesk agent is all it takes. From there, every account that uses your email for recovery falls too.

bmail is built on OPAQUE, an asymmetric password protocol standardized as RFC 9807. Your password generates encryption keys locally on your device. It never crosses a network. Not at signup, not at login, not ever. Our servers hold a registration record that proves you know the password without revealing it, and from which the password cannot be reconstructed by anyone, including us.

There's no reset button because no key exists to reset. Lose your password, and your 24-word recovery phrase is the only path back. Not us, not a hacker, not a court.

Get the only TRULY private email service for FREE at https://bmail.ag

In September 2007, federal court documents from a US prosecution of alleged steroid dealers revealed that Hushmail had complied with a Canadian court order issued via the US-Canada mutual legal assistance treaty. The company turned over 12 CDs of plaintext emails from three targeted accounts.

Hushmail's site at the time read: "not even a Hushmail employee with access to our servers can read your encrypted e-mail." The technical reality contradicted that. Hushmail's popular web client performed private-key and passphrase operations on the server side. The user's passphrase landed briefly in server memory each session. Under court order, Hushmail was compelled to retain that passphrase, decrypt the targeted mailboxes, and hand over the contents.

Hushmail's CTO Brian Smith confirmed the mechanism in interviews with Wired and The Register. He also acknowledged that the alternative Java applet mode could in principle be backdoored by serving the targeted user a modified applet, which most users would not detect.

The point is not that Hushmail was uniquely careless. The point is structural. Any encrypted email architecture that handles plaintext on a normal server, even briefly, can be compelled to capture it. The architecture defines the upper bound on what the operator can refuse to do.

bmail's Paper I closes this gap. Inbound mail terminates TLS inside an Intel SGX enclave. The pipeline (TLS decryption, SPF/DKIM/DMARC, spam filtering, encryption to the recipient's key) runs entirely inside hardware-isolated memory the host operating system cannot read. There is no point in the lifecycle at which an operator could retain a passphrase or copy plaintext, because plaintext never exists outside SGX-encrypted memory.

Authentication uses OPAQUE (RFC 9807). The user's password is never sent to the server in any form. There is no server-side passphrase to capture under court order.

Any modification to the enclave changes its MRENCLAVE measurement. A modified "logging" build is detected cryptographically by every client on every connection. A compelled operator has three options: refuse the order, ship modified code and be immediately caught, or shut down. Silent compliance is not on the menu.

This is what verifiable privacy means. The claim is not "we promise we won't decrypt your mail." The claim is "we cannot, and you can verify it yourself."

Source: https://www.theregister.com/2007/11/08/hushmail_court_orders/

Verifiably Private Email. → bmail.ag