As noted in comment #1, this behavior was seen on macOS 15, an OS release that is in beta. The Chrome Mac team has seen this too, but while we investigate we also are waiting a bit as sometime’s Apple’s new protections glitch in terms of when they trigger.

Re comment #4, this is not an issue for TE to verify.

Hi coburrow@, thanks for reporting this issue! We are aware of this new permission in macOS 15 and have finished the implementation to address this issue. The fix will roll out in M128, which will release to Stable on Aug 20, 2024 https://chromiumdash.appspot.com/schedule

Running Google Chrome Stable 128.0.6613.85 and just updated to macOS 15b7 and on first boot after the upgrade launching Chrome triggered this dialog. Do I misunderstand the "M128, which will release to Stable on Aug 20, 2024 " from #comment8 above?

Tried Chromium 130.0.6683.0 and it does not trigger the dialog.

This feature is rolling out through a server-side config. So it's not enable on 100% of the M128 population yet.

Hello muyaoxu@google.com

I have a top-tier customer (Airbnb.com) reporting this same behavior on the stable versions of Chrome and MacOS:

• Chrome 128.0.6613.120
• macOS 15.0 (Build 24A5331b)

Can you please confirm the Chrome browser M128 versions on which the fix is expected?

Thanks for the context muyaoxu@google.com.

Considering that M130 Stable is not meant for release until at least October 15th, is it safe to assume that the server-side fix will continue to rollout, slowly but steadily, until eventually 100% of the M128 / M129 browsers are fixed from this prompt? I am asking with the goal to set the right expectations for this customer

@muyaoxu, do you know if this will be at 100% for M129?

The customer is requesting to expedite the rollout for their domain. I understand this is being controlled via Finch, and we aren't able to add explicit domains to the rollout. Can the rollout be expedited for M129?

Edit: nevermind, I actually read #comment17 again and understand.

Running macOS 15.0 (24A335), I just downloaded Google Chrome Beta (Version 129.0.6668.42 (Official Build) beta (arm64)), and it prompted to find devices on local networks on first launch, just like previous versions. I've confirmed this on two different systems. Is the fix supposed to be in Beta/Version 129.0.6668.42?

FYI: Chrome 129.0.6668.90 didn't prompt for local network access on first launch on a clean 15.0.1 install.

Thanks a lot for verifying. I really appreciate it. I'll close the bug now.

That's interesting. Cast in Chrome shouldn't use the GPU process. Does this prompt show up when Chrome first launches?

Thanks for sharing this! We don't deliberately post tasks to the gpu process, or other processes in code. But there might be some optimization happening that we don't know. I'll keep an eye on it.

Yes. It's expected that the prompt "Google Chrome Beta..." shows up when users explicitly open the cast dialog. What's interesting in comment #22 is that the GPU process is requesting the permission.

I'm still seeing this on 15.1, Chrome Version 130.0.6723.70.
https://screenshot.googleplex.com/9MGCqPcKdg8SyFY

It just appeared randomly. I was in a personal Meet GVC, but am not certain if that's relevant.

Logs from tccd, responsible for mediating these permission decisions, and the network extension subsystem could be helpful in understanding what's going on:

log show --start '2024-10-30 9:00:00' --end '2024-10-30 10:00:00' --predicate 'process = "tccd" or subsystem = "com.apple.networkextension"'

These subsystems log a lot of messages, so I'd suggest tweaking the start / end times to be a few minutes before and after the prompt was displayed to limit how much data this generates while still capturing everything of relevance.

Thanks, Jeff.

That line message does seem like it could be relevant. One thing that I don't see is exactly what caused UserEventAgent to be asking about Chrome or any mention of a decision to prompt the user. I've seen both when I looked at logs of an earlier occurrence of this. I may have misremembered the process / subsystem that emits that message. When you can, would you mind capturing logs for +/- 3 minutes of that timestamp with the --predicate "…" argument removed?

The group of lines around that message make me wonder if this is related to the Chrome updater having downloaded and staged an update, pending a Chrome restart.

2024-10-30 08:59:49.427489-0700 0x3c279    Default     0x0                  349    0    UserEventAgent: (com.apple.networkextension) [com.apple.networkextension:] LocalNetwork: found bundle id com.google.Chrome by PID
2024-10-30 08:59:49.440998-0700 0x395bd    Default     0x0                  441    0    nehelper: (libsystem_networkextension.dylib) [com.apple.networkextension:] UUID cache miss for com.google.Chrome
2024-10-30 08:59:49.444011-0700 0x3c27c    Default     0x0                  441    0    nehelper: [com.apple.networkextension:] Caching 2 UUID(s) for com.google.Chrome
2024-10-30 08:59:49.446573-0700 0x3c27c    Default     0x0                  441    0    nehelper: [com.apple.networkextension:] Setting UUID cache generation to 282

