Images are always served from the local machine because they are cached. When it was created by a remote user then you have got the possibility to block that user.

What is the legal position if you end up unintentionally hosting criminal content in a P2P system? I know Section 230 provisions or equivalent apply to the likes of defamation on a web platform, but what if it is distributing content that it's a *crime* to possess. I'm concerned the law might not be reasonable on this point as well.

Let me try to answer you.

Someone on your server interacted with an account on pawoo.net, whether by following this account, or fetching a public post (by entering its URL in the search bar) or subscribing to a hashtag if you have configured your node to accept content from post relays (although it appears unlikely).

pawoo.net then sends this post including a link to an image hosted on pawoo.net to your node. To protect your user's privacy, your node will download the image locally and rewrite the URL in the post to point at its location on your node.

So you are right, your node will be publishing this image from your domain until you take a moderation action against the post itself, the remote account (node-wide account blocking includes an option to delete all the content) or the remote server (node-wide server blocking includes an option to delete all the remote accounts and their content.

This local copy is meant to protect your user's privacy, but unfortunately it can't be limited to users at it stands. Since the same exact process is used to publish your user's own pictures in their public posts, making it logged-in user only would prevent their public posts to show their images to non-logged users. Think about RSS users or simply their public profile page.

Now, as Michael mentioned, there are ways of limiting the risks for you as a website publisher. Moderation is the main point (and the URL of the picture you mentioned now returns "Not Found") but as you said it is a game of whack-a-mole. It is made easier by domain blocking but there will be an amount of time during which questionable content will be published by your node.

Making the community pages (either from your local users or the global network your node knows about) private to your users only is another way of limiting exposure, as only your users will be able to be exposed to this kind of content through images your node is publishing. But then they would be able to share the image URL publicly for anyone else to see.

Currently images know whether they should be served to anyone or just to your users based on the permissions of the posts their are embedded in but I guess we could improve this system to take the site setting to make the community page private into account. This would further reduce the risk for you as even if one of your users shared the URL of such a picture with a non-logged in user they wouldn't be able to access it.

There seems to be a technical misunderstanding. Cookies are arbitrary data set by a website on a user's browser for ulterior retrieval. Authentication cookies are typically used to persist a successful login on a given website for a given period of time. Server to server communication do not use cookies and cannot set cookies in any user's browser.

We do have a mechanism to authenticate a Friendica user on a remote node, but it involves several requests back and forth between the two nodes so it isn't really suited to authenticate image display.

@Matthew Exon@Hypolite Petovan

Surely an interim solution would be to serve local users from the cache, but serve the original URL to everyone else?

Also, i'd like to change my vote for code change priorities.

Id like to see this fixed before anything else

It is possible, but this would require to alter a post content depending on the authentication status and this would yield a significant performance hit for all post display operations.

A less costly solution would be to redirect anonymous users to the original URL but the image URL with your domain would still be visible in the source of the post page, I don't know how tech-savvy are your roving pedo hunter gangs.

@Hypolite Petovan@Matthew Exon I can't imagine "if local user, serve cache URL, else serve original URL" should have a huge performance hit.

Likewise, when serving from the cache, only serve if local user.

Or is it impossible for the server to tell the difference between a cached image and a legitimate image belonging to a local user?

@Matthew Exon@Hypolite Petovan Indeed

The devil is in the details. Computing a post display from a raw post body is a costly operation; we need to convert Markdown/BBCode tags to HTML, resolve mentions, rewrite image URLs... so we only do it once and store the result that we use for everybody, logged or not. Discriminating between logged in and anonymous users would require us to perform the same operation twice, store the result in parallel, and pick the correct version when building a page. This is possible, but not insignificant for overall performance.

Or is it impossible for the server to tell the difference between a cached image and a legitimate image belonging to a local user?

It is possible, it would be part of the solution I suggested earlier, it just hasn't been implemented yet.

@Hypolite Petovan@Matthew Exon ah, you did say that above, my bad.

So can we have a "remote" flag or something attached to an image, which is set for images that are cached for local users, and is unset, should a local user actually make a post with that image?

That wouldn't prevent anyone seeing it if a user shared the image, but at least from a legal point of view, it's more clearly their fault, and easy for me to fix (by booting them)

Yes, the flag would work in conjunction with the setting for hiding the global community page from anonymous users. If the page is hidden, the image URL wouldn't work for anonymous users, and if the page is shown, the image URL would work for everybody.

@Hypolite Petovan@Matthew Exon that would be a huge improvement, imo.

Certainly good enough for now.

@Matthew Exon@Hypolite Petovan

the pedo hunters are, frankly, blithering idiots, and they aren't above planting evidence (this has ruined many police investigations).


There are definitely people who will sell them tools to do this.

So this is a very real threat imo.

What does "bulletproof server" means?

Got it. I'll explore the feasibility of both solutions (redirect and settings-based) this week.

@Matthew Exon@Hypolite Petovan I wouldn't have worried if not for actually seeing a post in the wild which directly referenced those URLs.

The people who share that kind of stuff will also share URLs out-of-band, so this is already a real world attack, rather than theoretical.

Really pleased to see this is high on @Hypolite Petovan 's priorities, that's all anyone can ask for :)

Thank you for the elaboration, I want to take roving gangs of pedo hunters seriously.

What tickles me in this issue is that image caching is supposed to be an asset, not a liability. It would be simpler for us to keep the original image URLs but we added this processing to protect Friendica users' privacy. This side-effect of changing the ownership of questionable material is typical of a feature which was only considered from one angle. and I'd like to correct the record.

What do you mean by "delegating to the proxy"?

How would this look for embedded images?

Then what’s the situation where we get to rewrite the image link but not the displayed link?