Google Chrome will soon prevent malicious websites from attacking your home network
Google Chrome is getting a new security feature that can help prevent websites from attacking your home network. The mechanism has been termed "Private Network Access for Navigation Requests".
To be more specific, the feature which was spotted by XDA, has been designed to protect the devices that are connected to your home network, from being infected. This is done by restricting the navigation requests that may be initiated by a malicious website.
Google Chrome's Private Network Access for Navigation Requests
Normally, when you go from one website to another, the browser will take you to the destination. This is done by the user, i.e. by clicking on links. Some websites can redirect you to other web pages automatically, and this is when things can turn ugly. There are some protocols already in place, such as Google's Safe Browsing, that protect users from dangerous web pages. With the new Private Network Access security feature in place, Chrome will check the origin of the request, i.e. to identify whether it comes from a secure source. It then sends a preflight request to check whether the destination website has a header that allows private network access. In other words, it scans both websites, and the device, to ensure that they are not infected, before allowing the page to load in your web browser.
This is how the Mountain View company describes the feature, "Requests are considered “Private Network Access” if the resulting connection’s IP address space is less-public than the IP address space in the request’s initiator’s policy container”.
Google also wants to disable auto-reloading of web pages in case a request has been blocked by Private Network Access. The official documentation page for the feature, which you can access on Google Docs, has a screenshot that outlines the error message that a user will see when a malicious connection attempt was blocked.
Initially, Chrome will not fail the checks even if the request itself does fail. But this "warning-only version" is likely to exist only during the development phase, Google says that Chrome's DevTools will log the request as a warning to help web developers understand how it works. The feature will later be updated with a setting which a user can use to disable on a per-site basis.
Mozilla and Apple have given their nod of approval for the feature as it will become part of the web standard, but they are not happy with the term "Private" in the name as it could result in some confusion, and feel that "Local Network Access" would better suit the feature.
Google's announcement says the feature will be shipped with Chrome 123 for desktop and Android. According to the browser's roadmap, Chrome version 123 will be available in the Beta channel from February 21, and is set to hit the Stable channel on March 13. The Chrome Status page lists Private Network Access for Navigation Requests among the features that are enabled by default.
This feature might be a good way to protect PCs from being spied upon, or become part of botnets. Of course, it won't be completely foolproof, I recommend using a good ad blocker like uBlock Origin, a reliable antivirus such as Windows Defender. Pay attention to URLs on web pages, avoid HTTP links and sketchy websites.
What do you think about the Private Network Access feature?
Per Ashland’s post, feature is not available yet in current Chrome stable
Version 122.0.6261.70 (Official Build) (64-bit).
Apple’s Bonjour (Avahi) and several million “Raspberry Pi” computers, or “Chromecast” or “Fire Stick” for lazy people who can’t connect their devices to the internet and don’t want to learn networking. MDNS has been spoofed for some time now.
Thank You Kim
I’ve learned so much from you Iam a dedicated fan
Keep up good work
This is a comentary I wrote to Google as the newly installed version of Chrome in Fedora is constantly stalling (briefly…).
https://www.ghacks.net/2124/02/20/google-chrome-will-soon-prevent-malicious-websites-from-attacking-its-own-network/
It was also a comentary on this very important info:
https://www.bleepingcomputer.com/news/security/hackers-abuse-google-cloud-run-in-massive-banking-trojan-campaign/
Anyway congratulations to Ghacks, still the best!
I certainly see more positives then negatives and the speculations about how this will be abused is just that.
In other words, priming the browser for censorship under age old excuse of “for your safety”. Are there elections already?
Just what we need. Google looking into our local network. No, thanks!
Will this mean the “Block Outsider Intrusion into LAN” filter list in uBlock Origin and also the “Localhost Resource Permission” in Brave won’t be necessary any more?
https://brave.com/privacy-updates/27-localhost-permission/
>”In other words, it scans both websites, and the device, to ensure that they are not infected, before allowing the page to load in your web browser.”
So Google matches your requests with the page you are leaving AND the page you are going to AND your device. Sounds like a law enforcement dream come true – just subpoena Google once and get all the information that would previously require 3 or 4 subpoenas, not all of which may have been complied with.
And lets not forget, it wasn’t that long ago that Edward Snowden showed that Google was sending all customer data directly to the NSA – I’m sure the NSA would love this kind of triangulated data.
well John, currently it is a gaping hole. My first guess would be a simple heuristic: if the domain of the page that makes the request resolves to something on the local subnet, then it is ‘probably ok’ but if it looks like public ip4/ip6 then it most likely is ‘not ok’. (throw in complications with iframes)
It is still pretty shittly, but even a little help is a boon at this point. The alternative is of course DRAKONIAN firewall settings to jail your browser. Which Google rather obviously does not want you to do and would make work complicated if you need something “inside the perimeter” to do your job – you’d be inconveniently working 2 browsers, each with different access, and must maintain strict discipline. One for “the web” and one for “local”.
The gist of the issue is (as usual) javascript and what it is allowed to do.
A clever criminal could set it up to probe, connect to and manipulate not just “yourself” aka localhost/127.0.0.1 in ip4 parlance, but everything else on your lan/wan/subnet, just like a fullblown infection could do.
In a corporate setting, that likely includes whitelisted access to all the internal stuff that “the internet” is not allowed to see (often carte blance access to the entire subnet) – but by use of js in your browser it easily becomes a temporary proxy or tool for information gathering for a higher stakes APT intrusion, riding under the shield of permissions that your browser is given.
E.g. a making a portscanner that runs in your browser is not a big trick. You just don’t see it much because that would trigger a lot of alarms and blow the cover you have inside the browser that does not get enough attention.
And you could do MUCH worse. However this is where I draw the line on “giving ideas”.
I think I have commented on these lines before. We are in a world of shit because they (all of them) refuse to make safe software and follow safe principles.
It has always been insanity to allow webdefined (unchecked, unsanitized, from anyone anywhere) access to your local resources. Whether directly (part of why we have firewalls) or indirectly with the browsers acting as the proxy middleman inside the fence.
Interesting explanation. Thanks.
I don’t understand the way that Google could prevent something that they don’t know for sure to be malicious or not. Indeed they say that “With the new Private Network Access security feature in place, Chrome will check the origin of the request, i.e. to identify whether it comes from a secure source”, so it’s unclear the method and it’s also the criteria.