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:
Screenshot of my inbox showing a thumbnail of the image

    • eth0p@iusearchlinux.fyiOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      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.