Specifically, the network extension subsystem that is responsible for the "find devices on your local network" prompting does not recognize the Mach-O UUIDs of Chrome's binary. Earlier log messages related to microphone / camera permissions reference a path to the main Google Chrome executable under $TMPDIR/../com.google.Chrome.code_sign_clone/code_sign_clone.*/Google Chrome.app, which is where go/code-sign-safe-updates stages a clone of the Chrome application to mitigate many of the impacts of staged updates on code signature validation.

When I last looked into this, this local network permission is associated with the specific Mach-O UUIDs of an application rather than being tied to a code signing identity like most other TCC permissions are on macOS. The network extension subsystem listens for LaunchServices notifications about an application being installed and updates the Mach-O UUIDs it associates with an application's bundle identifier. This means that when LaunchService sees a new version of an application, the local network permission is lost for prior versions of that application, even if they're still running.

Hopefully less filtered logging for that time period will confirm or refute this hypothesis.

Hi Jeff,

On Chrome on macOS doesn't start discovery until explicit user interaction with the Cast UI, or the Global Media Controls dialog. If you haven't quit the browser since you saw the permission prompt, could you please go to chrome://media-router-internals and share the logs?

https://screenshot.googleplex.com/4Su3rAHxjXj3UWV.png

Hi Mark, paste choked on that one, attaching the log output requested. I do have a Chrome update pending which may have been staged/prepared around the same time.

Hi Muyao, I have not quit or restarted the browser. Here is a screenshot of the logs from earlier today around that time.
https://screenshot.googleplex.com/4ngNGTjEBDFoSGR

Thanks,
Jeff

Thanks for the screenshot, Jeff.

It looks like the device discovery service wasn't started when you see the permission, which is weird. Maybe something other than cast is triggering the prompt.

I just saw this pop-up on my personal machine. I suspect it's due to a Chrome update, as there's now one pending. I've attached a logarchive generated with log collect --last 5m --predicate 'process = "tccd" or subsystem = "com.apple.networkextension"' which should cover the time.

I spent a lot of time staring at Jeff's logs without finding anything specific.

Clay's logs were immediately useful:

info	2024-10-30 20:16:41.839936 -0400	UserEventAgent	Got local network blocked notification: pid: 665, uuid: 4C4C4406-5555-3144-A10C-9D0AE092D97B, bundle_id: (null)
default	2024-10-30 20:16:41.841119 -0400	UserEventAgent	LocalNetwork: found bundle id com.google.Chrome by PID
info	2024-10-30 20:16:41.842885 -0400	UserEventAgent	LocalNetwork: did not find bundle ID for UUID 4C4C4406-5555-3144-A10C-9D0AE092D97B
info	2024-10-30 20:16:41.842890 -0400	UserEventAgent	Found bundle ID: com.google.Chrome
info	2024-10-30 20:16:41.844538 -0400	UserEventAgent	Got local network blocked notification: pid: 665, uuid: 4C4C4406-5555-3144-A10C-9D0AE092D97B, bundle_id: (null)
default	2024-10-30 20:16:41.844553 -0400	UserEventAgent	LocalNetwork: found bundle id com.google.Chrome by PID
info	2024-10-30 20:16:41.844707 -0400	UserEventAgent	LocalNetwork: did not find bundle ID for UUID 4C4C4406-5555-3144-A10C-9D0AE092D97B
info	2024-10-30 20:16:41.844707 -0400	UserEventAgent	Found bundle ID: com.google.Chrome
info	2024-10-30 20:16:41.845005 -0400	nehelper	Created a new configuration delegate with name = UserEventAgent, bundleID = com.apple.UserEventAgent, applicationID = (null), entitled = 0, hasProviderPermission = 0
default	2024-10-30 20:16:41.887721 -0400	nehelper	UUID cache miss for com.google.Chrome
default	2024-10-30 20:16:41.891391 -0400	nehelper	Caching 2 UUID(s) for com.google.Chrome
default	2024-10-30 20:16:41.893208 -0400	nehelper	Setting UUID cache generation to 10
info	2024-10-30 20:16:41.893322 -0400	nehelper	Received UUID 4C4C4406-5555-3144-A10C-9D0AE092D97B for com.google.Chrome does not match cached UUIDs (
    "4C4C4452-5555-3144-A185-4A3C256ECB3F",
    "4C4C4456-5555-3144-A146-5E13773D7A6A"
)
info	2024-10-30 20:16:41.894596 -0400	nehelper	Path /private/var/folders/16/cbw50jv1521dgpjk_503fpm00000gn/X/com.google.Chrome.code_sign_clone/code_sign_clone.wP9ioe/Google Chrome.app/Contents/MacOS/Google Chrome for PID 665 does not match generic UUIDs, allowing creation of a new rule
info	2024-10-30 20:16:41.894602 -0400	nehelper	Found new path /private/var/folders/16/cbw50jv1521dgpjk_503fpm00000gn/X/com.google.Chrome.code_sign_clone/code_sign_clone.wP9ioe/Google Chrome.app/Contents/MacOS/Google Chrome for PID 665, allowing a new prompt
info	2024-10-30 20:16:41.897430 -0400	nehelper	Showing local network alert for com.google.Chrome even though not in the foreground
info	2024-10-30 20:16:41.897433 -0400	nehelper	Local network preference not yet set, prompting for Google Chrome (com.google.Chrome)

