Viewing media from different domains - cultural heritage interoperability

[tomcrane]

(Adapted from privacycg/storage-access#72)

This use case was discussed on the W3C privacy-cg community call of 22 April: https://github.com/privacycg/meetings/blob/main/2021/telcons/04-22-minutes.md

Our current auth patterns, described at https://iiif.io/api/auth/1.0/, are dependent on third party cookies.

This specification is for museums, libraries and archives (any one else) publishing access-controlled material that conforms to the IIIF specification.

Simplified expression of problem

Starting condition - user is logged in at publisher.org and has a session. On a web page at publisher.org, user can view access controlled images because the session cookie is sent with the image request.

<img src="https://publisher.org/image.jpg" />

Over at viewer.org, the user is working on an art annotation project using this same image from publisher.org. Even though a direct first party request for https://publisher.org/image.jpg works for the user (because they have a session), when that request is initiated from viewer.org, the image is broken because the browser policy no longer permits third party cookies to be sent.

<img src="https://publisher.org/image.jpg" />

Cross domain interoperability for access controlled images relies on third party cookies. Recently implementations have had to make sure they were using SameSite headers correctly, but it still worked.

We understand that the web feature that enables this interoperability is the same web feature that is abused by trackers. Consensual opt-in to third party cookies via browser API solves this more elegantly. Our experiments with the Storage API (in Safari, Firefox and Edge) suggest that our current spec can be revised to include use of the Storage API to gain the user's consent for sending third-party cookies on a domain-by-domain basis.

Another part of our spec is about how viewer.org client code learns whether the user has credentials for https://publisher.org/image.jpg without having to know anything about the credentials themselves, which might be a use case for isLoggedIn.

Summary

Recent browser developments have broken our spec, but we think that a revision that incorporates the storage API can get it working again in browsers that continue to support third party cookies.

We're not sure where this leaves us with Chrome.

To be clear, the use cases for our spec are not about tracking (we don't need to track) or even establishing identity - the client doesn't need to know who the user is, just whether they can see a resource. Although it could be used in a commercial context, there are no advertising or other commercial drivers behind this specification, it's all about interoperability of content, that for various reasons (most commonly today, cultural sensitivity) is behind some form of access control.

We need:

• To avoid creating a broken user interface, we need to know whether a user can see a third party image (i.e., that the user has a credential for that image, usually a cookie). We don't need to know what the credential is, how it works, or any other aspect of the publishing party's access control mechanism.
• Once we know they should be able to see it, we rely on the fact that the browser will send whatever credentials (typically, third party cookie(s)) that user has for that request.

If Chrome removes support for third party cookies, can we use Privacy Sandbox to meet the same use case?

Links

• iiif.io
• What happens if there are no third-party cookies? (short (3 min) explanation of the problem)
• Access Control, Interoperability and Cultural Heritage (longer (9 min) explanation of the problem)
• Web Privacy issue #72 - this issue has a lot of detail and further information.

[samdutton]

Hi Tom — thanks so much for all the detail here.

We'll take a proper look and respond. (A bit delayed, catching up after Google I/O!)

[scossu]

As another member of the cultural heritage IT community I support a solution that is robust and can be maintained by the very limited resources of the IIIF spec editors.

Ideally, if Chrome supported the Storage API, it would save the editors from developing two separate solutions, one for Chrome and one for other browsers. I understand this use case serves a tiny niche in the Internet, and have no insight into the efforts required to implement a common solution in Chrome, but it would be good to know where the Chrome developers' opinion is at in this regard. Thanks.

[tomcrane]

Hi @samdutton

We've been checking in on the latest developments on First Party Sets and CHIPS to see if they help our use cases.

First-Party Sets

We don’t wish to correlate user activity across sites, and we don’t need (or want) user identity to share beyond a single context.

https://github.com/privacycg/first-party-sets/ says:

This proposal is consistent with the same-origin policy. That is, Web Platform features must not use first-party sets to make one origin's state directly accessible to another origin in the set. For example, if a.example and b.example are in the same first-party set, the same-origin policy would still prevent https://a.example from accessing https://b.example's cookies or IndexedDB databases.

…that is:

If my browser address bar is Site A and the page has image A and image B, cookies for site B will still be sent because A and B are in a first party set. BUT cookies for A would not be sent with that request for image B UNLESS site A’s cookies are explicitly marked SameParty. Which we would not (normally) need to do.

So can our IIIF use case still use FPS? We could conceivably establish a formal trust relationship between publishers and clients if it’s the only way. But IIIF Publishers are not a typical first party set as defined, in that they:

• Issue cookies independently
• Don’t need to (in fact, must not) know anything about what users are doing on other “members” of the set: a credential for one is not a credential for any other (that’s OK, same origin policy is still the default, I think)
• Don’t need any sort of state or shared identity across contexts

Scenario

• IIIF Consortium declares itself the FPS owner
• IIIF publishers (bl.uk, nga.gov, bnf.fr, etc) are registered members of the set

If the viewing app was running on bl.uk but the content was on nga.gov, nga.gov cookies would still be sent with nga.gov requests.

This means that client applications that are not publishers (e.g., projectmirador.org, universalviewer.io, fromthepage.com, and many many more "unknowns" - my-example-annotation-tool.org) would also need to be members of the set, because they are the top-level context - the address in the browser address bar. You can’t run your own viewer/tool without registering as a set member, which rules out embeddable IIIF content.

It seems we need a “trusted third party set” rather than a first party set. Members of that third party set permit a browser to send their issued cookies when they are in a third party context. Somehow related to Goals For The Origin Info Bubble - The Chromium Projects.

Ideally this set is established from content, ad-hoc, with the user granting permission for third-party cookie behaviour for the origins required right now by the page/viewer (likely to be only 1 or 2 distinct origins). That could still have the protection of a publisher list; you can’t trigger the browser to ask the user for permission for third-party-cookie-sending if that third party is not on a list.

This would allow client applications (viewers, annotation tools, web pages with images) to remain untrusted (not on the list).

Cookies Having Independent Partitioned State (CHIPS)

“... the Partitioned attribute [...] will indicate to user agents that these cross-site cookies should only be available in the same top-level context (top-level site or that site's First-Party Set if it has one) that the cookie was created in.”

This is the inverse of our problem. The top level context we want the cookies available in would be the viewer/annotation tool, which is never where the cookies are created. We don’t need to create the cookie in a third party context. The cookie for site A is always set by a user interacting with the origin in a first party context, typically via site A’s login page.

Later, the browser needs to know it can send that cookie. We need a feature where the cookie is only sent in a 3rd party context if it was acquired in a first party context (and not surreptitiously from evil-tracker.com).

This sounds more like the Storage Access API; the third-party site A cookie is sent by the browser because the browser knows it was set when site A was in the address bar. And if that was some time ago or the browser is otherwise suspicious of it, there is a mechanism to ask the user whether to grant permission to send it cross-domain.

Rather than the diagram on the CHIPS page, we need this:

User on green.com
Gets broken image for red.com/img.jpg because no cookie for red.com
...
User goes to red.com and logs in
Red.com sets cookie in 1st party context
(user can see img.jpg on this site)
...
User goes back to green.com
red.com/img.jpg now 200 because browser sent that third party cookie

Summary

We could work with something like a FPS, but where membership is quite flexible, and only permits the browser to send third party cookies if they were acquired in a first party context, with a significant interaction in that context (no cheating by flashing open a window, setting a cookie and closing it).

[samdutton]

Hi @tomcrane Thanks for the question — and all the detail. We'll take a proper look and get back to you.

[krgovind]

Thank you for sharing your use-case with us! We are certainly mindful that a wide variety of applications rely on third-party cookies, and intend to provide guidance for use-cases as they come to our attention.

Chrome currently does not plan to ship Storage Access API as a long-term general-purpose API that allows access to third-party cookies; but we hope to recommend purpose-built APIs depending on the use-case, so that they can provide the right user experience, and privacy guarantees for the long-term.

First Party Sets (FPS): We don’t think FPS would be the right solution here; since the IIIF publishers that you listed as examples (bl.uk, nga.gov, bnf.fr, etc) clearly do not share a common owner and controller, as specified in the UA Policy for FPS.

However, we wanted to clarify a few things:

If my browser address bar is Site A and the page has image A and image B, cookies for site B will still be sent because A and B are in a first party set. BUT cookies for A would not be sent with that request for image B UNLESS site A’s cookies are explicitly marked SameParty. Which we would not (normally) need to do.

In this scenario, is image A hosted on site A, and image B on site B? In that case, A’s cookies would not be sent on the request for image B (even without any third-party cookie restrictions) as per the Same Origin Policy for cookies. Only cookies associated with site B may be sent on the request. (“may” because cookie inclusion rules related to the SameSite and Domain attributes apply) However, cookies for the embedded third-party site B must be marked SameParty.

Don’t need to (in fact, must not) know anything about what users are doing on other “members” of the set: a credential for one is not a credential for any other (that’s OK, same origin policy is still the default, I think)

Correct, same origin policy still applies. The fact that a member domain has access to credentials on its own domain may allow it to correlate user activity across other member domains that it is embedded on; but we don’t expect that all sites will use it to do so.

CHIPS: Partitioned cookies might be a potential direction if you are okay with having the user re-authenticate on publisher.org when they’re on viewer.org. Would that be acceptable to you?

This is not currently possible with CHIPS, but we are considering proposing some new functionality that would allow viewer.org to create a partitioned navigation/popup window to publisher.org. This publisher.org document would not have access to the same cookies as if the user had independently navigated to publisher.org in a first-party context; but would have cookies “partitioned” to viewer.org.

Trust Tokens? - We have a follow-up question on something you said on the original post:

the client doesn't need to know who the user is, just whether they can see a resource

It might be worth considering whether a solution like Trust Tokens might be useful here.

Could you clarify whether:

• All you need is a boolean verdict on whether the user can see resources from that site or not (perhaps the verdict is simply based on whether the user is signed in on publisher.org), or do you have multiple access levels? The verdict is true for all resources from the site, and not determined on a per-resource basis?
• If the user logs out of publisher.org, would you prefer immediately revoking access to resources from other viewing sites; or is it acceptable if there are previously cached tokens that are used until they are spent/expired?

[tomcrane]

Hi @krgovind

Many thanks for your reply!

In this scenario, is image A hosted on site A, and image B on site B?

Yes

Partitioned cookies might be a potential direction if you are okay with having the user re-authenticate on publisher.org when they’re on viewer.org. Would that be acceptable to you? [...] we are considering proposing some new functionality that would allow viewer.org to create a partitioned navigation/popup window to publisher.org.

This might be a possible approach. One of the principles of our auth spec is that the login process is clearly external to the viewer, at the publisher's site. E.g., it's not in some JS popup without an address bar. The user goes there in a new tab/window, an obvious (to the user) first party context. Once back on viewer.org, requests for images at publisher.org are accompanied by the cookies acquired through that login, and viewer.org client code can be confident that they won't be 40x responses.

This publisher.org document would not have access to the same cookies as if the user had independently navigated to publisher.org in a first-party context; but would have cookies “partitioned” to viewer.org.

Does this mean that publisher.org, in that popup, can set cookie(s) partitioned to viewer.org, that will then be included on requests to publisher.org images made from viewer.org?

Additional API around the showing of that navigation/popup, including a message indicating success, could simplify the flow of our spec, which currently involves a postMessage(..). I'd be interested in understanding whether that popup could also be used as a "probe" for the viewer application to learn of the user's current auth status wrt the image resources.

Could you clarify whether:

All you need is a boolean verdict on whether the user can see resources from that site or not (perhaps the verdict is simply based on whether the user is signed in on publisher.org), or do you have multiple access levels? The verdict is true for all resources from the site, and not determined on a per-resource basis?

It would need to be on a per-resource basis. Although we simply talk about image requests to focus on the sending-of-third-party-cookies problem, each image resource has an associated service endpoint that we probe to determine whether the user can see the image.

In practice, a user will sometimes have the same access to all of a publisher's images, and it is a boolean decision. But this is not always the case, especially in higher education / e-learning scenarios, and for archival content, where permission maybe very specific and accompanied by varying terms.

If the user logs out of publisher.org, would you prefer immediately revoking access to resources from other viewing sites; or is it acceptable if there are previously cached tokens that are used until they are spent/expired?

This is probably acceptable if use of these tokens simplify the flow elsewhere!

This slide deck has an explainer about IIIF Auth:
https://docs.google.com/presentation/d/1KBFYK0pz-NPqY5BTeP97XHUrMKYEeg53S1_9Uq9Ylxc/edit#slide=id.ga5a145864f_0_116

Slide 21 has an "English language" version of the process - even stated like that it's quite complex!
We're open to quite radical changes to this flow in the interests of simplicity for implementers (both viewer and publisher). The spec at the moment lives in the cracks of what is permitted via cookie policy, CORs etc; those cracks get narrower and narrower, any pattern that provided an alternative, "official" way of achieving the (not unreasonable) use case would be most welcome. Our spec is called an auth spec but it's not itself an auth protocol (it doesn't protect any resources itself) - instead it's a protocol for:

• learning whether a user has access to third party resource X
• if they don't, sending them somewhere at X where they could get access

Once again, many thanks for your reply!

[mikeapp]

CHIPS: Partitioned cookies might be a potential direction if you are okay with having the user re-authenticate on publisher.org when they’re on viewer.org. Would that be acceptable to you?
This is not currently possible with CHIPS, but we are considering proposing some new functionality that would allow viewer.org to create a partitioned navigation/popup window to publisher.org. This publisher.org document would not have access to the same cookies as if the user had independently navigated to publisher.org in a first-party context; but would have cookies “partitioned” to viewer.org.

@krgovind It would be great to see documentation about this proposal if it moves forward. One question that came up during today's IIIF call was whether this mechanism could accommodate auth workflows that redirect (e.g., to sso.publisher.org) prior to setting the cookie in the popup window.

[cfredric]

Hi all, I'd like to provide an update on Chrome's plans with regard to the Storage Access API. Chrome now plans to implement the Storage Access API; I've written up details about what exactly this means here: https://github.com/cfredric/chrome-storage-access-api.

From what I understand, this will not fully address your use case, since the recent security improvements of the Storage Access API now require that an embedded iframe call document.requestStorageAccess() before third-party cookies are available (and therefore the images in your scenario cannot use the Storage Access API). Is that still accurate?