Bruteforcing the phone number of any Google user

Legacy systems, deprecation, and security architecture

• Several comments highlight how large companies accumulate fragile legacy flows (like Google’s no-JS recovery page) that are hard to test and maintain, especially across many products and UIs spanning decades.
• There’s debate over whether Google’s massive revenue means they “should just fix it”:
  • One side says they lack incentive because end users aren’t the real customers; advertisers and enterprise buyers are.
  • Others stress that money alone doesn’t solve it: “unsexy” maintenance work is hard to staff, hard to pay differently for, and often needs high-level attention to reorganize properly.
• Some argue that aggressive product deprecation is security-driven: every extra surface is another future exploit. Others counter that if a product’s mere existence threatens account security, the shared-account architecture is flawed (too much power in central identity/contacts services).

Bug bounties, incentives, and “likelihood low”

• Many commenters think the ~$5k / $1,337 awards are insultingly low for a vulnerability that can leak phone numbers at Google scale and potentially aid serious attacks.
• Concern: underpaying pushes talented researchers toward less ethical buyers.
• Counterpoint: bug bounties are not realistically competing with nation-state or criminal markets; the value is in mobilizing many ethical researchers cheaply, despite triage overhead.

Phone numbers, privacy, and SIM-swap risk

• Strong disagreement over how “private” a phone number is:
  • Some say it’s already widely exposed via breaches, data brokers, and historic phone books; treat it like a name.
  • Others emphasize modern consequences: SIM swaps, SMS 2FA, and easy social engineering make number exposure materially dangerous.
• Several recommend never tying real numbers to major accounts, or using burner/relay numbers, though practical constraints (forced verification, carrier rules) complicate this.

Cross-service hints and data aggregation

• Commenters are alarmed that partial phone/email/card hints from many services can be combined to fully reconstruct identifiers. Past real-world cases (e.g., chained Apple/Amazon flows) are cited as precedent.
• Telegram bots, data brokers, and automated services already aggregate such fragments.

IPv6 and rate limiting

• The exploit’s use of many IPv6 addresses spurs discussion that per-IP limits are obsolete:
  • Common suggestion: rate limit by /64 block at least, since many providers hand out /64s or bigger.
  • Others note this can unfairly impact shared networks (universities, large LANs) and that with residential /56/48 delegations, effective abuse detection must consider ASN and allocation patterns.