Consider an encryption scheme that keeps the user data out of website author hands

[broggeri]

e.g., share a website-specific encryption key between the various tech vendor of a website (operator, CMP, adserver, SSP., DSP..).

This also suggest that the wording below should be adapted: https://github.com/criteo/addressable-network-proposals/blob/ef04286eb1a8f20ed387f4594389b786556eb4ee/mvp-spec/operator-design.md?plain=1#L13

=> no decryption is needed by website. Decryption might stil be needed by e.g. the SSP. The benefit is still there: it's possible to handle the payload through client side javascript until it reaches the SSP.

[OlivierChirouze]

I've made some progress on this requirement.

Objective

The objective is that for some publishers,

• no readable data is stored as 1st cookie party
• no readable data is available in the browser

In other words, Prebid data is encrypted for these publishers and can only be decrypted by backends, when needed (to get consent by CMP, to display existing preferences by CMP, to bid by ad server)

Changes

Big picture (and to build on the existing proposition), it would mean the following changes in the current design & API:

• when the operator receives a request to read data from a "sender", if a secret key is associated with this sender then encryption is activated
• when encryption is activated, the returned ID and preferences are encrypted with the sender's secret key. In this case the data model is different, for example:

in this case, instead of:

{
  "sender": "operatorO.com",
  "timestamp": 1639059692793,
  "signature": "message_signature_xyz1234",
  "body": {
    "preferences": {
      "version": 0,
      "data": {
        "opt_in": true
      },
      "source": {
        "domain": "cmpC.com",
        "timestamp": 1639643112,
        "signature": "preferences_signature_xyz12345"
      }
    },
    "identifiers": [
      {
        "version": 0,
        "type": "prebid_id",
        "value": "7435313e-caee-4889-8ad7-0acd0114ae3c",
        "source": {
          "domain": "operator0.com",
          "timestamp": 1639643110,
          "signature": "prebid_id_signature_xyz12345"
        }
      }
    ]
  }
}

the response would look like:

{
  "sender": "operatorO.com",
  "timestamp": 1639059692793,
  "signature": "message_signature_xy48789799",
  "body": {
    "encryptedPreferences": {
      "value": "A3NpbmdsZS41MWRjLnVrAC...CfXor0v9Y1R+NzY8z1k=",
      "encrypter": "publisherP.com" 
    },
    "encryptedIdentifiers": [
      {
          "value": "HijVo2mQtOst1durTtajwevb_V480ODx...dZy32NIkXH414nhdE9K1JFyiVU",
          "encrypter": "publisherP.com"
      }
    ]
  }
}

• Signature algorithm for the "read" response also needs to evolve to handle possible encrypted values.
  • Signature of the response would probably be based on the concatenation of:

sender + '\u2063' +
receiver + '\u2063' +
preferences.source.signature + '\u2063' +
encryptedPreferences.value + '\u2063' +
identifiers[0].source.signature + '\u2063' +
identifiers[1].source.signature + '\u2063' +
...
identifiers[n].source.signature + '\u2063' +
encryptedIdentifiers[0].value + '\u2063' +
encryptedIdentifiers[1].value + '\u2063' +
...
encryptedIdentifiers[n].value + '\u2063' +
timestamp

• the encrypted value is an encryption of a serialization of the full identifier or preferences object, including its source
  • this is because once decrypted, the object must be verifiable
• when the website client receives data, it can write it as a local cookie, but only the encrypted value is stored
  • it is useful to write it as a 1st party cookie to avoid querying the operator again and again: having a cookie named "prebid id" with value encrypted means PAF has already been queried
• in this configuration, id and preferences are never read in the browser
• the data can be decrypted but only by a backend, for example by the ad server. This ad server needs to have the secret key that was used for encryption
• to remain consistent, the write endpoint must also be adapted to accept encrypted ids and preferences
  • and the signature algorithm must also be adapted

Challenges / issues

• need to clarify how the CMP manipulates clear data, but the publisher that triggers the CMP display does not have access to this data
• when encryption is active for a publisher, readable data cannot be accessed in the browser. Is this never an issue?
• when the website client receives encrypted data from the operator, is it useful to verify the response's signature?
  • because either data has been rightfully encrypted by the operator and only the operator or the publisher can decrypt it, or a man in the middle has encrypted data but in this case it won't be possible to decrypt it anyway.
  • option? include the encryptedPreferences.encrypter and encryptedIdentifiers[1].encrypter in response signature.
• the encryption of the audit log needs to be tackled as well: if id & preferences are encrypted but the audit log (and its seed) is received "clear", then that's a security hole.