The solution
Ars Technica reported in January 2022 that Google was acting on a class of attack that had worked for over a decade: using browsers as a beachhead into routers and other devices on the visitor's network. Browsers can by default connect to virtually any resource inside the local network, which has given rise to cross-site request forgery attacks. In one 2014 incident, hackers changed the DNS settings on more than 300,000 routers; in 2016 the DNSChanger malware used the same route against Netgear, D-Link, Comtrend and Pirelli routers.
The fix is a specification called private network access. When a public site wants an endpoint in the private network, Chrome sends a preflight request with the new header Access-Control-Request-Private-Network: true; the request goes through only if the device responds with Access-Control-Allow-Private-Network: true. It builds on the CORS protocol.
The rollout is staged. From Chrome 98 the browser sends the preflight but a failure only logs a warning in the DevTools issues panel, and the request still happens. Around Chrome 101, if the trial shows no major breakage, permission becomes mandatory. Google engineers wrote that any failed preflight will then result in a failed fetch, and the logged warnings let site owners test their sites beforehand.
Why it worked
Browsers must reach many services, so by default they can reach anything inside the local network, which attackers exploit.
Routers and printers are often locked down, so attackers go through the browser instead.
Reusing CORS means a familiar mechanism and a small spec change.
Log-only warnings let Google see what would break before enforcement.
What can be applied
Close a long-open hole in stages, log-only first, so you can see what would break before making the rule mandatory.
Aftermath
The plan at the time was warnings in Chrome 98 and mandatory permission around Chrome 101, provided the results did not show major parts of the internet would break. Ars did not report what happened after.
FOLLOW THE EVIDENCE