Avoid tracking when fetching external manifests?

[ts-web]

I'm investigating a reported concern in my c2pa browser extension about tracking. What happens is: my extension uses the c2pa library to get the manifest of an image, and if that image has an external manifest, the library makes a fetch request to that URL, which includes cookies. These cookies may include tracking cookies.

I'm still wrapping my mind around how much of an issue this is. The fetch request doesn't pass any headers like Origin or Referer, so the domain can't see which URL the user is viewing. But it does pass the cookies.

For example with Adobe URLs the cookies include values like gpv (get previous value), which shows the last visited content.

I suppose these cookies don't send the domain any new information, besides the event of passing the cookies. But this itself not new information, because the server knows that it's receiving a request.

Ah! There is new information: that the user is viewing a certain manifest. If the cookies identify a specific user, then the external manifest server can track which manifests the user is viewing.

So there is a valid concern about tracking. Does that track with you guys? (sorry, pun intended)

Would it make sense to add an option (or just change the behavior) to not send credentials with the fetch request?

Of course if the manifest url is behind auth, then not passing credentials would make the request fail. But do any external manifest urls require cookies like that? I'd assume not.

[DaveStein]

@ts-web is it possible for you to create a small repro on a jsfiddle-like (I am dating myself) site? AFAIK the JS SDK just reads data out of the file. That file may have a cloud manifest, in which case we would hit a server where that cloud manifest lives. There is no reason anything in the code should be passing any kind of cookies through since it would just be a generic GET to a public URL.

Aside from making a small repro case, it would be helpful if you could post screenshots of the network requests' request and response headers.

[ts-web]

Hi @DaveStein this is kind of interesting. I have been unable to reproduce the cookies in a codesandbox, but I still continue to see them being sent by the extension. It turns out that Chrome extensions have different third-party cookie rules.

According to the Chrome Extension Storage and Cookies docs:

Requests from an extension to a third-party are treated as same-site if the extension has host permissions for the third-party. This means SameSite=Strict cookies can be sent.

For reference here is what I'm testing: The image is at: https://static.showit.co/2400/Pvacxu7xxA8zXfCWEwfveA/217387/eclipse-web-05.jpg and it has an embedded manifest at this url: https://cai-manifests.adobe.com/manifests/adobe-urn-uuid-b120e693-9b3f-46b1-919c-652272e210e1.

Here are repro steps:

1. Navigate to an adobe page to ensure you have adobe cookies. E.g. https://stock.adobe.com/se/images/noah-s-ark-rainbow-in-the-sky-hills-in-the-background-leica-m-80mm-lens-4k/541125483
2. Install the browser extension: https://chromewebstore.google.com/detail/contentlens-c2pa-validato/gdejpnjeepoffhkbcgnjdbkgpohdhmln
3. Inspect the extension's offscreen page by going to chrome://extensions/?id=gdejpnjeepoffhkbcgnjdbkgpohdhmln and clicking offscreen.html. Keep that DevTools window open to log the network request.
4. Navigate to https://static.showit.co/2400/Pvacxu7xxA8zXfCWEwfveA/217387/eclipse-web-05.jpg
5. Right-click the image and click "Verify with ContentLens".

In the offscreen.html DevTools you should see the request for the external manifest, listed as adobe-urn-uuid-b120e693-9b3f-46b1-919c-652272e210e1. And when inspecting it, you see the cookies in the request headers.

If this is a third-party cookies situation, it won't be reproducible in codesandbox or jsfiddle, because Chrome doesn't send third-party cookies in those cases.

As far as solutions:

On the extension side, I can investigate the condition mentioned in the docs: "if the extension has host permissions for the third-party". It might be possible to limit the permissions of my extension, if it's possible to do that without hindering its functionality.

On the library side, it might make sense to specify {credentials: 'omit'} in the fetch call. The c2pa library makes the fetch call here in c2pa.ts.

Thoughts?

[ts-web]

After some thought, it doesn't seem possible to fix on the extension side. Because, the extension makes its own fetch requests and it needs to include credentials with those requests. If we remove the permissions from the extension, then it won't be able to function.

The extension needs to fetch images in order to load their data . It loads the images by their url and sends cookies in order to do so. Because in the web platform there's no way to simply get the image data that's already loaded on the page. The only way to get image data is by making a fetch request.

So it seems like the fix needs to happen in the c2pa library.

From an API perspective, maybe the C2paReadOptions interface can get an option to configure the fetch call for external manifests in one of these ways:

• a custom fetcher: fetchExternalManifest?: (url: string) => Promise<...>
• fetch options: externalManifestFetchOptions?: RequestInit (RequestInit is the built-in dom interface that includes credentials -- i.e. the second parameter to fetch).

[bgon]

Any update regarding this issue? The kind of cookies sent using this library against the Adobe Credentials cloud repository, in the context of a Chrome extension, should require consent under EU's GDPR.
Developpers using this library should be made aware of that.

Example:
In a new Chrome instance, just one visit to an adobe.com properties, and the first lookup using the library lists 11 cookies, most of them advertising tracking coookies.

Name	Value	Domain	Path	Expires	Size	HttpOnly	Secure	SameSite	Partition Key Site	Cross Site	Priority
AMCVS_{redacted}%40AdobeOrg	1	.adobe.com	/	Session	42						Medium
AMCV_{redacted}%40AdobeOrg	{redacted}%7CMCIDTS%7C20133%7CMCMID%{redacted}%7CMCAID%7CNONE%7CMCOPTOUT-1739437050s%7CNONE%7CvVersion%7C4.4.0	.adobe.com	/	2026-03-20T06:57:30.451Z	180						Medium
OptanonConsent	isGpcEnabled=0&datestamp=Thu+Feb+13+2025+07%3A57%3A26+GMT%2B0100+(Central+European+Standard+Time)&version=202311.1.0&browserGpcFlag=0&isIABGlobal=false&hosts=&consentId={redacted}&interactionCount=1&landingPath=NotLandingPage&groups=C0001%3A1%2CC0002%3A0%2CC0003%3A0%2CC0004%3A0&AwaitingReconsent=false	.adobe.com	/	2026-02-13T06:57:26.000Z	342		✓	None			Medium
datadome	{redacted}{redacted}{redacted}	.adobe.com	/	2026-02-13T06:57:43.792Z	136		✓	Lax			Medium
gpv	stock.adobe.com:search	.adobe.com	/	2025-02-13T07:27:30.000Z	25						Medium
s_a_campaign	BMVV34ZM	.adobe.com	/	Session	20						Medium
s_cc	true	.adobe.com	/	Session	8						Medium
s_ecid	MCMID%{redacted}	.adobe.com	/	2026-03-20T06:57:30.487Z	52						Medium
s_nr	1739429845330-New	.adobe.com	/	2026-02-13T06:57:25.000Z	21						Medium
s_ppv	[%22stock.adobe.com/se/promo/firstmonthfree%22%2C100%2C0%2C1251%2C1453%2C922%2C1920%2C1080%2C1%2C%22P%22]	.adobe.com	/	Session	110						Medium
s_sq	%5B%5BB%5D%5D	.adobe.com	/	Session	17						Medium