scossu
commented
4 years ago 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
nicolasfranck
zimeon
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:
But now, Safari 13 blocks third party cookies by default - even
SameSite=Noneones. 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
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:
https://github.com/w3c/web-advertising/issues/22#issuecomment-576775419