A new spam policy for “back button hijacking”

Original Article ↗ Hacker News Discussion ↗

Overall reaction to Google’s new policy

  • Many welcome the change and say it’s long overdue; back-button traps are described as one of the most hated modern web dark patterns.
  • Others are skeptical it will be effective, seeing SEO rules as yet another cat-and-mouse game spammers will route around.
  • Some point out the irony that Google’s own products (YouTube, AMP, News, “open in app” prompts) already degrade navigation and UX.

Browser-level fix vs. search-policy fix

  • A recurring view: browsers should have been designed so back-button hijacking is impossible, or fixed directly now (e.g., special handling of history, permissions, or “previous origin” navigation).
  • A counterargument (including from someone citing Chrome’s prior attempts): technical heuristics are fragile in an adversarial setting; a policy hammer via search ranking is more realistic.
  • Suggestions include: history APIs as explicit permissions, distinguishing “web app” APIs, detecting frantic back-press patterns, or building immutable/tree-like history.

Legitimate vs abusive uses of the History API

  • Defenders cite valid uses:
    • SPAs like mail, chat, or video sites maintaining in-app navigation without full reloads.
    • E‑commerce variants, filters, and galleries that make specific states bookmarkable and shareable.
    • Modals, image viewers, map position, game state, multi-step forms.
  • Critics argue SPAs often abuse history, break true “back” semantics, and add complexity and bugs; many say SPAs should have their own in-app back buttons instead.
  • Concern: how will Google distinguish legitimate SPA navigation from deceptive history stuffing or redirect loops? Fear of false positives, especially for common routers and libraries.

Wider “web encrapification” complaints

  • Thread broadens into frustration with:
    • Overlays, cookie banners, surveys, “are you sure you want to leave?” prompts.
    • Scroll hijacking, Ctrl‑F / keyboard shortcut hijacking, right-click blocking.
    • Paywalls showing up in search and 3rd‑party ad scripts manipulating UX.
  • Many argue that JavaScript-heavy, ad-driven designs and tracking incentives are the root problem; some pine for a simpler, document-centric web.

Workarounds and user tools

  • Users share coping strategies: opening everything in new tabs, long-press/right-click back history, ad blockers and “annoyance” filters, reader mode, or disabling JS per site.
  • Some note Firefox- or userscript-based tweaks to limit pushState or prevent shortcut takeover, but these are seen as expert-only workarounds rather than real fixes.