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.
The problem with a common UA string is that you would know the request came from someone browsing Lemmy with Sync. Ideally, media requests to any third party should be indistinguishable from a regular web browser. As for empty strings: in my experience, some websites block requests with an empty or missing User-Agent header.
I still think the best approach would be to let the user pick a UA. Having a list of common browser/device pairs that update the version numbers automatically would probably be a good idea, though.