I’d wager that it’s probably not that hard to obtain a lemmy user’s IP address, whether the admin hands it over or not.

Lemmy permits – arguably not the greatest design decision from a privacy standpoint – for inline remote images in comments. E.g.:

![](https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png)

Yields:

As soon as that image is loaded, the remote http server knows the IP address of the client viewing the image.

I bet that it does in private messages too, though I haven’t tested it. Send a private message to a user, referencing an image on a server you control – maybe even a one-pixel, transparent image, a tactic that has been used in Web tracking in the past – and the server knows their IP when the image is viewed. Even if it doesn’t, you could probably just respond to a few comments by a user in regular threads, and they’re probably going to be the first to view the image (and probably the only to view all of them).

EDIT 2024-04-11: It looks like there’s at least one lemmy instance that’s running a caching image proxy and rewriting comments and posts specifically aimed at closing this hole (and has been doing so for some months before I made this comment):

https://lemmy.kya.moe/post/521258

I’m guessing, though I’m not familiar with the instance and it has no local communities, that it probably focuses on underage anime porn; based on instance hostnames I’ve seen in the past, I believe that the .moe TLD is something of a convention in that community, so I assume they’re probably worried about legal repercussions for people in some jurisdictions where viewing it it’s illegal; they probably have a strong incentive to have this function correctly. That doesn’t mean that they’ve actually implemented it correctly, mind. I don’t know if any image formats that the Threadiverse supports inline display of might permit for external references to be embedded in the image, to generate requests that bypass the proxy; it looks like on some browsers, SVG permits for this and is probably one thing I’d examine if I were auditing whatever their code is.

According to the post I linked to, they’re rewriting URLs to point at a local image proxy. It sounds like they’re just proxying the request and caching the image for short periods of time, not persistently mirroring the image, so they probably have bounded storage requirements unless someone specifically attempts to flood the instance. That being said, this could consume a lot of bandwidth.

It’s also possible that it might break images that are intended to be dynamic (though if their proxy is conformant to http proxy conventions, I believe that the original host provides a time-to-live with images, which I believe can request that the cache not retain the image).

They don’t list any technical details of what it is that they’re using, though, and I have no idea if it’s open-source or made available to other instances. Also, I have no idea what it would cost in terms of bandwidth to operate such a proxy. It could be pretty substantial.

While it doesn’t matter now, this approach might also run into problems down the line, if stuff like cryptographic signatures on comments ever become the norm on the Threadiverse, so that one can ensure that an instance isn’t modifying comments (since the instance relies upon doing exactly such a modification to make this work). But as things stand today, I’d imagine that it should reduce the number of parties who have access to an user’s IP address to the instance administrator.