4C4C4406-5555-3144-A10C-9D0AE092D97B is the UUID from the executable of the running copy of Chrome. That is 130.0.6723.70. The UUIDs that nehelper is aware of for Chrome (4C4C4452-5555-3144-A185-4A3C256ECB3F and 4C4C4456-5555-3144-A146-5E13773D7A6A) are from 130.0.6723.91. That's a newer version, and so is presumably the update that was recently staged on disk. This seems to confirm my hypothesis that staged updates are a factor in seeing this alert.

The remaining detail that the logs do not reveal is what Chrome did that triggered the local network alert.

Clay, if you're able to capture logs from the same time window but focused on mDNSResponder that will be incredibly helpful:

log collect --start '2024-10-30 20:13:00' --predicate 'process = "mDNSResponder"'

Reopening and assigning to myself while we track down what is continuing to trigger this.

I've marked the system logs that folks have attached as restricted since they may contain PII.

Compressed log archive attached. Generated with this:

❯ log collect --start '2024-10-30 20:10:00' --predicate 'process = "mDNSResponder"' --output mdnsrepsonder.logarchive
Archive successfully written to mdnsrepsonder.logarchive

Related, this technote was finally published: https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy

Hi lauri.pekonen@,

Thanks for sharing.

I got this prompt several times, answered yes, until I tried answering no. Then I noticed my Chromecast is not working anymore

The permission needs to be enabled to use cast in chrome. But the prompt should show up only once for each application. Tracking Bug 376743512

Also, in Privacy & Security - Local Network settings I have seven instances of "Google Chrome" and the amount keeps increasing. Wonder if every time the dialog pops up, it increases an entry there.

I filed another bug to track the issue about multiple instances of "Google Chrome" in the settings page: Bug 376742636

I looked over Clay's log this morning. One thing that stood out to me is there is no mention of mDNS service discovery (i.e, DNSServiceBrowse) prior to the local network prompt being displayed. If I trigger Cast manually I see mDNSResponder log messages related to DNSServiceBrowse. The absence of those messages in Clay's logs suggests something other than Cast is tripping it.

The technote indicates that virtually any access to the local network can trigger the prompt. Clay, were you accessing any servers on your local network? If so, that would explain why the prompt was triggered. We'd still be left with the problem that macOS is showing the prompt repeatedly. That appears to be due to macOS failing to associate the local network access permission with Chrome across Chrome updates.

I've figured out why this prompt is sometimes attributed to the GPU process, such as in comment #22.

