IDFA/AAID with strange format after decrypted about openrtb-doubleclick HOT 5 CLOSED

This behavior has changed as a consequence of AdX's enforcement of SSL transport, which allowed us to offer non-encrypted fields for sensitive information since the entire message is now protected by HTTPS. For example, instead of using encrypted_advertising_id, you can use the new field advertising_id. (Or the constrained_usage_* variants of both for COPPA requests, so it's actually 4 fields, only one will be present in any message.) The OpenRTB mapper will map all those fields identically, in this case to Device.ifa.

I guess you are decrypting values that are not encrypted, this will certainly produce strange results. You can now just use these values directly without the decryption step. The DoubleClickCrypto utility is being supported until we completely phase out support for plain HTTP, at least for the bid request data since you still need to decrypt winning prices.

from openrtb-doubleclick.

Thank you for your response. I checked advertising_id and it's a 16 byte field, so it's again a 32 chars hexadecimal. Should I assume it's an IDFA/AAID without hyphens?

To clarify, I am expecting something like: 54f00b25-33cd-4b94-982d-c6737fc89031 and I am receiving like b494e73421fe4bcb988af60bcee8485c (just format, not real examples)

from openrtb-doubleclick.

That's correct, AdX doesn't bother with the hyphens since the field is binary anyway in order to be as compact as possible. So the full story is that you get a Websafe-Base64-encoded string, which you can decode to get a 16-byte array which you can finally format as hexadecimal and insert hyphens in the proper positions if you need to match that to standard formatted IDFA/AAIDs.

BTW sorry for requiring two steps of conversions, it may seem simpler if ifa was already populated with the hexadecimal representation (older versions of the library did that indeed). But we use Websafe-Base64 for every binary field because this choice is pervasive inside AdX; which means for example that all our logs, reports, etc., both internal (which TAMs can access) and in things exposed to users, will be using this representation for binary fields. So if we use a different representation here, this could make some support/debugging workflows more confusing. Not to mention that we're also implementing OpenRTB natively, and base64 is more compact than hex which is important on the wire.

from openrtb-doubleclick.

Whoa, please ignore the last paragraph above. We never used base64 here, this was something internal that was later fixed to use hexadecimal. (The OpenRTB spec of these fields is not specific, but examples use hex and it's also a de facto standard with other implementations so we're going with hex too.)

from openrtb-doubleclick.

Than you so much Osvaldo!

from openrtb-doubleclick.