这是indexloc提供的服务,不要输入任何密码
Skip to content

Dynamic but K-Anon Creative URLs for Server Side BA Auctions #729

@thegreatfatzby

Description

@thegreatfatzby

One of the fun challenges we're working on is the need to pre-declare creatives in the IG at IG joining time, and being constrained to those at auction time. Update URL frequency could be tweaked to make this better, but fundamentally it's a challenge.

It's also interesting because I think that requirement is mainly operational: in theory if the creative URL was not pre-declared but met K-thresholds that wouldn't impact privacy, but that K evaluation at auction time would be infeasible if all browsers had to query for all object Ks at auction time. Rather than doing that, K is updated periodically based on the declared creatives, allowing the K evaluation to happen locally at auction time.

I would think that in the evolving BA world this could be loosened with some smart coordination. If we did a setup something like this:

  1. K Servers are placed in various DCs worldwide. They shard K-object counts by owner, have some level of redundancy within each cluster, and are eventually consistent across DCs.
  2. The service adds something for an owners Buyer* Front End TEEs to pull (service or pub/sub, I'd go pub/sub for start up + incremental, but I digress) K-updates into memory.
  3. The BFE code pulls that down, and includes it in the response to the SFE (note it would be the Trusted code doing this, not the bidding functions.
  4. SFE could use the value from the response of K-filtering (I'd also like to see multiple bids returned which would help with finding optimal bids in the place of K-misses.
  5. A callback from the SFE to the BFE would result in an incrementing of K as needed.

Could we allow the Buyer Front End/Bidding Functions to return creative URLs without pre-declaration, but just still apply the K-anon threshold locally.

*In the long run I would push for this being "Interest Group Owners", as I hope to see some of the publisher side IG flexibility discussed in #686.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions