Openverse integration: sideload images when inserted

[jeherve]

What problem does this address?

The Openverse integration is a great way to streamline one's publishing process.

However, at the moment it "only" hotlinks the images from their source. While that works for now, it means that you may find yourself with broken images on your site if the original site were to go down, or if the original image were removed.

What is your proposed solution?

I would suggest uploading the image to one's site once picked and inserted. This way it would remain available on the site, whatever may happen to the service or the original image.
Of course, the image attribution should remain in the caption.

[johnstonphilip]

Should this also be considered from a privacy and GDPR standpoint? When an image is hotlinked, it can allow the real host to gather data about the device loading the image.

Here's a snippet from the Office of the Privacy Commissioner of Canada.
https://www.priv.gc.ca/en/privacy-topics/technology/online-privacy-tracking-cookies/cookies/02_05_d_49/

Cookie-Less Tracking
A person’s browsing habits can also be tracked without cookies. One such method involves “web bugs”, which are small, invisible image files placed on a web page or hidden in an e-mail message. When you view the page or message, the image is downloaded from a server that can keep detailed logs. These logs record such information as your location, Internet address, the page or message you are reading, and the current date and time.

If WordPress encourages users to add images they do not self-host, perhaps it should also help them understand that they should add something to their Privacy Policy about that.

[pbiron]

@johnstonphilip mentioned this in Slack. I pointed out that once Openverse images are inserted into a post, they can then be added to the Media Library (with their use in that post modified to use the Media Library version).

Phil suggested that that be the default. I have no opinion one way or the other, I'm just relaying that discussion here.

[cbirdsong]

There's a related issue here:

• Copy external images to the media library when pasting content. #2515

[shawfactor]

Not sure if I should add my thoughts to this ticket or a separate one.

But I am deeply uncomfortable with any integration of openverse into core. Philosophically Wordpress is a personal publishing platform so it should be avoiding external apis and dependencies. The only external calls it should make (by default) is to check for updates

No issue with the service itself though (I like it) but it should be a canonical plugin that site owners consciously install.

Either way images must be on the local server though.

[tomjn]

I can see this becoming an issue for anybody who tries to copy the Openverse integration to build their own media provider, as well as:

• anybody who needs control over media URLs
• developers who needs local offline instances
• anybody concerned about data firehoses linked to the .org infrastructure
• site migrations
• users who want to crop, rotate, filter the openverse images in their content
• legal compliance issues

This should be resolved before this functionality is included in WordPress v6.2

[tomjn]

Also noting that #46014 is not a solution to this problem

[Luehrsen]

I would consider shipping the openverse integration without sideloading a breaking change for every jurisdiction, where privacy laws and GDPR exists.

Having a default WordPress feature built into the backend, that in no shape or form indicates that user information get leaked to unknowable third party servers will result in lawsuits. This is the same territory as the Google Fonts in core themes, which cost a lot of people a lot of money. But this time it's a new feature.

So please, please to not implement openverse as it currently stands (with hotlinking) in 6.2! Sideloading images would fix the privacy issue.

[jdevalk]

I concur with @Luehrsen. This cannot ship this way, or it will get unknowing users sued. Next to that it has negative performance implications, as you can't do srcset or loading attributes on images loaded from remote. Sideload really should be the default, and in fact IMHO, only way.

[jonoalderson]

Agreed. This can't ship as-is. The performance degradation will be appalling, and this is a huge step backwards in the work that's been done to reduce external (IP leaking) requests.

[johnstonphilip]

I see most of the Openverse work was done by @ntsekouras. Would you be able to take a look at this issue?

[ntsekouras]

👋 I'll take a look at this first thing tomorrow morning!

[ntsekouras]

I opened a quick PR: #48501.

Some more changes will be required in that PR, but wanted to open it to get some early feedback about the handling of images that cannot be upload due to CORS issues - in case we can land this in time for beta 4 tomorrow.

[jdevalk]

Thanks for the quick work @ntsekouras! This looks like a huge improvement over the current practice.

[mtias]

Thanks for testing and raising the issue! We definitely want to upload to the site library for this flow and should treat this as a bug. There's work going on in parallel to upload by default on other actions (like pasting) that are not as straightforward or general enough (hence the need for something like #46014) but this one should be straightforward.

I really appreciate the quick PR to address it @ntsekouras.

[Luehrsen]

Thank you for acting so swiftly @ntsekouras! Really appreciate that!