This Google Chrome feature will protect home networks from attacks

Google is trying out a new feature to stop bad public websites from using a user’s browser to attack devices and services on private, internal networks. In simpler terms, Google wants to stop harmful websites from attacking your devices (like printers or routers) at home or on your computer. These devices are usually seen as safe because they’re not directly connected to the internet and are protected by a router.

“To prevent malicious websites from pivoting through the user agent’s network position to attack devices and services which reasonably assumed they were unreachable from the Internet at large, by virtue of residing on the user’s local intranet or the user’s machine,” Google described the idea in a support document.

The new “Private Network Access protections” feature, which will be in a “warning-only” mode in Chrome 123, checks before a public website (called “site A”) tells a browser to go to another site (called “site B”) on the user’s private network.

The checks involve making sure the request comes from a secure context and sending a preliminary request to see if site B (like an HTTP server on a loopback address or a router’s web panel) allows access from a public website through specific requests called CORS-preflight requests.

Unlike current protections for subresources and workers, this feature is all about navigation requests. Its main goal is to protect users’ private networks from possible threats.

Under this new idea, when the browser sees that a public site is trying to connect to an internal device, it will first send a preflight request to the device. If the device doesn’t respond, the connection will be stopped. But if the internal device does respond, it can tell the browser whether the request should be allowed using an ‘Access-Control-Request-Private-Network’ header.

This means requests to devices on an internal network will be blocked unless the device specifically allows connections from public websites. During the warning stage, even if the checks fail, the feature won’t block the requests. Instead, developers will see a warning in the DevTools console, giving them time to make changes before stricter rules are enforced.