HN Debrief

1k Data Breaches Later, the Disclosure Lag Is Worse

  • Security
  • Privacy
  • Regulation
  • Developer Tools

The post comes from Troy Hunt, who runs Have I Been Pwned, after loading its 1,000th breach. His point is simple and ugly: despite years of public pressure, regulation, and endless headlines, the lag between a breach happening and users being told is still getting worse. That delay matters because people cannot rotate credentials, freeze credit, or watch for targeted fraud until long after attackers already have a head start.

If you run a product, treat retained personal data as a balance-sheet liability, not a growth asset. If you buy software, ask vendors how fast they disclose incidents, what they actually store, and how quickly they can tell you exactly whose data was exposed.

Discussion mood

Frustrated and cynical. Most people accepted that breaches are now structurally normal, blamed weak incentives and weak enforcement, and focused on minimizing stored data and personal exposure rather than expecting firms or regulators to fix the problem soon.

Key insights

  1. 01

    Narrowing app access changes breach size

    Moving the trust boundary inward cuts the blast radius of ordinary compromises. If a web app can only call a narrowly scoped API or database view instead of running broad queries against the full user table, you gain auditing, rate limiting, and detection points that disappear when the app effectively has `select *` power over production data.

    Review whether your app tier has broad read access to customer tables. Rework it toward least-privilege APIs, views, firewall restrictions, and mutual TLS before the next feature push makes that harder.

      Attribution:
    • alexfoo #1
    • sandeepkd #1
  2. 02

    Insurance could enforce security faster than regulators

    Mandatory data loss insurance would create a payer that actually cares about audits, negligence, and incident response speed. That shifts pressure from abstract compliance to premiums, post-breach investigations, and concrete requirements like a vulnerability disclosure program, `security@` mailbox, and `security.txt` for reporting flaws.

    If regulation is slow where you operate, borrow the insurer mindset internally anyway. Set up clear disclosure channels, documented response windows, and evidence of controls that a real underwriter would demand.

      Attribution:
    • cdirkx #1
    • parable #1
  3. 03

    Disclosure matters more in founder-led B2B

    For private or founder-controlled B2B companies, breach denial can directly kill revenue even when stock markets shrug. Procurement, GRC teams, CISOs, and risk committees will freeze deals until the company can show what happened, who was affected, and how it was fixed. That makes fast disclosure and a credible remediation story commercially rational, not just ethically nice.

    If you sell into enterprises, treat incident communications as part of sales ops. Have customer-facing breach playbooks ready before you need them, because pipeline damage starts before legal finishes wordsmithing.

      Attribution:
    • apimade #1
  4. 04

    Identity fallout shows up in adjacent systems

    The ugly consequences are often not direct account takeover but abuse of downstream systems you forgot existed. Student aid portals, tax filing, telecom accounts, KYC checks, and bank onboarding can all be opened or poisoned with breached data, even when someone uses strong passwords and frozen credit. That is why many people feel fine until one obscure system becomes the attack path.

    Map the non-obvious accounts tied to customer identity in your domain and tell users how to secure them. Personally, freeze credit and secure government or financial identity portals before you think you need them.

      Attribution:
    • toast0 #1
    • nk91 #1
    • makeitdouble #1
  5. 05

    Small products can avoid collecting PII entirely

    One founder described shipping a subscription app that stores only Apple or Google identifiers for auth and payments, not names, emails, addresses, or card data. The important point is not the exact stack. It is that many products claim they need personal data when they really just need a stable token and a payment state.

    Audit every field you store and ask what feature breaks if you delete it. If the answer is vague marketing utility, cut it.

      Attribution:
    • parable #1
    • ItsBob #1
  6. 06

    Plus addressing is no longer enough

    Using `name+service@example.com` still helps with lightweight filtering, but it is weak against modern data brokers, phishers, and sites that normalize or reject addresses. Several people pointed to real aliasing systems like SimpleLogin, Addy.io, DuckDuckGo Email Protection, and Sign in with Apple email relay as the more durable pattern because they generate distinct addresses that are not trivially stripped back to the base inbox.

    If email identity matters to your threat model, move from plus aliases to real per-service aliases. Product teams should also stop rejecting valid email formats and stop assuming addresses never change.

      Attribution:
    • Cider9986 #1
    • alexfoo #1
    • trumpdong #1
    • thewebguyd #1

Against the grain

  1. 01

    Most people mostly experience inconvenience

    For a large share of users, breach harm stays abstract. They get notifications, rotate a password, maybe see more spam, and never suffer a concrete loss they can point to. That helps explain why public pressure stays weak and why data breach politics never feels as urgent as security people expect.

    Do not assume customers will reward security investments just because a breach is bad in principle. If you want budget or market traction, tie security work to visible customer pain, procurement requirements, or direct financial risk.

      Attribution:
    • cfiggers #1
    • BoxFour #1
    • crefiz #1
  2. 02

    Centralized proxy identity would become the biggest target

    A system that promises private day-to-day identities but lets authorities reverse them through one master mapping sounds neat and creates the exact database attackers would want most. It also does not solve law enforcement's real problem, because serious criminals will just use someone else's identity and send investigators toward the wrong person.

    Be wary of privacy proposals that depend on one universal identity vault. Prefer designs that reduce data sharing at the edges instead of concentrating it in a single irresistible store.

      Attribution:
    • AnthonyMouse #1
  3. 03

    Showing leaked records can create fresh risk

    Some wanted breach services to reveal the exact values that leaked so users could tell whether an old fake address or a real current one was exposed. The pushback was that publishing passwords or even hashes would make a defensive service into a redistribution point for stolen data, while the right party to disclose exact compromised fields is the company that lost them.

    If you operate a breach notification product, resist pressure to become a raw data lookup tool. If you are the breached company, provide precise field-level disclosure yourself so users do not need risky third parties to guess.

      Attribution:
    • charcircuit #1
    • parable #1

In plain english

Addy.io
An email aliasing service that lets users create separate forwarding addresses to reduce tracking and damage from leaks.
API
Application programming interface, a way for software to call another service programmatically.
B2B
Business-to-business, meaning products or services sold to other companies rather than to individual consumers.
GDPR
General Data Protection Regulation, a European Union privacy law that governs how personal data can be processed.
GRC
Governance, risk, and compliance, the business function that evaluates operational controls, legal exposure, and vendor risk.
Have I Been Pwned
A public service that lets people check whether their email address or other identifiers appear in known data breaches.
KYC
Know Your Customer, identity checks used to verify who a person or business is.
PII
Personally identifiable information, data that can identify a specific person.
security.txt
A standard text file placed on a website that tells researchers how to report security issues to the site owner.
SimpleLogin
An email aliasing service that creates unique forwarding addresses for each site or app.

Reference links

Background and regulation

Security reporting and breach response

  • security.txt standard
    Mentioned as a simple way for companies to publish security contact details for vulnerability reporting.

Breach monitoring tools

Identity fraud examples

Email aliasing guidance