Leaking the email of any YouTube user for $10k

Original Article ↗ Hacker News Discussion ↗

Exploit & Real-World Impact

  • Attack chain:
    • Use a public YouTube API to turn a channel ID into a GAIA (Google account) ID.
    • Feed that GAIA ID into an old Pixel Recorder sharing endpoint that reveals the associated email.
    • Prevent the victim from receiving a notification by sending a title/subject ~2.5M characters long so the mail delivery fails.
  • Impact discussed:
    • Deanonymizing pseudonymous creators, commenters, and critics (e.g., regime opponents, vulnerable individuals).
    • Better-targeted phishing and social engineering by mapping channels → personal or private emails.
    • Linking multiple channels to the same person and correlating with other leaks and public profiles.
  • Some argue the risk is muted:
    • Many large channels use brand accounts with generated emails or public business contacts anyway.
    • The exploit is relatively low-volume (2 calls per lookup, huge payloads, very noisy in logs), making “scrape every account” unrealistic.
    • Email-only leaks are seen as less severe than credential or payment data.

Bug Bounty Size & Economics

  • $10k total (after an initial ~$3k) is viewed by some as:
    • Surprisingly high for a server-side web bug that only leaks emails.
    • In line with industry norms where server-side issues have weak grey markets and can be killed instantly once detected.
  • Others see it as puny:
    • Small relative to SWE comp, time investment, and potential black/grey‑market uses (doxing, OSINT, targeted phishing, data-broker style datasets).
    • Argue that companies underpay because they bear little legal/financial consequence for privacy leaks.
  • Several points about market reality:
    • High six-figure payouts exist mainly for client-side full chains (iOS/Android/Chrome), where there’s a mature brokerage market and multiple state buyers.
    • For niche server-side bugs like this, there’s no well-established buyer ecosystem; selling them often means “planning a heist,” not selling a commodity exploit.
    • Bug bounties pay per bug, not per hour; sustainable income comes from finding many smaller issues, not one big one.

Security, Google’s Complexity & Product Lifecycle

  • Comments that with Google’s scale and legacy surface area, obscure vulnerabilities are inevitable, and security is a “continuous battle” rather than absolute.
  • Some see this as a reason Google retires “non-core” products: every extra service is additional attack surface and maintenance drag.
  • Others criticize:
    • Slow fix timeline (~147 days from report to full remediation, longer than the 90‑day window Project Zero pressures others with).
    • A culture that can treat such reports as low-priority despite serious privacy implications.

Miscellaneous Discussion

  • Many readers misread the title as:
    • Cost to buy an email, or
    • Cost in compute to brute-force something, rather than the bounty paid.
  • Debate over the bug being downgraded for “complexity of the attack chain”: some see that as backwards, others say harder-to-find = less likely to be exploited in practice.
  • Side threads:
    • Complaints about Google support/appeals processes (e.g., Maps edits, account issues).
    • Grumbling about protobufs base64-encoded inside JSON as emblematic of Google’s API style.
    • Date-format confusion (DD/MM/YY vs MM/DD/YY) and regional norms.