Telemetry Configuration

Transcend Consent Management sends telemetry about encountered data flows and cookies to Transcend. This telemetry data is used to populate the data flow and cookie triage views in the Transcend Consent Management dashboard.

It may be difficult to classify a given data flow or cookie without a lot of context. To gather information about where a given data flow or cookie was encountered on your site, you can change the Telemetry configuration under Developer Settings.

By default, this option is set to "Origin", which means Transcend Consent Management will only collect the origin of the URL where a cookie or data flow is seen. When set to "Origin and Path", we will collect both the origin and the path, and when set to "Full URL", the entire URL will be recorded.

Let's review an example where Transcend Consent Management is running at the site xyz.com and a user visits https://xyz.com/signup?firstTime=true&lang=EN. On this page, suppose the cookie _abc_tracker is set by some SDK running on the site. Transcend Consent Management will record where this cookie is encountered, but the content will differ based on your configuration:

• Origin: The cookie _abc_tracker is encountered at xyz.com
• Origin and Path: The cookie _abc_tracker is encountered at xyz.com/signup
• Full URL: The cookie _abc_tracker is encountered at xyz.com/signup?firstTime=true&lang=EN

Full URL will provide the most context but runs a high risk of collecting personal information. We recommend that you enable at least "Origin and Path" while setting up your Transcend Consent.

Note

"Encounters" information collected for a cookie is different from the "Domains" of a cookie. The latter refers to the domain attribute of the cookie.

Telemetry can be suppressed on a per-event basis using regular expressions and/or runtime conditions.

Define airgap.suppressTelemetry.{requests, cookies}: RegExp[] prior to airgap.js initialization to suppress telemetry for specific events whose URLs or cookie names match listed regular expressions.

Define airgap.suppressTelemetry.requestConditions: ((event: PendingEvent) => boolean)[] prior to airgap.js initialization to suppress telemetry based on runtime conditions. Return true in a handler function to suppress telemetry for a specific event.

The following example demonstrates suppressing telemetry for known events using all of our suppression APIs.

self.airgap = {
  suppressTelemetry: {
    requests: [
      // Suppress telemetry for requests ending in ".webm"
      /\.webm$/,
    ],
    cookies: [
      // Suppress telemetry for cookies starting with "test_"
      /^test_/,
    ],
    requestConditions: [
      // Suppress telemetry for requests triggered by <video> elements
      (event) => event.target instanceof HTMLVideoElement,
    ],
  },
};

Starting with airgap.js version 9.1, unknown data flows and cookies are traced to determine whether they originated from end users' browser extensions, and if so they will not be reported to telemetry. This helps prevent false-positive data flows and cookies from appearing in your triage view and necessitating the classification of these entries as "junk". This behavior is on by default, and can be disabled using the data-tfpf="off" data attribute on your airgap.js script.

This functionality is only available in browsers that allow the JavaScript runtime to see the script locations corresponding to end users' browser extensions. This is the case for any Chromium-based browsers (Chrome, Edge, Brave, Opera) as well as Firefox. Safari prevents the JavaScript runtime from seeing these script locations, so telemetry false positive filtering cannot be enabled in those contexts and may leak through false positive data flows and cookies. If you wish to disable data flow and cookie telemetry in browsers that don't support extension filtering, add data-require-tfpf="on" to your airgap.js script tag.

Chromium-based browsers offer a more extensive API to allow access to these script locations, but it can come at the cost of performance. Since this telemetry reporting is only done for unknown data flows or cookies, this is a particular concern for sites that still have many data flows or cookies left in Triage. That said, we limit the number of stack frames that we check for browser extension signatures in to avoid a performance impact on your site while still protecting you from these false reports. This balance can be different for customers more or less sensitive to performance or false positives, so we expose a data attribute data-tfpf-stack-limit to help with you achieving that balance on your own. The default is "10", and you can choose to lower it (or disable the feature entirely) if performance is a concern, or raise it to any arbitrary integer (or "Infinity" if you want to capture all stack frames) to avoid all false positives from Chromium-based browsers.