Winding down Google Sync and Less Secure Apps support

Original Article ↗ Hacker News Discussion ↗

Google is retiring Google Sync and “Less Secure Apps” password access for Workspace accounts, pushing organizations toward OAuth-based authentication or app-specific passwords for IMAP, POP and SMTP. Commenters welcome stronger protection against credential stuffing and phishing, but worry about breaking legacy clients, printers, and scripts, the complexity and cost of OAuth for small projects, and a perceived push toward Google’s own apps and ecosystem lock-in. Many point to app passwords and third‑party mail providers as practical workarounds, while questioning how long Google will keep those alternatives available.

Scope of the change

  • Many note the HN title is misleading: Google is disabling “Less Secure Apps” (username + main password) and Google Sync (ActiveSync) for Workspace, not IMAP/SMTP/POP themselves.
  • App-specific passwords and OAuth remain supported; several users confirm Workspace support has explicitly said app passwords will work for IMAP, POP, and SMTP.
  • Personal Gmail lost LSAs earlier; this finishes the transition for Workspace.

App passwords and legacy devices

  • Heavy concern about printers, scanners, and old clients (e.g., Outlook 2007, iOS Mail via Exchange).
  • Thread consensus: these can continue to work via app passwords or, in some cases, SMTP relays.
  • Some admins report app passwords working reliably; others find them confusing or unreliable and worry typical users/IT will struggle.

OAuth complexity and friction

  • Many complain OAuth2 is confusing, opaque, and error-prone, especially for headless servers and scripts.
  • Issues cited: unclear error messages, changing token behavior, refresh-token quirks, and Google’s high bar (and cost) for having a verified production client.
  • Several tools and workarounds are mentioned (OAuth proxies, CLI helpers, rclone, etc.), but they often require manual OAuth client setup.

Security arguments and password strength

  • Pro-change camp: LSAs enable credential stuffing and lack 2FA; OAuth and app passwords reduce blast radius and phishing risk.
  • Others argue strong unique passwords + TLS and optional 2FA are already sufficient, calling this “security theater” and user-hostile.
  • Debate over app-password entropy (16 random lowercase chars). Most conclude 65–75 bits is ample, especially with online-rate limits.

Lock-in, UX, and competition concerns

  • Several see this as a way to nudge users off third‑party clients and toward Gmail apps, especially given loss of Exchange push in iOS Mail and Google’s resistance to protocols like JMAP.
  • Some institutions already restrict IMAP with Exchange/O365, reinforcing fears of a broader trend toward proprietary ecosystems.
  • A number of users discuss or endorse alternatives (self-hosting, Fastmail, Proton, Tuta), citing better interoperability or spam handling.

Uncertainties

  • Future of app passwords is viewed as unstable: Google docs discourage them, and some organizations report prior deprecation warnings.
  • Exact long-term support level for non‑OAuth IMAP/SMTP via app passwords is seen as “for now,” not guaranteed.