Drupal and the Missing Photographer

Photographs downloaded from Dutch museum and archive websites can lose the names of the people who made them. I found this while examining nine heritage institutions running Drupal. On the eight sites where I could inspect an image-style derivative, the maker and rights information were missing from the file, even when the credit appeared on the webpage.

Once someone downloads and shares that photograph, the credit on the original webpage no longer travels with it. But retaining every piece of image metadata creates another problem: a file can reveal information such as GPS coordinates or a camera's serial number. These questions led me to develop two Drupal modules. Embedded Attribution controls the metadata in the image copies a site publishes, while Content Credentials helps editors assess signed information about the media they upload.

What I found

Nearly every image I examined on those homepages was an image-style derivative: a smaller copy Drupal makes of the original. The default GD image toolkit discards metadata when it makes that copy. Switch to ImageMagick and it can retain much more, including the GPS position, the date and the serial number of the camera. Not so handy if the photo was made in someone's back garden.

I started this because I find it important that real media, made by people and not by AI, keeps its value, and that we may say so. So I wrote two modules. The first one is about the images a site publishes, the second about the files editors upload.

That matters beyond the website itself. A museum may carefully credit a photographer on its pages, but the image can travel much further. It can be downloaded, shared, included in a presentation or saved in somebody's collection. When the credit exists only on the webpage, it does not travel with the photograph.

These are two different problems: losing information that should stay, and keeping information that should not be published.

Embedded Attribution

Embedded Attribution puts the maker and the rights back into the image-style copies Drupal makes of a photo, together with the source and the licence link. Values already in the original take precedence. Where the original has none, the module takes them from fields you choose, such as a Photographer or Attribution field. Nothing from unpublished content ends up in a file.

Drupal already has ways to store this information. The Attribution & Licensing module, for example, lets a site manage creator and licence information in Drupal fields. Embedded Attribution does a different job. It writes that information into the image derivatives themselves, using established image metadata formats such as IPTC, XMP and EXIF. A site does not have to replace its existing attribution fields to use it.

For a photographer, this means the name can remain attached to a downloaded image. For a museum or archive, the source and licensing information can travel with a photograph instead of being available only on the collection page. For an editor, the information can come from fields already used in the publishing workflow.

The alt text goes in as well, as embedded accessibility metadata, so the description can travel with a download. It does not replace the alt attribute on the webpage, but it means the description is not necessarily lost when the file leaves Drupal.

The photo credit and licensing information can also be read by Google Images. Google's image metadata documentation explains how embedded IPTC fields can provide the creator, copyright notice, credit line and licence information. A suitable licence link can make an image eligible for the Licensable badge, although Google does not guarantee that it will display the information.

On the edit form, you can see what will end up in the files. Change a field, save, and Drupal makes the copies again with the new values. The module can also show what an existing derivative actually contains. That distinction is useful when editors need to check not just what Drupal stores, but what a visitor receives.

Everything else is removed by default, so with ImageMagick the GPS position, the camera information and the dates disappear. The module retains selected technical data, including the colour profile, because the colours depend on it. That profile can still contain identifying text, such as the name of a device or a copyright line. The attribution stays, and so does the AI label that AI Disclosure's image module puts into copies of AI images. The uploaded original is never touched. A photography site that wants to show camera data can switch off metadata removal on the settings page.

There is another part to this that matters to developers. Drupal does not always make an image derivative when someone requests it for the first time. A site may generate copies in advance, for example with Drush. The module has to handle those files as well as ordinary image requests, and it has to prevent a visitor from downloading a copy while metadata cleaning is still in progress.

In Embedded Attribution 1.0.0-alpha4, the derivative is cleaned before it is placed at its public path. This change also addressed a race condition in which a second request could reach an uncleaned file. In my ImageMagick test, I reproduced the problem in 200 out of 200 attempts before the change, and in none of 200 attempts afterwards. These are tests of the reported failure, not a guarantee about every hosting environment.

When a copy cannot be cleaned, the module does not serve that derivative. It logs the problem and the visitor gets an error rather than an image with potentially sensitive metadata still attached. That is a deliberate trade-off: an unavailable image is better than one that unexpectedly reveals a location or camera serial number.

Content Credentials

Content Credentials looks at files coming in rather than images going out. A Content Credential is a signed record inside a media file that can describe how it was created, what software was involved and whether AI was used. It uses the C2PA standard for media provenance.

When an editor uploads an image, video or audio file with such a record, signed by a certificate the site trusts, the module can suggest the matching grade in AI Disclosure. The editor can accept or ignore the suggestion. Without a credential, or with one the site does not trust, there is no suggestion.

AI Disclosure is a module by Giorgio Alfredo Pagano (sjpagan on Drupal.org) for saying how AI was used in content, and Content Credentials builds on it. AI Disclosure holds the classification and provides the editorial interface. Content Credentials reads the evidence and proposes a classification; it does not publish a label by itself.

This matters because a newsroom or publishing team may receive files from photographers, agencies, clients or AI tools without knowing exactly how each file was created. A trusted Content Credential can provide information worth considering during editorial review. It does not remove the editor's responsibility to check the file or decide how its use of AI should be disclosed.

The distinction between verification and truth is important. A valid C2PA signature can establish that a signed record has not been tampered with and that its signer is trusted under the configured certificate policy. It cannot prove that everything shown in the image is true. The C2PA specification's explainer makes that limitation clear. The absence of a credential is not evidence that a file was made by a person rather than AI, either. Credentials can be missing, removed or lost during conversion.

