Changing browser support for third party cookies

[tomcrane]

Summary

If browsers won't send third party cookies, cross-domain IIIF interoperability for access controlled content is broken.

Detailed Version

Interoperability for IIIF is about third party contexts; where some or all of the content you're trying to look at is coming from a third party. The host name in your browser’s address bar is often not the host name of the images your viewer is requesting. They might even be coming from multiple different hosts.

For access control across multiple publishers, clients send credentials to third parties for simple web requests, to see images.

A simple HTML page is an example:

<img src="https://other-site.org/access-controlled-image/full/max/0/default.jpg" />
<img src="https://yet-another-site.org/another-image/full/max/0/default.jpg" />

But now, Safari 13 blocks third party cookies by default - even SameSite=None ones.
Chrome wants to go this way too.

The reasons are good - protecting your privacy. Stopping tracking.

Tracking works because a page on some-site.org has an image that loads from ad-server.com, which at some point previously, set a cookie on my machine. When it sees my image request with that cookie, it knows it is me.

But this is how interoperability works for our simple web requests, too!
Your IIIF client doesn’t know how you got the cookie, it can’t see it, doesn’t know how other-site.org works. It relies on the browser sending any credentials along with image requests.

Chromium

After initial dialogue with the web community, we are confident that with continued iteration and feedback, privacy-preserving and open-standard mechanisms like the Privacy Sandbox can sustain a healthy, ad-supported web in a way that will render third-party cookies obsolete. Once these approaches have addressed the needs of users, publishers, and advertisers, and we have developed the tools to mitigate workarounds, we plan to phase out support for third-party cookies in Chrome.

Links:

https://www.chromium.org/Home/chromium-privacy/privacy-sandbox
https://github.com/WICG/first-party-sets
https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html
https://www.blog.google/products/chrome/building-a-more-private-web/
https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html

What can we do?

The Privacy Sandbox idea might be a way out, if it's some kind of formal opt-in to third party credentials. We need to put some work into understanding exactly what is proposed.

If not, then in the absence of third party cookies, IIIF Auth has to become a protocol in its own right, which probably means sending a credential as part of a GET... info.json?token=abcd, and doing precisely what we set out to avoid.

These are wildly diverging approaches, and we need more info and involvement in the sandbox work if we hope to pursue it. So although Auth is the most important thing to get working on, there's a problem in deciding exactly what to do.

Our first attempt at engagement:

w3c/web-advertising#22 (comment)

[scossu]

Thanks @tomcrane for summarizing this and @azaroth42 for presenting the IIIF use case to the W3C group.

Let me see first if I got the problem right:

• Institution A publishes a IIIF viewer app at https://a.edu/viewer
• Institution B publishes a IIIF image which is under access control, at https://b.edu/image
• User U visit the image from B on the viewer site A.
• Site B requests authentication through the viewer. User authenticates in the viewer.
• Site B sets a session cookie in the browser.
• But User U updated their browser, and auth is broken! Since the session cookie comes from b.edu and we are vewing a.edu, the browser refuses to see it and, for a.edu, U is as good as nobody.

Correct?

After reading through your links, I formulated some thoughts that are still a bit fuzzy and scattered:

Privacy sandbox seems the most appealing concrete proposal so far. I have a couple of reservations however. Mainly, it seems to only apply to Chromium and derivatives, so it's not really a "standard" but more of a workaround for a problem driven by a specific community.

Ideally I would like to see a solution from a group that is not primarily focused on advertising. While I share some of the core principles behind the idea, I think there is a risk that our goals may diverge from the main one in the future. Especially if such group were to continuously review new techniques for behavior tracking, which could make the spec too high-maintenance for us.

Also, we shouldn't be constrained to only one solution. For example, if Privacy Sandbox were the most approachable solution for some, that might be implemented by some, but also we could have alternatives that don't use cookies at all. Therefore, I wouldn't completely discard @tomcrane 's idea (however presented with some doubts) of having an auth token passed for each request. It may not work for some, it may be the best approach for others.

As for first-party sets, I'm not sure if IIIF auth is in the scope of this proposal. Maybe I'm misunderstanding the rationale, but wouldn't this still block cross-institutional auth information such as in my example above?

I don't know how much value this adds to the conversation, but I am interested in keeping the discussion going and exploring different solutions.

[tomcrane]

Hi @scossu

Yes, your summary is correct. User U's browser address bar shows https://a.edu/viewer; it will therefore not send any cookies when it requests https://b.edu/image.

[tomcrane]

Update on where this being discussed

W3C Privacy Community Group:
privacycg/storage-access#72

Minutes of meeting - https://github.com/privacycg/meetings/blob/main/2021/telcons/04-22-minutes.md

Chrome - Privacy Sandbox:
privacysandbox/privacy-sandbox-dev-support#8

[tomcrane]

And update on experimental implementations using storage access API:

https://tomcrane.github.io/iiif-auth-client/
This talks to three different server implementations

Source code:
Client - stripped down version of original auth:
https://github.com/tomcrane/iiif-auth-client/tree/simplified_v1
Client: stripped down + storage access:
https://github.com/tomcrane/iiif-auth-client/tree/simplified-with-storage-access
Deployed at https://tomcrane.github.io/iiif-auth-client/
Server - stripped down version of original auth:
https://github.com/tomcrane/iiif-auth-server/tree/simplified_v1
Deployed at https://iiif-auth-server.herokuapp.com/
Server - stripped down + storage access:
https://github.com/tomcrane/iiif-auth-server/tree/simplified-with-storage-access
Deployed at https://iiif-auth-server-privacy.herokuapp.com/
Additional server branch with clickthrough:
https://github.com/tomcrane/iiif-auth-server/tree/simplified-clickthrough
Deployed at https://iiif-auth-server-clickthrough.herokuapp.com/

Client points to all three of the server branches, for different images.

[nicolasfranck]

Adding a token to the image urls would indeed help within the flow
of a IIIF viewer, where failed image requests (status 403) can be resolved
by requesting a new token.

But what about the use of images outside the
context of a viewer? For example as thumbnails within your website?
Now those image requests succeed if you previously visited their viewer and
logged in. I admit, that is a strange way of letting your website access
the thumbnails, but it is a practical effect.

[zimeon]

Resolved. The IIIF Authorization Flow 2.0.0 specification was published 2023-06-02: https://iiif.io/api/search/2.0/

[tomcrane]

TSG Propose close this issue.