Chrome 69 and the Hidden www That Triggered a Security Backlash

In September 2018, Google rolled out Chrome 69 with a polished new UI and a slew of usability upgrades to mark the browser’s tenth anniversary. Yet tucked within the cosmetic changes was a deceptively small tweak that sparked outsized controversy in the web development and cybersecurity communities: Chrome began hiding the “www.” and “m.” prefixes from URLs in the address bar by default. What seemed to Google’s product managers like a minor simplification for end users ignited a fierce backlash from security professionals, domain administrators, and technical users who argued that the change undermined trust, obfuscated important information, and opened new vectors for phishing and domain spoofing.

The core of the problem lay in how browsers visually display domain names. Traditionally, URLs are parsed by users at a glance to determine the identity of the website being visited. Every component of the URL—from the protocol (https) to the subdomain (www. or m. for mobile)—provides critical cues about site ownership and authenticity. For years, browsers had consistently displayed these parts, allowing savvy users to differentiate between legitimate domains and cleverly disguised imposters.

Chrome 69 broke from this tradition by treating certain subdomains as “trivial.” Specifically, Chrome’s omnibox (its combined search and URL bar) stripped out www. and m. by default, showing only the registered domain and top-level domain. So https://www.example.com was visually reduced to example.com, and https://m.example.com similarly appeared as example.com. Google defended the decision by arguing that these subdomains offered no meaningful information to most users and that the simplification would reduce visual noise, helping users focus on what matters—the domain itself.

But critics quickly pointed out that this assumption failed to hold up in many real-world cases. Subdomains, while sometimes benign, are often used to differentiate entirely distinct web services, infrastructures, or even entities. A company might host a secure login portal at secure.example.com, while example.com redirects to a general marketing page. A phishing site operating on www.security-check.com might hope users overlook that “security-check” is the actual domain, not “security.com.” By removing www. or m. from the visual address, Chrome effectively masked potentially vital distinctions, making phishing attacks easier to pull off and harder to spot.

Security researchers quickly identified how attackers could exploit this behavior. One tactic involved registering domains like www-bank.com or m-paypal-account.com, counting on Chrome to truncate the prefix and show only bank.com or paypal-account.com, thus giving users a false sense of legitimacy. While technically the URL was correct, the visual context—stripped of subdomain cues—blurred the boundary between trustworthy and suspicious sites.

Further complicating matters was the inconsistency this introduced across platforms and browsers. Firefox, Safari, and older versions of Chrome still displayed full URLs including the www. prefix, meaning users switching between browsers would encounter different views of the same domain. This inconsistency sowed confusion for web administrators trying to troubleshoot domain configurations, as well as users trying to verify which version of a URL was secure or canonical.

Criticism wasn’t limited to security circles. Developers, SEOs, and accessibility advocates raised alarms about the implications for education and digital literacy. For years, users had been taught to “look closely at the URL” to verify authenticity, with emphasis on each part of the domain. Hiding a portion of the URL—especially without a clear opt-out or notification—eroded this fundamental practice. Google initially doubled down on the change, calling it part of a broader push to simplify URLs, which company engineers have long viewed as too complex and error-prone for average users.

But the community backlash was swift and sustained. GitHub issues and Chrome bug reports flooded with feedback. Prominent engineers from Mozilla, Cloudflare, and the EFF publicly criticized the move. One developer even created an extension called “Restore URL Bar” that reversed the change, restoring full domain visibility. Eventually, Google conceded some ground. In Chrome 70, released in October 2018, Google added a flag (chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains) that allowed advanced users to toggle the behavior off. Later versions required even deeper configuration, but the debate never fully subsided.

The controversy around Chrome 69’s address bar update illustrates a deeper tension in browser design: the push-pull between simplicity for the masses and transparency for the vigilant. Google’s emphasis on streamlining the web experience sometimes collides with the needs of power users and the unforgiving realities of web security. In a world rife with phishing, typosquatting, and homograph attacks, the visible structure of a URL is not trivial—it’s one of the last lines of defense for users trying to determine authenticity.

Ultimately, while Chrome’s shift in displaying URLs may have been born from a desire to reduce cognitive overhead, it unintentionally reduced the very cues that enable informed decision-making online. It offered an important lesson for product teams building for billions: design decisions that erase technical context may make things look simpler, but they can also make users more vulnerable. In trying to help people trust the web, Chrome 69 inadvertently made it harder for them to trust what they see.

In September 2018, Google rolled out Chrome 69 with a polished new UI and a slew of usability upgrades to mark the browser’s tenth anniversary. Yet tucked within the cosmetic changes was a deceptively small tweak that sparked outsized controversy in the web development and cybersecurity communities: Chrome began hiding the “www.” and “m.” prefixes…