A recent post at Lemmy.ml pointed out that images are loaded directly by Lemmy clients, and aren’t proxied through any instances.
This has some implications for targeted advertising and tracking. For example, if I ran an ad network, I could post a benign-looking comment that has a tracking pixel embedded as an image. Say I posted one on a Lemmy post about cooking: when a user scrolls near that comment, the image would get loaded and I would be given an association between an IP address and device type → some interest. If not many people use that IP and device type tuple, I could determine that you were interested in cooking and try to serve you ads for kitchenware.
Adding the option to specify the HTTP user agent when viewing images (or better yet, randomize it between a bunch of valid ones) would be a nice option for privacy-conscious users who don’t want advertisers (or websites collecting HTTP request data to sell to advertisers) to be able to build profiles on them.
If you wanted to add extra value to Sync Ultra, you could even offer image proxying as one of its features :)
Edit: According to this comment, the regular Lemmy website will load embeds for direct messages. If that’s also true for Sync, it means someone could find your IP address by just sending you a message with an embed. That has some even bigger privacy implications.
Edit: Sync doesn’t embed the image, but it loads it to display a thumbnail:
i don’t think this needs to be a sync feature, but a lemmy one.
Ideally, yeah.
I’m not confident that instances would actually enable image proxying, though. The bandwidth for that costs money, and instances don’t necessarily have a consistent revenue stream that would make it feasible to run a proxy in addition to hosting the instance itself.
With Sync Ultra being a subscription, I think it would be more viable for lj to maintain an image proxy for Ultra subscribers. And if Lemmy ever adds image proxying itself, the instance proxies could be used where available instead.
I don’t think this would do very much for your privacy.
For spoofing a user agent: The server could easily get your ip address which likely says more about you than a user agent. The user agent says almost nothing about you: just the name of the client doing the request.
For proxying image requests, you could gain something similar by using a VPN. It all comes down to trust. If you trust the end instances at the start, you don’t need to proxy requests, if you trust a vpn you can do that instead as a trust barrier. Sync being a proxy doesn’t make sense to me and could cost a lot to do properly with low latency, etc.
That’s just my thoughts, not that of the ljdawson.
For spoofing the user agent, I still think that some level of obscurity could help. The IP address is the most important part, but when sharing an internet connection with multiple people, knowing which type/version of device would help disambiguate between people with that IP (for example, a house with an Android user and an iPhone user). I wouldn’t say not having the feature is a deal breaker, but I feel like any step towards making it harder to serve targeted ads is a good step.
Fair point on just using a regular VPN, but I’m hoping for something a bit more granular. It’s not that all traffic would need to be proxied, though. If I use some specific Lemmy instance or click on an image/link, that was my choice to trust those websites. The concern here is that simply scrolling past an embedded image will make a request to some third-party website that I don’t trust.
Maybe put it on the github tracker as a feature request so you can be certain to get a reply?
https://github.com/laurencedawson/sync-for-lemmy/issues/new/choose
deleted by creator
The image needs to have already been downloaded the moment the client even fetches it, or you can use the image to track of a particular user is online/has read the message.
Oh wow… That’s an excellent point. And even if the client downloads it the moment it fetches the message, that would still be enough to help determine when somebody is using Lemmy. I don’t think advertisers would have a reason to do that1, but I wouldn’t put it past a malicious individual to use it to create a schedule of when somebody else is active.
1 It’s probably easier for them to host their own instance and track the timestamp of when somebody likes/dislikes comments and posts since that data is shared through federation.
This needs to be implemented in the backend. Images already get downloaded to and served from the server’s pictr-rs store in some instances, so there’s code to handle this problem already.
That would be ideal, I agree. This comment on the GitHub issue explains why some instances would want the ability to disable it, though. If it does eventually get implemented, having Sync as a fallback for instances where media proxying is disabled would be a major benefit for us Sync users.
A small side note: that comment also points out a risk of a media proxy running the risk of downloading illegal media. I don’t necessarily think lj would need to worry about it in the same way, though. From my understanding, the risk with that is that an instance would download the media immediately after receiving a local or federated post pointing it. An on-demand proxy would (hopefully) not run the same risk since it would require action (or really bad timing) on the part of a user.
On the other hand, such a system would also pose a privacy problem: suppose someone foolishly believes Lemmy’s messaging feature is secure and sends a message with personal pictures (nudes, medical documents, whatever). Copying that data around to other servers probably isn’t what you want.
Fair, but it’s a bit of a moot point. Sending the message between instances is already copying that data around, and even if it’s between two users of a single instance, it’s not end-to-end encrypted. Instance admins can see absolutely everything their users do.
Orbot can do per-app VPNs for free if you’re willing to take the latency hit.
Interesting! I wasn’t aware that there were any Android VPNs capable of doing per-app tunneling.
