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).