You opened Gmail in your browser and it asked for permission to access your local network. That is an alarming thing to read on a webmail page, and the search results for it are unhelpful — they are written for developers, or they answer a different question about email scanning entirely. Here is what actually happened.
Chrome 142 introduced a new Local Network Access permission. Any website that tries to reach a device on your home network — your router, a printer, a NAS — now has to ask first, and Gmail’s web interface triggered that check. The prompt is not evidence that Google is mapping your home. It is the browser doing something it never used to do: telling you when a page reaches inward instead of outward. Denying it blocks that page’s local requests and nothing else.
Everything technical below comes from Google’s own developer documentation for Chrome and Android — the primary sources — and is linked at the end. I have not inspected Gmail’s network traffic, and I say so because it matters: I can tell you exactly what the permission controls and what refusing it does, but I cannot tell you Google’s intent. Where the honest answer is “Google has not published one”, that is what you will read, rather than a confident guess.
What you actually saw
Chrome has spent years trying to close a genuine security hole: a website you visit can quietly send requests to devices sitting on your home network. Those devices — routers, printers, IP cameras, smart plugs — are often unauthenticated, because their designers assumed anything already inside the network was trusted.
The fix is Local Network Access. It appeared behind a flag in Chrome 138 (chrome://flags#local-network-access-check) and launched with the prompt enabled by default in Chrome 142. It replaces the earlier Private Network Access effort, which was halted.
Three things on a page can set it off: a JavaScript fetch() call, loading a subresource, or navigating a subframe — in each case, from the public internet toward a local address.
What counts as “local”
This is narrower and more precise than “your network”, and worth knowing because it tells you exactly what the block covers.
| Type | Range |
|---|---|
| Private IPv4 (RFC1918) | 192.168.0.0/16 and the other private ranges |
| IPv4 link-local | 169.254.0.0/16 |
| IPv6 unique local | fc00::/7 |
| IPv6 link-local | fe80::/10 |
| Loopback | 127.0.0.0/8 and ::1/128 |
| Local names | .local |
If you self-host anything, that last row is the one to notice. A service you reach at nas.local is inside this net.
Why Chrome added it
Two stated reasons, and both are defensible.
The first is cross-site request forgery aimed at your router. A malicious page can attempt requests against 192.168.1.1 hoping to hit an admin interface that never asked it to log in. This class of attack has been used against consumer routers for years, and until now the browser had no mechanism for the user to see it coming.
The second is fingerprinting. Which devices answer on your network is oddly distinctive. A page that can enumerate them learns something durable about you without a cookie in sight.
So why is Gmail asking?
This is where I have to be straight with you: Google has not published an explanation for why its webmail interface makes a request that trips this check. Every page currently ranking for this question either documents the permission for developers or answers something unrelated. None of them says why Gmail specifically.
The useful part is that you do not need to know the reason to make the decision. What matters is what the permission gives away and what refusing it costs — and both of those are documented.
What happens if you say no
For the browser prompt, refusing means that page’s requests to local addresses are blocked. The rest of the site continues to work; you are not logging out of Gmail or breaking your inbox.
The Android side of this change is documented more precisely, and the pattern is the same: outbound and inbound local requests simply fail. TCP connections time out. UDP returns an EPERM error. The app keeps running — the specific feature that needed the local network does not.
In practice, if you deny it and later find that casting to a TV, adding a printer, or reaching a self-hosted service has stopped working, you have found what the permission was for. You can grant it then.
The same change is coming to Android apps
This is not only a browser story, and if you use Android it is the more consequential half.
| Android 16 | Android 17 | |
|---|---|---|
| Status | Opt-in | Mandatory for apps targeting SDK 37 or higher |
| Permission | NEARBY_WIFI_DEVICES | ACCESS_LOCAL_NETWORK |
| Permission group | — | NEARBY_DEVICES |
| If denied | Local traffic fails — TCP times out, UDP returns EPERM | |
What it gates on Android is broader than most people assume: raw sockets to local addresses including mDNS and SSDP, framework classes such as NsdManager, outgoing and incoming TCP, UDP unicast, multicast and broadcast, and resolution of .local names.
Google’s reasoning is worth quoting plainly, because it explains why this is a privacy change and not merely a security one. Enumerating devices on a local network can form a fingerprint of the user and act as a proxy for location. Before this change, any app holding only the ordinary internet permission could reach devices on your home network — with no prompt and no record.
That is the part most people missed for years, and it is the reason the prompt is worth welcoming rather than resenting. You are not being asked for something new. You are being told about something that was already happening.
Should you allow it?
Two questions. Nothing leaves your browser.
1. Do you use this site or app to cast, print, or reach a device in your home?
Yes
No
Not sure
2. Do you run anything self-hosted on your network (NAS, media server, home automation)?
Yes
No
How to change your answer later
Nothing here is permanent, which is the main reason denying first is a reasonable default.
- In Chrome: click the icon at the left of the address bar while on the site, and adjust its permissions. Site settings holds the same controls if you would rather manage them in one place.
- On Android: open Settings, then Apps, choose the app, then Permissions. The local network control sits with the nearby-devices permissions rather than with location.
- Test what broke: if a feature stopped working after you refused, that feature was the reason for the request. Grant it and try again.
The wider point
It is easy to read a permission prompt as an accusation. In this case the prompt is the improvement. For most of the web’s history, the boundary between “the internet” and “the machines in your house” was enforced by nothing but the assumption that no page would bother to cross it — an assumption router attacks disproved repeatedly.
Reading a prompt carefully and refusing by default is a good habit, and it applies well beyond this one. Our analysis of the Huntarr security incident covers what else to check before trusting a self-hosted application with access to your network, and the Obtainium review looks at the related problem of knowing what your sideloaded apps are doing after you install them. If you are curious how we decide what to investigate, the method is published in full.
Frequently asked questions
Is it dangerous that Gmail asked to access my local network?
The prompt itself is not evidence of anything harmful. It appears because Chrome 142 now requires any website to ask before it can reach devices on your local network, so the request became visible where it previously would not have been. Denying it blocks that page’s local requests and leaves the rest of the site working.
Why does the top search result not answer this?
Because most pages ranking for this question are developer documentation explaining how to declare the permission in an app, or articles about apps scanning the contents of your email — a different subject entirely. The question is common; a plain-language answer to it is not.
What counts as my “local network” here?
Private IPv4 ranges such as 192.168.0.0/16, IPv4 link-local 169.254.0.0/16, IPv6 unique local addresses fc00::/7, IPv6 link-local fe80::/10, loopback addresses 127.0.0.0/8 and ::1/128, and any name ending in .local.
What breaks if I deny local network access?
Only functions that need to reach a device on your network — casting to a TV, discovering a printer, or connecting to a self-hosted service. On Android the failure is documented: TCP connections time out and UDP returns an EPERM error. The app or site itself keeps working.
Which Chrome version introduced this?
It was available behind a flag in Chrome 138 and launched with the permission prompt enabled by default in Chrome 142. It replaces the earlier Private Network Access proposal, which was halted.
Does this affect Android apps as well as websites?
Yes. Android 16 introduced local network protections as opt-in using the NEARBY_WIFI_DEVICES permission, and Android 17 makes them mandatory for apps targeting SDK 37 or higher using ACCESS_LOCAL_NETWORK, part of the NEARBY_DEVICES permission group.
Why does a local network permission count as privacy rather than security?
Because the set of devices that answer on your network is distinctive enough to act as a fingerprint, and can serve as a proxy for your location. Google cites both reasons. Before this change, any app with ordinary internet permission could reach local devices without asking.
Can I change my mind after denying it?
Yes. In Chrome, use the icon at the left of the address bar while on the site, or Site settings. On Android, go to Settings, then Apps, then the app, then Permissions, where it sits with the nearby-devices permissions.
Sources
- Chrome for Developers — Local Network Access — versions, triggers, gated address ranges and rationale
- Android Developers — Local network permission — Android 16 and 17 behaviour, permission names, denial errors
- r/degoogle — where the question was asked repeatedly, and where the absence of a plain answer was obvious
Documentation read on 8 August 2026. Version numbers and rollout behaviour change; check the primary sources above if you are reading this much later. Google has published no explanation specific to Gmail, and this article does not invent one.