EDIT
TO EVERYONE ASKING TO OPEN AN ISSUE ON GITHUB, IT HAS BEEN OPEN SINCE JULY 6: https://github.com/LemmyNet/lemmy/issues/3504
June 24 - https://github.com/LemmyNet/lemmy/issues/3236
TO EVERYONE SAYING THAT THIS IS NOT A CONCERN: Everybody has different laws in their countries (in other words, not everyone is American), and whether or not an admin is liable for such content residing in their servers without their knowledge, don’t you think it’s still an issue anyway? Are you not bothered by the fact that somebody could be sharing illegal images from your server without you ever knowing? Is that okay with you? OR are you only saying this because you’re NOT an admin? Different admins have already responded in the comments and have suggested ways to solve the problem because they are genuinely concerned about this problem as much as I am. Thank you to all the hard working admins. I appreciate and love you all.
ORIGINAL POST
cross-posted from: https://lemmy.ca/post/4273025
You can upload images to a Lemmy instance without anyone knowing that the image is there if the admins are not regularly checking their pictrs database.
To do this, you create a post on any Lemmy instance, upload an image, and never click the “Create” button. The post is never created but the image is uploaded. Because the post isn’t created, nobody knows that the image is uploaded.
You can also go to any post, upload a picture in the comment, copy the URL and never post the comment. You can also upload an image as your avatar or banner and just close the tab. The image will still reside in the server.
You can (possibly) do the same with community icons and banners.
Why does this matter?
Because anyone can upload illegal images without the admin knowing and the admin will be liable for it. With everything that has been going on lately, I wanted to remind all of you about this. Don’t think that disabling cache is enough. Bad actors can secretly stash illegal images on your Lemmy instance if you aren’t checking!
These bad actors can then share these links around and you would never know! They can report it to the FBI and if you haven’t taken it down (because you did not know) for a certain period, say goodbye to your instance and see you in court.
Only your backend admins who have access to the database (or object storage or whatever) can check this, meaning non-backend admins and moderators WILL NOT BE ABLE TO MONITOR THESE, and regular users WILL NOT BE ABLE TO REPORT THESE.
Aren’t these images deleted if they aren’t used for the post/comment/banner/avatar/icon?
NOPE! The image actually stays uploaded! Lemmy doesn’t check if the images are used! Try it out yourself. Just make sure to copy the link by copying the link text or copying it by clicking the image then “copy image link”.
How come this hasn’t been addressed before?
I don’t know. I am fairly certain that this has been brought up before. Nobody paid attention but I’m bringing it up again after all the shit that happened in the past week. I can’t even find it on the GitHub issue tracker.
I’m an instance administrator, what the fuck do I do?
Check your pictrs images (good luck) or nuke it. Disable pictrs, restrict sign ups, or watch your database like a hawk. You can also delete your instance.
Good luck.
seems like the solution to this should be to automatically remove images that haven’t been posted, after like 3 minutes
deleted by creator
The 3 minutes would only kick in if an image was uploaded but then never posted. So nobody would see it anyway in any case.
This route would avoid the issue but also help save on space too.
What happens if user spends over 3 minutes to write the post after uploading image?
Would user create a post with broken image link? or would there be some kind of “call home” API call on create post page so image wouldn’t be removed? (which has risk that API call could be replicated by a bot)
That is a good point. Could potentially not upload the image until the post is created instead of at image choosing, which would also alleviate the issue. But I’m not sure how that would work across web and mobile clients.
I think that’s the best solution. I can’t see a reason any client couldn’t upload the image when the post is submitted. Currently the uploader is some fancy javascript deal and it’s unnecessary.
deleted by creator
Write the post and then upload the image?
This could be handled by the client. Get the Ruleset for image uploads (max size, format, etc.), Validate the image within the client, only upload when the post is published.
Then the delay between post and image only depends on your internet connection and the user can still take 3 hours to write a post.
Could allow for like one hour of keep-alive pings before it’s deleted and the client is told to notify the user of this
Also: rate limits that gradually increase are good.
The solution is to base it upon the user session timer.
As in when you’d normally get automatically logged out? If so, I’m not sure that would work since Lemmy uses JWTs that don’t expire (or if they do, not for a very long time) it seems.
Or make it like 1hr and don’t let the user know the url of the uploaded image until they post it, that way it wouldn’t be able to be shared or reported.
It’s difficult to display an image without the client knowing the URL, but it would be possible to use a temporary URL that only works for that signed-in user.
Store the image in memory, or in browser cache.
This is one way to solve it.
3 minutes is way too short. You could upload and it be gone by the time you post.
Or just mark the resource as private and only serve it to the user who created it until they associate a post with it.
You would probably need a separate server to stage images like this, as your main image server probably shouldn’t have a login wall, which probably slightly complicates things but not badly.
Or you set a flag that says something like “incomplete image” and then only once user completes whatever operation by hitting “submit” do you then set it to complete.
And maybe while an image is not yet complete, only the uploading user can view the image.