search

w3c / web-advertising

Web Advertising BG - https://www.w3.org/community/web-adv/
https://w3c.github.io/web-advertising/dashboard/
Other
438 stars 93 forks source link

Non-advertising use cases #100

Open tomcrane opened 3 years ago

tomcrane commented 3 years ago

Hi,

What's the best way to discuss use cases that currently require third-party cookies, but are not related to web advertising?

A while ago we added this comment which summarises our problem, and we are happy to provide as much detail as required.

In short, the International Image Interoperability Framework allows of interoperability of cultural heritage content. It is implemented by hundreds of organisations worldwide, including, in the US, the Library of Congress and the Smithsonian; in Europe, the British Library and the Bibliothèque nationale de France, and hundreds of other universities, museums and cultural heritage institutions around the world. This interoperability happens in browser-based viewers and tools. Usually, the content is all open and has no access control requirements, but this is not always the case.

For example, if I am annotating Wikipedia-hosted images in a browser-based annotation tool on mydomain.org, and Wikipedia requires me to authenticate to see those images, then my tool running on mydomain.org needs to:

  1. Know that I can't see the Wikipedia content right now
  2. Know that I will need to go to "wikipedia.org/login" to do something about that
  3. Later, know that I can now see the content hosted by Wikipedia.

Crucially, mydomain.org doesn't need to know anything about me, or about my interactions with wikipedia.org, or how Wikipedia.org enforces access control, or have any knowledge of or access to my credentials for Wikipedia, or have any access to Wikipedia's protected content at all. It just needs to know whether or not a request from my browser for that content would succeed. Once it does know that, it can then render image tags (for example) that point to that content on Wikipedia. As these requests are cross-origin, it also requires that credentials I have acquired for wikipedia.org are included with those requests.

This is, I think, equivalent to:

It may be OK for a site to learn the fact that a user has earned trust on another site

from https://github.com/michaelkleber/privacy-model

Our current specification for these patterns is at https://iiif.io/api/auth/1.0/

This spec is fine with accommodating SameSite and other restrictions to date, but it will not work if credentials acquired in a trust relationship with a third party site are not then sent with content requests to that third party site.

If the privacy sandbox means that there is a way of selectively allowing one domain to learn something about a user's trust relationship with another domain, and that the mechanism of allowing this "leaking" is understood and trusted by the user, then we might be able to produce a new auth pattern that is significantly better and more transparent than the current pattern, which is tricky to implement. But if this use case is not going to be supported on the web in future, then we won't be able to continue with interoperability of access-controlled cultural heritage in the way we have been to date.

wseltzer commented 3 years ago

Is there a community group or other place where those of you expressing interest here currently meet? Or you might look to the Privacy Community Group for the more general issues of making web functionality work with the new privacy measures under discussion there.

tomcrane commented 3 years ago

We meet in a variety of forums (https://iiif.io/community/) and this week we are holding our Fall working meeting (https://iiif.io/event/2020/fall_working_meeting/).

Would this repo be the best place to describe the use case? https://github.com/privacycg/proposals/issues

One of our tasks is to come up with a set of interaction patterns that continue to support the use cases supported now, but will work in browsers for the next few years.

johnwilander commented 3 years ago

Hi! The Storage Access API is designed for exactly this use case and is shipping in Safari since early 2018, in Firefox since 2019 (I believe), and in Edge since last year. With it, the third party can request access to its cookies per first party website.

The Improving Web Advertising Business Group is probably not the right place to discuss non-advertising use cases. The Privacy Community Group regularly discusses the kind of issue you bring up and that’s where the Storage Access API is being worked on.

tomcrane commented 3 years ago

Many thanks @johnwilander - we'll have a read of the issues over there.