Google's Back Button Attack: Why LinkedIn and Microsoft Can't Escape the History API Dragnet
Google is implementing a spam policy by June 15 targeting 'back button hijacking'—the deceptive manipulation of browser history for pageview farming.
The debate fractures over motives. Some see Google's enforcement as a necessary slap against monopoly power, noting that sites like Learn.Microsoft.com must comply with web standards (TheMinions). Conversely, lvxferre claims Google built the trap itself by enabling the underlying mechanisms, like the history API's `replaceState()` function, suggesting the enforcement is self-serving.
The raw consensus suggests the problem is deeper than just bad code. While most agree the hijacking is deceptive, the core conflict remains: is this Google acting as a benevolent regulator, or is it simply policing the misuse of tools it helped build? The consensus points to systemic site design flaws, not just individual bad actors.
Key Points
Back button hijacking is an exploitative tactic used by sites to trick users into extra clicks.
Powderhorn details how this forces users off a profile link back to a social feed, inflating metrics.
The misuse is technically enabled by browser history manipulation functions.
lvxferre specifies the risk lies with JavaScript abusing functions like `replaceState()` to lie about navigation paths.
Google's action is seen by some as a necessary correction against corporate overreach.
TheMinions praised the enforcement for forcing major players to adhere to expected web standards.
Major corporations will likely remain immune to this policy.
panda_abyss predicts big corps like LinkedIn and Microsoft will be exempt due to their lobbying power.
The ideal fix is not just policy, but browser behavior.
RunawayFixer suggested the back button must remember and restore the user's precise scroll position, not just the previous URL.
Source Discussions (3)
This report was synthesized from the following Lemmy discussions, ranked by community score.