The network service runs within "Google Chrome Helper.app", which has a bundle ID of com.google.Chrome.helper. The GPU process is "Google Chrome Helper (GPU).app", which has a bundle ID of… com.google.Chrome.helper. The duplicate bundle ID is intentional due to the macOS graphics stack hard-coding some behavior for com.google.Chrome.helper (https://crrev.com/c/1721830)

It seems that somewhere in the pipeline for the local alert prompting, macOS loses track of the "responsible process" for the process that triggered the prompt. The prompt should refer to Google Chrome since that is the "responsible process" for all of the helper processes. It's the only user-visible process, after all. The local alert prompting then resorts to looking for information about the process by bundle ID.

I'm not clear why a) macOS loses track of which process is "responsible", b) why it resorts to searching by bundle ID rather than retrieving the path of the process.

Clay, were you accessing any servers on your local network?

Ah! I looked through all my open windows and there was one lingering in the back connecting directly via IP address to a pihole on my local network. So this probably is the trigger.

That's great information.

I have been able to reproduce this on a work Mac running macOS 15.1 by leaving a build of Canary running overnight, with the only tab open being to a non-existent https://foo.local hostname. I've enabled Chrome network logging in hopes that I can correlate between the system logs when the prompt appears and Chrome's network logs to determine what action is triggering the prompt. My guess is a network reachability change notification is resulting in Chrome retrying the hostname lookup, and since a Chrome update has been staged it results in the prompt thinking it has never seen Chrome Canary before. If this is reproducible it should make it easy for Apple to improve the repeated prompt situation.

https://crbug.com/376743512 is tracking the fact that macOS is showing the prompt repeatedly for the same application. That will likely result in a bug report being filed with Apple since they're entirely in control of the prompting.

Has anyone seen multiple prompts for Chrome after updating to macOS 15.1? The technote mentions that macOS 15.1 fixes some bugs related to local network privacy, but it doesn't provide any details about what was fixed. The macOS release notes it links to for more information doesn't appear to mention local network privacy at all.

I saw the prompt once for Canary after updating to macOS 15.1 last week but have not seen it since. It's not clear to me whether the repeated prompting was fixed in macOS 15.1 or if I'm not doing the right things to trigger it. I can't rule out the latter because I'm still not clear exactly what I did to trigger it.

I’ve been seeing the prompt on canary every day or two, even since updating to macOS 15.1 a week ago.

I have filed feedback reports with Apple about the repeated prompting and the network access being attributed to one of Chrome's helper processes rather than Chrome itself. I've also requested that they emit a log entry when displaying these prompts that contains information a developer can use to understand the reason for the prompt. As it stands it is hard to tell which process is triggering the prompt, let alone what action it performed that triggered the prompt.

I saw two prompts today. Feels like it appears when I try to access a website that I didn't visit recently. But not all such cases would trigger.

Saw this today shortly after logging onto my MacBook Pro laptop (Apple M1 Pro, 14-inch, 2021). I upgraded to Sequoia (15.1.1) yesterday. I am on Chrome Version 131.0.6778.109 (Official Build) (arm64). I don't believe I am screen casting to any devices. I do have lots of tabs open.

http://screen/4rny9ifoEbyPgjC

Hi roydenluckey@, could you go to chrome://media-router-internals and check if you can find similar logs under the "Logs" tab?

The permission prompt should only show up when you open up the Cast dialog or the Global Media Controls dialog

In my case I don't see mDNS discovery started, instead I see quite a few Network ID changed entries.

Saw this today. I just upgraded to Sequoia. When Chrome automatically relaunched upon logging in, restoring my session with lots of open tabs, I was immediately provided with this permission request. I clicked allow.

Here are my chrome://media-router-internals logs: https://screenshot.googleplex.com/BfYdHCUYKCS3fZu

I'm not sure if it matters but one of my background tabs is YouTube. By background, I mean it's an open tab but it's not the foreground tab in the browser window it's in.

Chrome version 131.0.6778.110

It's possible that the prompt is triggered by Chrome's network interface change notification / interface enumeration code. I don't think enumerating loopback should be sufficient to trigger the prompt, so if there is a repro case it would be worth filing another FB (IMO).

I think that sounds like a plausible cause. It happened again to me today. I opened my laptop in the office in the afternoon (after using it earlier in the day also in the office) and I was greeted again with the same "Allow "Google Chrome" to find device on local networks?" prompt. The only thing that happened between not seeing the prompt is putting my laptop to sleep, walking to a different floor in the building, opening the laptop, and unlocking it.

This prompt is also surprising because I would've thought that once I answered it as "Allow" the first time it wouldn't appear again. Maybe I'm misunderstanding how long the "allow" lasts.

Here is a link to chrome://media-router-internals output: https://drive.google.com/file/d/1Hr6UAt7b9RzjPdywJ7EbtzYmOIIO0D1l/view?usp=sharing

I closed my laptop around 2pm (Pacific) and then opened it again around 3:30pm (Pacific) and saw the message.

This prompt is also surprising because I would've thought that once I answered it as "Allow" the first time it wouldn't appear again.

As a side note, this specific issue is a macOS bug that we reported to Apple as FB15683070. The “local networks” TCC dialog seems to track Chrome app identity in a way unlike every other TCC dialog, and that specific method causes it to lose track of the approval that users have given. Apple is working on it.

mpearson@, could you help generate a mac sysdiagnose? I can send it to Apple engineers who work on the Local Network permission to figure out which part of chrome triggers the permission. The generated file should be huge, so it might be better to email it to me.

chris.keller@, I'm sorry to hear that you're not able to discover Chromecast devices from Chrome. The issue about multiple Chrome instances in the Local Network settings page is an issue with macOS, as is mentioned in #56. Apple's working on it.

It's possible that the prompt is triggered by Chrome's network interface change notification / interface enumeration code

Chrome tries to reconnect to previously discovered devices on network change (code). If the permission grant is not sticky (i.e. users have reported seeing multiple permission prompts), reconnecting to the device triggers a permission prompt. However, I haven't figured out if network changes alone (when chrome hasn't discovered any devices) can trigger a permission prompt.

I have 5 entries for Chrome in System Settings -> Privacy & Security -> Local Network (see screenshot). This is presumably the same bug as the bug here?

I have 5 entries for Chrome in System Settings -> Privacy & Security -> Local Network (see screenshot). This is presumably the same bug as the bug here?

Nope, that one is bug 376742636.