Why does Atlassian want to access to other devices on my local network?

[Darryl Lee]

So CLOUD-12835 - Guidance for the local network access request for our Atlassian cloud explains:

Around Chrome v142, Google introduced a new Local Network Access (LNA) permissions model. The key ideas:

• Any page (or iframe) that talks to local / private IPs (e.g. localhost, 127.0.0.1, 192.168.x.x, corporate RFC1918 ranges, device UIs, etc.) is now gated by an explicit permission.

https://developer.chrome.com/blog/local-network-access

My users and I have seen this, I guess because at work we use the 10.0.0.0 space.

What I'm curious about is, what is Atlassian doing that is triggering this?

Yes, I suppose I could open a ticket, but maybe there's some networking experts out here? I'm also posting because as this version of Chrome starts rolling out more widely, I'm sure others may come across this issue.

[Arkadiusz Wroblewski]

Hello @Darryl Lee 

That prompt is super specific  and it’s easy to blame “we use 10.0.0.0 at work”, but that’s not what Chrome is reacting to.

Chrome’s LNA prompt fires when the page (or something embedded in it) tries to make a request to a private address: 10.x, 192.168.x, 172.16–31.x, or localhost. It’s not about your client IP being private, it’s about the destination of a fetch/XHR/img/iframe being private.

So the real question becomes: what on a Jira page would ever call a private IP? In my experience it’s usually one of these:

An embedded app iframe (Marketplace / Connect / Forge) calling back to an internal service (CMDB, internal API, proxy, etc.). The browser attributes the prompt to the top-level origin (*.atlassian.net), so it looks like “Atlassian wants LAN access” even though the call may be coming from an embedded app.

Smart Links / embedded content pointing to internal URLs. One internal wiki page, image, iframe, or link preview to http://10.x... can trigger it when Jira tries to render/preview.

Browser extensions that enhance Jira and talk to localhost/internal endpoints. Seen this more than once.

Fastest way to confirm: open DevTools -> Network, reload, and filter for 10. / 192.168 / 172.16 / localhost. The request and the Initiator will tell you immediately whether it’s core Jira, an embedded app, a Smart Link, or an extension.

Practical guidance I’d give users:

If you don’t rely on internal integrations from Jira, Block is fine, Jira keeps working.

If you do, figure out what is triggering it first, then you can make a conscious call whether Allow is needed for that specific integration.

If you can share what endpoint shows up in the Network tab (even just the private IP/host and the initiator), I’m pretty sure we can pinpoint the exact trigger quickly.

[Philipp Sendek]

Amazing answer! I'm looking forward to the reply what causes this in case I ever come across it.

[Arkadiusz Wroblewski]

@Philipp Sendek 

This topic is really interesting. Besides administering, developing internally, and migrating Atlassian products, I also work in IT infrastructure and support. It’s always great when you can combine knowledge across areas. And to be honest, administering and developing Atlassian tools internally is increasingly moving toward system engineering rather than ‘just’ administration.