Alright ya'll I'm opening up our research into advertising privacy, identity, and cryptographic compliance. This research has been pretty open to people within IAB. But let's open it up to critique, ideas, and questions. Maybe we can get some credit now! https://drive.google.com/file/d/1dCXx_Y4oG9-kIqsEcVX5nkVl4-8B-KEe/view?usp=sharing

There are two paths for the next generation identity frameworks: With PII and Without PII.

First we'll take a look at PII-based ideas we've put forth, particularly a compliance proof framework. This is how Lucidity proves privacy and consent compliance for advertisers.

First, we propose to use pub/private key encryption to non-interactively encrypt PII to consented vendors. Non-consented vendors cannot read PII in OpenRTB.

I call this ads.key since it's used for encryption and not signing. You must use a nonce to avoid creating PII.

So encrypting the PII so that non-consented vendors cannot read it is Step 1: secure the PII.

Step 2: Auditable. This is a very important step. We propose to add digital signatures to the TCF framework (v3.) When vendors in the OpenRTB stream get consent they must store it when doing an action (e.g. bidding, impression, etc.) Signatures make it non-forgeable, like Bitcoin

Step 2 is important, because from the signed consent and action logs vendor can create "roll up proofs". This concept is from Ethereum. You roll-up the proofs like you aggregate data and attach proofs to reports and bills. This is what Lucidity does.

Buyers should require proofs

From Step 2, we can even embed the protocol into OpenRTB itself. But really, if buyers and partners require the proofs when invoicing and making payments there's no need to. However, it is possible to make the auditing and proof verification in real time.

Step 3 is important but probably the most complicated step and that is "Revocability"

Honestly, there's quite a few ways to do this and yes blockchain can potentially help.

So, for DMPs instead of passing around lists of device ids you pass around a private data structure such as a bloom filter. The bloom filter must have a proof of consent attached. This is what Lucidity does as well, really we generate proofs for any big data computation.

And yes we have all of this live today. Cryptography is really cool and useful, blockchain is just a tool you can use to verify and generate proofs. It all depends on how you correctly use it, which is not easy to design!

I care much less about non-PII based approaches, but there's plenty of ideas there as well. I think some of these approaches are just as secure and simpler than FloC!

We'll dive into some of those later.

Also we have some research under "Toy Box" because I don't take those approaches seriously due to their complexity, setup costs, and general inflexibility including:

* Differential Privacy
* Private Set Intersection
* One Time Tokens
* Proof of Stake

Ok ya'll shoot me any questions or hate or whatever.

@thezedwards @aripap @swodinsky @adtechtroll @larakiara

Oh also put in some thoughts on the super cool concept of Trust Tokens, which is going to help finally kill fraud with a probabilistic mechanism.

Forgot @acfou

Also would love thoughts and feedback from @justinschuh @Log3overLog2

And in case you're wondering, yes I'm very very bored.