Utilizing Confidential Computing Hardware On Device, on "edge"(lc intentional)

[thegreatfatzby]

@rdgordon-index and @michaelkleber et al, I've been thinking about #824 a bit recently. The specific issue there is exposure of rate cards, pricing logic, and generally anything that would give a competitor insights you don't want to give them. To abstract this a bit:

The Party (seller) would like to execute some logic (scoreAd/reportResult/rate-cards) that it owns, in an environment that it doesn't own (consumers device), and will trust the environment if it can make certain Claims about protection of that data (non-exfiltration) that can be Relied on.

If you buy that generalization, to me it sounds like a Confidential Computing problem. To oversimplify, if executed on a platform running CC Hardware, the Publisher could release it's code and data only to an environment that attests as running some known supervisor that encrypts the running process, prevents access, etc.

But where?

Consumer Device CC

In the case of the On Device PAAPI Auction, one place to start would be on device. Some (see below) current consumer devices do include CC hardware, so in those cases Chrome could execute publisher code in an enclave. There are a few ways this could work but one would be that Chrome spins up code that will simply pull down and execute the publisher code/data; that code would be publicly attested and approved by Ad Tech God or some equivalent, and the publisher could then trust their logic would execute in an encrypted process that won't exfiltrate it's stuff; the publisher would encrypt their code/data similar to how IGs are encrypted, and only release keys to the attested Chrome Adapter process.

So I'm curious:

• For the Chrome folks how you'd think about Chrome itself integrating with CC hardware when running on an OS that allows that access?
• For SSP folks I'm curious how this would strike you from a security perspective? The guarantee would be strong, although not literally perfect.

Sadly, consumer devices don't yet universally have CC hardware like SEV, TDX, or SGX (especially for the VM based ones, and SGX seems to be losing favor), and ATM Apple doesn't give direct developer access to TrustZone. So a second possibility I'm curious to discuss...

Edge Workers Running on CC

I wonder if there might be an interesting baby splitting opportunity here for SSPs that would like to participate in on device auctions (maybe they have demand that wants to experiment), but don't want to trivially expose their logic and data.

Hypothetically Chrome could talk to an edge worker running in some Point of Presence that could run scoreAd and/or reportResult. The POP provider would have to be running some "CC Edge Cluster", but ultimately Chrome and Publisher would release their data after a similar attestation that Chrome does with BA, KV, etc, today. Similar to ^ there's a couple of ways to imagine this: but most basic would be Chrome has a small Attested Adapter that can receive scoreAd, reportResult, etc, and the SSP can deploy that with it's UDF to an edge worker (no publisher attestation needed); Alternatively the edge worker could stay very generic and pull down the UDF from the SSP(s), and the SSP would only release keys to decrypt its data after attestation.

Some upsides would be:

• SSP logic/data is now not exposed on the client, but SSP and DSP can try to innovate with on device as feature sets improve.
• SSP gets this w/o having to standup a full TEE cluster.
• The ecosystem now allows for more surgical use of "server side" TEEs w/o the entire flow moving there, requiring a minimum of 4 hosts, per hop asymmetric encryption/decryption, etc.
• Even in the hypothetical presence of 100% consumer market CC coverage, a particularly security conscious SSP could still use this to participate in on device but maintain greater control.

Servers, even edge servers, cost money of course. Additionally were this used for scoreAd a major downside would be added latency in the critical path; for reportResult (or other of the report* family) the impact on user facing latency could be played with.

So I'm again curious for both the Chrome and other SSP perspectives. When I was at Fastly XCellerate a few weeks ago I spoke with some of their senior engineers about confidential edge workers and there was qualified interest. That led to me saying I would start this ticket and try to get them to one of our meetings with folks to discuss if we also have qualified interest.

So curious what qualified interest there is on our side.

Addenda

I wanted to start with something concrete, but I could definitely see value in browsers leveraging on device CC hardware in other ways; edge works too I suppose, with more tradeoffs to analyze.

[michaelkleber]

I am skeptical of bringing on-device confidential computing into the picture here. Browsers did indeed decide to launch a DRM mechanism, Widevine, in order to get video streaming; this was quite controversial but ultimately justified based on lots of browser-users really wanting video streaming. I have a hard time believing that there is any similar groundswell of user demand here.

Regarding server-side TEE environments, of course B&A goes all-in on this direction, while you're asking about doing small steps instead. ysMy instinct is that the small-steps version seems like it would run into substantial engineering challenges due to both round-trip latency and the amount of data that you would need to ship around. Basically, B&A pays some overhead cost along these lines, but gets fast server-to-server interactions to make up for it. It seems like your version incurs most of the cost and gets only a small fraction of the benefit.

It's entirely possible that I'm wrong here, and the trade-offs are more favorable than I'm predicting. If you have reason to think so, then sure, let's talk more; this seems philosophically aligned with the other uses of TEEs in Privacy Sandbox. But this feels to me like a harder sell than B&A in a similar design space.