Massive Loophole Enables Squatting in Google Apps for Domains System
Google Apps has a fundamental flaw in the way it creates accounts. Anyone can squat on a domain without proof of ownership. I found this out yesterday when I attempted to go through the process of setting up shared calendaring for the LockerGnome team.
Context & Ripple Effects
This lands in a familiar sequence of Google Apps provisioning failures. In September 2009, schools that moved student mail onto the platform found accounts could read each other's messages (students "Going Google" reading each other's emails), and in November 2010 TechCrunch flagged what it called a pretty big security hole in Google's own infrastructure ("Whoa, Google, That's A Pretty Big Security Hole"). Each incident points at the same root: Google's automated signup and account-linking flows trusting identifiers — an email address, a claimed domain — rather than verifying actual control.
What's new here is that the same weak verification extends to whole domains: anyone can walk through the Apps setup flow and squat on a domain with no ownership proof, which the author hit while trying to set up shared calendaring for the LockerGnome team. The pattern echoes the older typo-squatting economy Microsoft Research documented against Google results back in 2005 (MS Research: typo-squatters gaming Google) — except now the asset being claimed is an organization's identity inside its own productivity suite.
First-order effects
- Any organization that has not yet registered its domain with Google Apps can have that registration taken first by a stranger, locking out the legitimate owner from mail, calendar, and Docs on their own name.
- Teams like LockerGnome attempting routine collaboration setup — shared calendars across the company — are blocked until the squatting claim is untangled with Google support.
Second-order effects
- IT administrators adopting hosted suites must add pre-registration of every domain variant to deployment checklists, turning account provisioning into a defensive land-grab rather than an administrative step.
- Competing hosted-email vendors gain a sales argument built on stronger domain-ownership verification at signup, pressuring Google to harden its flow or cede security-sensitive accounts.
Third-order effects
- If signup flows across SaaS platforms keep treating a reachable address or unclaimed namespace as proof of entitlement, domain and identity squatting becomes a standing class of vulnerability in cloud services, forcing providers toward out-of-band ownership verification as a baseline requirement.
The trend: Cloud productivity platforms are repeating a predictable failure mode — treating self-reported identity as verified ownership — making domain squatting a recurring structural risk wherever SaaS signup automation skips real proof-of-control.