Umm why does infosec.place "access my device"?

/cc @jerry

@buherator that is a fine question. I will have to check why

@buherator did it just start doing that?

@jerry Original timestamp of the image:

Wed Sep 23 09:14:13 PM CEST 2026

It's the first time I see such request ever (not just here).

@buherator thanks - what browser is that? I am trying to replicate it.

@jerry FF

@buherator if you scroll back to where you were last night (if you know where that was), do you get another pop-up like that? I am wondering if it;s some sort of xss in a post that akkoma isn't handling.

@jerry It *is* timeline dependent! I had to scroll back more than a day (I stupidly overwritten the original screenshot with the crop, but the timestamp helped).

So far I could get this out from some vibe coded event handler in dev tools:

"Local Network Access permission required: top-level site “https://infosec.place/”, initiator “https://infosec.place/”, attempting to access target “http://localhost:3000/assets/images/og-card.png” (127.0.0.1:3000) via http. Secure context: True"

@buherator oh interesting. Something is borked. That is very very interesting. if you have any ability to play with it to narrow down which posts it might be, I (and other akkoma users) would be grateful

@jerry I came here to drink wine and scroll, and I'm just out of wine!

@buherator @jerry i found it. :) Its the web url trying to access the apps to find if you have the mastodon app and then try and trigger to open it. :-) Had me curious too :D :D

Nothing too bad.

@jerry Based on this article and the previous error I assume this permission request is not coming from JS but someone trying to make me fetch an URL from localhost which now triggers additional warnings:

https://support.mozilla.org/en-US/kb/control-personal-device-local-network-permissions-firefox

At this point I'm not sure if it should be illegal for posts to contain references to localhost.

@dey @jerry More details pls, who is trying to figure out if I have SW X installed and how?

@buherator @jerry So you know how certain sites have their web app for mobile devices too. Usually facebook or instagram they want to switch to the app. In this case Mastodon is trying to see if the app is installed in the computer (in case of MAC even windows) or the phone. Its not specific to infosec.place (or maybe it is I am not on that instance)

@dey @jerry But I'm not using Mastodon, this is an Akkoma instance. And this only happens if I scroll back to the point in my timeline when I first got this notif. It'd be really weird if this behavior didn't trigger at around page load.

@dey @buherator I also think this is happening due to another instance referencing an in image embed with that URL, and akkoma is passing it on to the web browser to try to fetch, which is causing the issue. That http://localhost:3000, btw, is the default port that the mastodon app server works from. 99.5% this is a badly configured mastodon instance + some issue with akkoma.

@buherator @dey it's giving you that address to fetch like any other image that appears in your timeline. localhost links shouldn't be sent and I need to figure out if akkoma has a way to prevent that.

Akkoma rewrites remote media through your server only when `:media_proxy, enabled: true` is set (docs.akkoma.dev howto_mediaproxy). Off, every <img> src in remote content goes to the browser verbatim - http://localhost:3000 resolves against the viewer's loopback, not your server. Caveat: `redirect_on_failure: true` 302s the client back to the origin URL when the proxy fetch fails, which is the same leak. Worth checking whether the URL is an attachment or an inline <img>

@sclaw I did not set up the proxy. I do think that might solve it. it would just present a broken image, I suspect, in this instance.

@jerry @dey @buherator i've been seeing this popup too - not on here, but elsewhere, which tells me if i went to go to inspector, i would also probably see some kinda 'call to localhost', which firefox is now throwing alerts for.

iiiiiiinteresting

@jerry @dey I can see the Initiator is an img, but I can't find anything seemingly related in inspector + network rectord don't tell me what code initiated a request. That's the status.

@buherator @dey there's no code, it's just in the body. I am working on setting up the proxy which will hopefully fix that

@jerry @dey I count HTML as code...

@buherator @dey fair. after far too many typos, the local media proxy is up and running, so with any luck, you won't see that any more.

@jerry @buherator wow you are good at computer have you considered doing it professionally?

@dey @buherator See, if I were good at computers this wouldn't have been an issue. I think i should have set up the media proxy from the start, but I was cheap and trying to save bandwidth

Right — the proxy fetches server-side, so localhost:3000 resolves against your Akkoma host, not the origin. Nothing listening there → connection refused → 404/broken image, as you expect. Worth enabling anyway: it stops remote content from making each viewer's browser request *its own* loopback. An <img src=http://localhost:3000> in a post is a port/service probe against the reader. Set redirect_on_failure: false so a failed fetch stays a 404 instead of 302-ing the original URL back to the client.

@sclaw exactly.

@jerry You are the Man, thanks! @dey

Re: this one I'm still curious how I could tell which document node triggered a network event (denied, with an img Initiator) I see in dev tools. I can't find the corresponding URL by searching in Inspector, DeepSeek hallucinates all the solutions, maybe @freddy has a tip?

#Firefox

RE: https://infosec.place/objects/c55e1bcb-86a9-4d16-b9fb-83dccaeb4dad

@buherator @freddy To install backdoors? Duh.

@buherator can you (privately) share what devtools is logging? Is this reproducible?

@freddy This is what I believe a native FF log message resulting from an attempt to load from localhost:

"Local Network Access permission required: top-level site “https://infosec.place/”, initiator “https://infosec.place/”, attempting to access target “http://localhost:3000/assets/images/og-card.png” (127.0.0.1:3000) via http. Secure context: True"

I could reproduce it by scrolling a shit ton in my timeline (won't do again), but I think a minimal test case would be a simple `img src="http://localhost...` served from a non-local origin.

In that case though the source would be there in Inspector, but in case of Akkoma infinite scroll does some magic that prevents me from simply looking up the tag by URL, that's why I'm thinking if some kind of "stack trace" is available for network events that would lead me to the offending element?

@buherator og-card in the URL? looks pretty much like you're black holing some social networking to 127.0.0.1 and therefore blocking some preview image

@buherator You could also log to a file with about:logging (select "Network") or use the Firefox Profiler (https://profiler.firefox.com/). - All of this will stay local, unless you share the log / profile (May contain cookies and other substances)

@freddy Interesting theory! I do blackhole some sites but I doubt any URL of those would point to :3000...

@buherator Huh....now I _really_ want to see a log file. :) You should try to find the toot that caused this first.

@freddy Not sure I'll be able to have the original trigger now that a media proxy got introduced (don't know if it works retroactively).

But I have an idea for a repro, adding then deleting an <img> to the document. I guess what makes debugging this difficult is that you need a point-in-time document snapshot to see the true source. Even seeing the <img> may not be meaningful without e.g. it's surrounding <div> with the post content.