HN Debrief

Rootshell: A new E2EE email service hosted in Iceland

  • Security
  • Privacy
  • Infrastructure
  • Startups

Rootshell is a newly launched email service hosted in Iceland that presents itself as end-to-end encrypted. That claim was the first thing people attacked. One commenter says a quick test showed messages coming back from the server in plaintext, which would mean decryption happens server-side rather than on the client. Several others made the broader point that ordinary email only becomes true end-to-end encryption when both sides use something like PGP or GPG. Otherwise the provider still sees plaintext for mail arriving from Gmail or any other normal service. The result is that “E2EE email” reads less like a technical property and more like a marketing shortcut unless the service clearly limits the claim to encrypted messages between compatible users.

Treat any new “secure email” product as guilty until it explains its threat model, client-side crypto path, and operational basics. If you are building one, the hard part is not the landing page claim but the protocol edges, account policy, and day-one trust posture.

Discussion mood

Mostly negative and skeptical. People did not buy the E2EE claim, found the product buggy during sign-up, and saw enough mail-security and trust issues to treat it as premature at best and misleading at worst.

Key insights

  1. 01

    Security audits are only as good as scope

    For a mail service making strong encryption claims, a branded audit report is close to useless unless it spells out exactly what was tested and by whom. The sharper point is that meaningful review of an E2EE mail design is expensive because it has to examine the full client and server boundary where these products usually cheat.

    If you evaluate a security vendor, ask for scope, methodology, and named reviewers before you care about the firm logo. If you are launching one, do not hint at audits unless you can publish enough detail for technical buyers to judge what was actually covered.

      Attribution:
    • tptacek #1 #2
  2. 02

    Mail ops mistakes can sink trust fast

    The most useful technical feedback was not about grand crypto theory but about day-one mail hygiene. Passing an image tracking privacy test was nice, but broken DANE, weak MX TLS ciphers, inconsistent HSTS preload configuration, and letting users register addresses like abuse@ make the service look operationally unsafe long before anyone audits the encryption model.

    For any new email product, baseline DNS, TLS, and reserved-address policy are part of the security story, not cleanup work for later. Buyers should check these basics before trusting the harder-to-verify claims.

      Attribution:
    • mike-cardwell #1 #2 #3
  3. 03

    Open source would help but not solve trust

    Publishing the code would let outsiders inspect the client-side encryption path and catch obvious design flaws earlier. It still would not replace real review, because security claims depend on deployment, key handling, and whether the running service matches the code you published.

    If you are early and unknown, open sourcing the client and protocol docs is the fastest way to earn technical scrutiny. Users should still distinguish “source available to inspect” from “service verified to operate securely.”}],

      Attribution:
    • dpoloncsak #1

Against the grain

  1. 01

    Independent mail providers are still worth wanting

    Even with all the skepticism, there was one clear note of support for the underlying goal. More standalone mail providers reduce dependence on giant corporate platforms, and privacy-focused hosting jurisdictions are attractive if the service can actually execute.

    Do not let this launch sour you on the category. The demand for credible alternatives to big-email incumbents is real, which leaves room for teams that can pair privacy claims with serious ops.

      Attribution:
    • Bender #1
  2. 02

    Iceland criticism was mostly guilt by association

    The broad attack on Icelandic hosting rested on bad experiences with abuse handling, but that does not say much about this service specifically. The pushback was that every large hosting ecosystem, including AWS, contains bad actors, so jurisdiction alone is a weak proxy for service quality.

    Use operator responsiveness and abuse processes as the signal, not country branding in either direction. A privacy-friendly jurisdiction helps only if the company behind it is competent and reachable.

      Attribution:
    • chadgpt3 #1 #2

In plain english

DANE ↩
DNS-based Authentication of Named Entities, a method that uses DNSSEC to publish and verify cryptographic keys or certificates for services.
E2EE ↩
End-to-end encryption, a security design that prevents the service provider from reading message contents in transit.
GPG ↩
GNU Privacy Guard, a tool for public-key cryptography often used to sign email or software artifacts.
HSTS preload ↩
A browser-maintained list of sites that should always be loaded over HTTPS from the first visit, before the browser has seen the site's HSTS header.
MX ↩
Mail Exchange record, a DNS record that tells senders which mail server handles email for a domain.
PGP ↩
Pretty Good Privacy, a system for encrypting and signing messages and files.
TLS ↩
Transport Layer Security, the standard protocol used to encrypt network connections such as web traffic or mail transport.

Reference links

Mail security testing and validation

  • Email Privacy Tester
    Used to check whether the service leaks tracking and remote content behavior common in email clients.
  • HSTS Preload submission checker
    Referenced to show that the domain could not actually be added to the browser preload list because of certificate issues.
  • crt.sh
    Suggested as a way to monitor whether anyone managed to obtain certificates for the domain after concerns about certificate-validation mailboxes.

Alternative privacy-focused email providers

  • Runbox
    Mentioned as a more established Nordic email provider with a long operating history.

Tools mentioned in testing

  • LuLu
    Mentioned as the firewall tool that blocked network access and exposed how the webmail UI behaved when remote content could not load.

Related project with the same name

  • rootshell iOS terminal client
    Linked because some readers initially thought the post referred to this libghostty-based terminal app rather than the email service.