You switch Content Credentials on per content type or media type. When an editor adds or replaces a file, Drupal puts it into a queue. The file is read on a later cron run, so the upload itself is not held up by verification. When the result supports a suggestion, the editor sees it on the edit form and decides what to do.

The module offers several ways to read credentials. A pure-PHP verifier can work on ordinary hosting without a native extension. A site can instead use a verification service over HTTPS or the ext-c2pa PHP extension. Each route has its own requirements and file-format limitations.

The administrator must also configure the trusted certificates, or trust anchors, against which signatures are checked. A valid signature from an untrusted signer does not produce an AI disclosure suggestion.

This is more than a technical detail. Trust settings determine what evidence the editorial workflow will act on. A site must decide which certificates it recognises, check that the verifier is working and make sure queued processing can access the uploaded files.

Images scaled during upload can also require the cron process to read a protected temporary original. On hosting where cron uses a different user or cannot access the same temporary directory, the expected suggestion may not appear. These are practical deployment questions that need testing alongside the verification itself.

How it fits in

The two modules have different purposes, but they also fit into a wider Drupal workflow. Embedded Attribution handles the credit that goes into an image derivative. Content Credentials reads signed provenance on incoming media. AI Disclosure records the editor's AI classification, while C2PA Sign can sign files that Drupal publishes.

Embedded Attribution runs on ordinary hosting, without extra software on the server. It also works with C2PA Sign: the credit is written first, so it can end up inside the signed derivative. I tested this, and if you change the maker afterwards without signing the file again, the signature no longer holds. This is why the order matters. Attribution and other metadata must be written before the published copy is signed.

Giorgio has also documented a test of Content Credentials, AI Disclosure and C2PA Sign together. In that workflow, an incoming signed image produces an AI disclosure suggestion, the editor confirms the grade, and Drupal's published derivative receives the declaration and a new signature. His test also showed how image conversion can remove an incoming credential before it reaches Drupal.

A publishing system can preserve the information it receives, but it cannot recover provenance that has already disappeared. And a signed declaration does not make the underlying content true. Both points matter when deciding what a website should tell its visitors about an image.

These integrations are still developing. Embedded Attribution and Content Credentials are not replacements for AI Disclosure or C2PA Sign. They address particular stages of the publishing process, and the order in which modules handle files can affect the result. A site using several image-processing or metadata modules needs to test the complete workflow.

And yes, for modules about labelling AI: I built them with the help of an AI coding assistant. I review and test the changes, and the development work is logged in the repositories. Using AI to help write code does not remove the need to check what the code does, particularly when it deals with metadata, privacy and the trustworthiness of signatures.

Good to know before you install Embedded Attribution

There are some practical limits to keep in mind before installing the module.

• It handles Drupal image-style copies, including copies made in advance, for example with Drush; the format and integration limits below still apply. A module that changes the copies afterwards, such as an image optimiser, can remove the credit again.
• It works on photos uploaded as JPEG, WebP, AVIF or PNG, also when Drupal turns the copy into another of those formats. GIF images are cleaned but get no credit.
• With ImageMagick, a TIFF or HEIC upload may produce a copy in the same format, and the module does not serve such a copy with cleaning enabled. Add a Convert step to JPEG or WebP in the image style and it can be shown, cleaned.
• Images that were already on your site get the credit once Drupal makes their copies again. One button on the settings page does that.
• The original stays exactly as it was uploaded. If your site offers originals for download, their metadata goes along with them.

Embedded Attribution works on Drupal image-style derivatives, not every image that a website can serve. A direct link to an uploaded original still gives the visitor its original metadata. An external image service, an IIIF server or a storage integration serving files outside Drupal's image-style workflow may not pass through the module. Only the default translation currently supplies mapped fields.

And the costs are small: in my tests, about 4 milliseconds per image with GD, and only the first time the copy is made. That is a measurement from my test setup, not a benchmark for every site. Image sizes, hosting, file formats and other processing modules can change the result.

Both modules are in alpha, require Drupal 11.3 or later and PHP 8.3 or later, and are open source. Embedded Attribution 1.0.0-alpha4 was released on 22 October 2026. Content Credentials 1.0.0-alpha3 followed on 30 October, with 1.0.0-alpha4 released on 2 November and 1.0.0-alpha6 on 10 November 2026. The project documentation reports no production deployment for Content Credentials, and neither alpha release is covered by Drupal's security advisory policy at this stage.

To try them on a test or staging site:

composer require 'drupal/embedded_attribution:^1.0@alpha'
composer require 'drupal/ai_disclosure:^1.0.0-beta1'
composer require 'drupal/content_credentials:^1.0@alpha'

For Content Credentials using the pure-PHP verifier, install the supported verifier dependency as well:

composer require 'provemark/c2pa-verifier:^0.10'

Content Credentials requires AI Disclosure 1.0.0-beta1 or later for this workflow. An existing site still using AI Disclosure 1.0.0-alpha3 must update the dependency and run the required Drupal database updates. After installation, configure which content or media types the modules should handle, check the relevant fields and trust settings, and test the resulting files rather than assuming that the information has been preserved.

Both projects are open source, and I would like to hear what happens when other people try them. A museum with a large collection, a photography site that wants to retain camera information, or a newsroom receiving signed AI-generated media will each have different requirements. Testing those workflows, especially where other modules change or serve the files, will help establish what works and what still needs attention.

If you try them on a test site, I would like to hear your experiences in the issue queues:

Embedded Attribution issue queue

Content Credentials issue queue