privacysandbox/protected-auction-services-docs

Divergence between Design Proposal & Bidding and Auction Services API

Closed this issue · 2 comments

davidae commented

Hello 👋
An initial big thanks for keeping this document up-to-date and alive 🙌

I've kept an eye on the Design Proposal, Developer Guides for FLEDGE, and this page over the past few months.

As bidding_auction_services_api.md has received more updates lately, I find it hard to know which proposal is the "latest" and most accurate/realistic. It would be great to know more about this since the proposals are quite different now and it will make it harder to prepare for the Beta which should happen this year.

A few examples of the differences

  • Omission of BiddingLogicURL and it's purpose
  • seller+buyer gRPC calls vs. user's device HTTPS calls
  • On-device javascript execution vs. self-hosted TEE javascript execution
cshmerling commented

You should prepare for Android Beta using FLEDGE on device as planned. Bidding & Auction services are not in scope and will not be ready for Beta. The Developer Guide and other documentation is still receiving updates when we release new Develop Previews, and the documentation will be accurate to use when we transition to Beta.

We are making an effort such that differences are small and there is minimal overhead for Adtechs if you need to transition from on-device execution to server side in the future.

Regarding differences.

  • Omission of BiddingLogicURL and its purpose
    For server side, the code can be pushed to Bidding service and Auction service. At this point, we have decided upon a push model due to additional security restrictions on the Bidding / Auction service. However, we may evaluate the pull model eventually, though in that case the TEE based server will read the url to fetch Bidding logic and Scoring logic from configuration at server startup. So the url doesn't need to be passed from the device again.

  • seller+buyer gRPC calls vs. user's device HTTPS calls
    The SellerFrontEnd, Auction, BuyerFrontEnd, Bidding are grpc based.
    Clients can send grpc or HTTP to SellerFrontEnd, there is Envoy Proxy hosted in the same TEE backed Virtual Machine that would do the transcoding.
    Note that BYOS Key/Value server and JS fetch endpoint should be HTTPS based as documented in Android FLEDGE design.

  • On-device javascript execution vs. self-hosted TEE javascript execution
    On device Javascript execution is what you should prepare for Android Beta.

We are seeking feedback about TEE based Javascript execution from Adtechs at this point. The Javascript developed for on-device execution should work for server side execution with minimal changes.

davidae commented

Thank you for the detailed reply 👍