Context

Up until now, third party scripts need to be modified to allow Orejime to handle them correctly. This implies namespacing regular attributes, labeling them, and ensuring the label matches with the config. This latter part is often causing problems, as the labels must match but there is no way to enforce this over time. This leads to desynchronizations when the code changes, and Orejime still working without errors but not actually acting on the scripts. This is unavoidable with the current architecture but could be mitigated by changing the way scripts are loaded.

Options

Other CMP tend to provide an extensive list of predefined third-party services (think Google Analytics, Matomo, ...) that can inject scripts with little configuration (i.e. a site id). This avoids any desynchronizations, as the CMP is entirely responsible of injecting the scripts. However, it is on the CMP to provide scripts for just about any service, in any given version, which is almost impossible.

A middle ground could consist in moving scripts to the Orejime config, but in the user-land. Instead of setting up regular script tags in the HTML, the user would put their content in the config, in each app declaration. This would let Orejime own their lifecycle without actually providing a predefined list of services.

Example

Before

<script type="opt-in" data-type="application/javascript" data-name="gtm">
  (function(w, d, s, l, i) { /* GTM code */ })(window,document, 'script', 'dataLayer', 'GTM-YOLO');
</script>

const config = {
  apps: [
    {
      name: 'gtm',
      title: 'Google Tag Manager',
      cookies: []
    }
  ]
};

After

const config = {
  apps: [
    {
      name: 'gtm',
      title: 'Google Tag Manager',
      cookies: [],
      // the exact code that we would find in the original script tag
      script: () => {
        (function(w, d, s, l, i) { /* GTM code */ })(window,document, 'script', 'dataLayer', 'GTM-YOLO');
      },
      // an optional list of HTML attributes for the injected script tag
      scriptAttributes: {
        crossorigin: true
      }
    }
  ]
};

Potential issues

Orejime can currently handle any HTML element (see https://github.com/empreinte-digitale/orejime/blob/master/src/consent-manager.js#L213). We'd have to either get rid of this behavior, or provide an alternative.
This would be a breaking change, requiring a rewrite of any user config. Maybe this could be an alternative mode that could coexist with the current one, making it easier to switch. The current one could then be deprecated and removed in the future.

empreinte-digitale / orejime