Subresource Integrity

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match. This definition is sourced from MDN Web Docs, where you can find full documentation on SRI.

In many cases, an SRI requirement stems from strict security compliance for enterprise-level policies. Though it adds a layer of certainty that the file you are expecting matches precisely what is delivered, in many cases, the overhead for managing SRI is not worth the investment.

Lytics deploys features, fixes, etc. to all of our customers as fast as possible, which means the exact code delivered by our core JavaScript Tag endpoints can change often. These incremental improvements are excellent in every case except for SRI. As such, we recommend that the Lytics JavaScript Tag source file be hosted at a secure location capable of handling the traffic volumes that your web properties generate. With this approach, you gain control over when the file and hashes need to be updated, which will reduce downtime.

To access the proper file to download, you'll need to look at the default JavaScript Tag configuration provided in your account. Part of that snippet will include a configuration object which consists of a src definition. For Version 3, the latest version of the Lytics Tag, that will be //c.lytics.io/api/tag/{{ACCOUNT_ID}}/latest.min.js. In most cases, HTTPS should be used as the protocol before the // and your account ID will replace {{ACCOUNT_ID}}.

Also, the JavaScript snippet that we recommend you copy and paste into your Tag Manager or source code will need to be slightly altered manually.

1. The src referenced above will need to be updated to point to the source of your newly hosted copy of the Lytics JavaScript Tag endpoint.
2. Within that snippet, we generate a script tag, loadScript, which is ultimately responsible for loading the file. In the case of SRI, there are additional requirements that will need to be defined, such as integrity and crossorigin. These can generally be included after the existing createElement call using setAttribute.

Again, it is essential to consult your development team here as Lytics will not be able to provide technical support for custom modifications to our core JavaScript Tag.

Once you have the proper attributes set to activate SRI with the expected hash, things should be up and running. Changes made to the core tag will be reflected only after a manual sync on your end.

With this approach comes a few significant implications:

1. Account settings altered in the Lytics UI will only be reflected after the tag has been synced and SRI hash updated. Most settings updates result in small alterations to variables in the core tag file.
2. Lytics Support will be able to offer limited assistance. In the case of bugs, issues, etc. our support team will not be able to utilize existing methods to assist you. Since the file is custom and hosted outside of Lytics, you must do so at your own risk.
3. Bug fixes or feature availability will be dependent on your team's ability to update the external files and associated SRI hashes.