Trusted Scoring Server Expected Usage

[nikunj101]

According to the current FLEDGE specification, sellers provide their trustedScoringSignalsUrl at auction time in the runAdAuction call. This means they could embed arbitrary publisher signals like a publisher’s first party user identifier or the full page url within the trustedScoringSignalsUrl. The trusted scoring server could then utilize this information to better implement seller functionalities, like url/user specific ad exclusions. Is this considered an acceptable usage of the trusted scoring server?

[michaelkleber]

No, you're right, we'll need to change the mechanism so that the trustedScoringSignalsUrl can't be based on user-specific data.

[jeffkaufman]

What goes wrong with letting trusted servers consider more fine-grained publisher information? I don't understand how this fits with the privacy model.

(Context: in #191 (comment) @MattMenke2 raised the idea of letting information flow from the AuctionConfig into (both) trusted server calls, as general-purpose functionality that could support experimentation.)

[michaelkleber]

The goal here is to maintain parity with the buyers' usage of a key-value server: the keys are intended to be pretty much static, suitable for just key-value lookup, rather than dynamic keys suitable for computing on.

[MattMenke2]

Regardless of what they are "intended to be", what's the risk in them being dynamic keys suitable for computing on? Also, are we concerned about arbitrary data being passed from the passed from the publisher to the seller in the seller's URL?

[michaelkleber]

Regardless of what they are "intended to be", what's the risk in them being dynamic keys suitable for computing on?

Even though we expect the KV lookup to start with a no-privacy-guarantees BYOServer implementation, we want the use cases to remain compatible with a much more private future. If the values are based on fixed keys, we're talking about graduating to something like oblivious database retrieval, PIR, etc. If the values are based on dynamic stuff for computing on, then we need to imagine much more complexity for the more private future — MPC, homomorphic encryption, etc. So I very much want to keep the KV input simple enough that we can see its upgrade path.

Also, are we concerned about arbitrary data being passed from the passed from the publisher to the seller in the seller's URL?

Which URL do you mean? The trustedScoringSignalsUrl is special because at KV lookup time it gets tied to user-specific data. We don't need to worry about things like decisionLogicUrl.

[MattMenke2]

I meant decisionLogicUrl (or trustedScoringSignalsUrl).

Anyhow, it seems like a DB lookup or any computation based on arguments to either URL from the publisher page don't violate the expectations of a trusted server, which are more around logging and passing along information, rather than querying existing information, or performing computations based on it.

It's also unclear to me if these seller URLs benefit at all from coming from/going to a trusted server - the publisher knows everything going to those URLs, anyways, and could easily transfer that exact same information to an untrusted server managed by the seller as well, in the context of the page.

[michaelkleber]

Anyhow, it seems like a DB lookup or any computation based on arguments to either URL from the publisher page don't violate the expectations of a trusted server, which are more around logging and passing along information, rather than querying existing information, or performing computations based on it.

If the trust model for the KV server is "You're allowed to know everything, just promise not to write it down anywhere", then there is no harm in passing more information. If the trust model is "You're allowed to execute blind database lookups, but we're going to encrypt the keys in some way that means that you can't actually learn the details of what you're serving", then putting personalized info into other parts of the URL is a problem. For now at least, we'd like to keep the second option open.

It's also unclear to me if these seller URLs benefit at all from coming from/going to a trusted server - the publisher knows everything going to those URLs, anyways

For the trustedScoringSignalsUrl, the lookup keys are identifiers for all of the creatives that are entered into the on-device auction, so the publisher definitely does not know them!

[MattMenke2]

Ah, I had assumed it had its own set of keys in the auction config. That makes implementation significantly more complicated - we don't have a URLLoaderFactory that can safely handle that (Need CORS preflights if made from the publisher site, but can't use the publisher's network partition), which makes correct implementation much more difficult to do and maintain. With process isolation, the 1P opt-in may be less important, but think we likely still want CORS, even with the X-Allow-FLEDGE header.