Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Exchange Support #14

Open
jrmooring opened this issue Jan 25, 2022 · 2 comments
Open

Exchange Support #14

jrmooring opened this issue Jan 25, 2022 · 2 comments

Comments

@jrmooring
Copy link

The Topics API restricts learning about topics to those callers that have observed the user on pages about those topics.

It sounds like if a publisher issues an ad request to an ad-exchange server then DSPs participating in the exchange can only receive topics known to the ad-exchange?

I wonder if browsingTopics() can be extended to take an array of "reader" domains and respond with a mapping from each reader domain to the set of topics known to that reader domain, with each reader's set of topics encrypted with a public key published by that reader at a /.well-known/ path?

With this approach could the x-origin iframe also be avoided?
@jkarlin
Copy link
Collaborator

jkarlin commented Jan 26, 2022

Interesting proposal! I need to chew on this. There is real cost to those .well-known lookups and the encryption operations. And any caching we do would need to be per-top-frame-site, so the caching would have limited value across sites.

@dialtone
Copy link

I think this is also related to this issue I raised as well #16 . As you point out the cost of doing this on the client side would be quite high, but maybe there's something to be done with FLEDGE?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dialtone @jrmooring @jkarlin