ATS Security and Pseudonymization

When an identifier is provided to or detected by ATS.js, it can be in plaintext or hashed form. If the identifier is hashed, no further transformations are applied. If a plaintext identifier is detected or passed in the configuration, ats.js uses Web Crypto API to create SHA1 and SHA256 hashes. A native JavaScript implementation is used to create an additional MD5 hash, which is the only hash generated if the user is on a non-TLS origin.

In the European Union/European Economic Area, ATS requires a Transparency and Consent Framework (TCF) v2 string with LiveRamp listed as a vendor for all claimed purposes for envelope retrieval. In the U.S., ATS will honor the settings contained in a California Consumer Privacy Act (CCPA) string but does not currently require its presence. These consent checks are performed on both the client (ATS.js) and the server (ATS API).

Once the hashes have been created, ATS.js makes a call to the ATS API cross-origin resource sharing (CORS) endpoint. The hashes are passed as URL parameters along with consent data, where applicable.

The API can only be reached over SSL/TLS. Calls made to the insecure endpoint are upgraded to TLS.

ATS is designed to process only the data absolutely necessary to operate and to only retain aggregated information. The following attributes are consumed by LiveRamp when processing a request:

The input hashes are resolved to Anonymous Representation Links (ARLs), a salt and SHA256 hash of the input. The ARL is used to look up the corresponding RampID (more specifically, the zero-encoded pseudonymized Abilitec CLINK) in a key/value store backing the API.

If a matching RampID is not found, a is created on the fly using the newly-created ARL as an input. Even though this ARL does not exist within the offline graph, the "derived" RampID remains consistent and can still be matched with advertiser-submitted data due to the deterministic nature of the identifier.

"Raw" encrypted RampIDs are not returned to the client. Instead, the RampIDs are additionally obfuscated and encrypted to protect the underlying information in transit and while in client-side storage.

Envelopes have two main components: header and payload. The header of the envelope includes unencrypted components that are required to determine the method of decryption of that particular envelope. The payload is the encrypted portion of the envelope, containing the identifier information along with an initialization vector. The initialization vector ensures that even when the same underlying information is represented, observers cannot derive any insight regarding the envelope's contents.

Once serialized using protobuf, the bytes of the payload are encrypted using AES/CTR 128. The header and payload bytes are then concatenated and Base64 encoded.

Envelopes must be decrypted for use by buyers downstream. Envelopes are processed server-side by SSPs who have deployed LiveRamp Sidecar, a containerized Docker application. Each Sidecar "account" is assigned a certificate that is used to create a secure connection to LiveRamp services which allowlist specific IPs or IP ranges to pull down encryption keys.

Sidecar decrypts the base64-decoded envelope to obtain the underlying RampID. Then, depending on which encryption keys have been provisioned for that Sidecar account, the underlying RampID is encrypted with a unique encryption key and output from Sidecar.

ATS.js supports Subresource Integrity (SRI). SRI is a security feature that enables browsers to verify that resources they fetch are delivered without unexpected manipulation. See this article on 'Subresource Integrity' to learn more.