I mainly wrote this in 2021 to enable TamperMonkey to continue using scripts that have `@require` dependencies on sites with a restrictive `Trusted-Types` policy, until TM v4.14 came out (milestone: https://github.com/Tampermonkey/tampermonkey/issues/1334#event-5361683856). Now it seems like some cases make it relevant again? I think that should be only temporary until the TM team get on top of what ever changed. Make sure this script is executed before the `@require`ing of any dependencies
showing errors like
This document requires 'TrustedScript' assignment.
This document requires 'TrustedHTML' assignment.
? If the whole script breaks before it even started, it may be due to @require scripts that were blocked by a restrictive Trusted-Types CSP (Content Security Policy). This script might help. It also tries to be useful in cases where the script can run, but regular old string assignments are now blocked.
I mainly wrote this in 2021 to enable TamperMonkey to continue using scripts that have @require dependencies on sites with a restrictive Trusted-Types policy, until TM v4.14 came out.
Now it seems like some cases make it relevant again? I think that should be only temporary until the TM team get on top of what ever changed.
Make sure this script is executed before the @requireing of any dependencies
Although TT is still an experimental feature, Google seems quite keen to enforce it already, albeit half-assedly, where supported. Ugh! >.<
This script provides pass-through policies to try to enable you to do what ever you want with the DOM, while trying not to disturb any defaults in place.
Basically, if you have to create your own Trusted Types (e.g. TrustedHTML), and if the site's CSP allows for the creation of new policies, you can use a permissive policy to wrap your strings into a Trusted Type, like TrustedHTML, which the browser will then allow you to assign to the DOM.
Best case scenario: The site has no default policy set. This allows us to specify our own, in which we can then allow everything (pass-through); this will restore all ability to modify the DOM.
If we have to create a custom policy, all contents have to be piped through the relevant function of the TT Policy, like TTP.createHTML("unsafe string contents"), which will then return trusted contents.
Just activate this script, it'll try its best to mend the situation.
If it doesn't work: Try setting overwrite_default to true. This is disabled by default because it might break functionality on the site, if it relies on its own default policy to do something specific.
If it still doesn't work: The site's CSP may have disallowed the creation of our own policies, in which case there's nothing we can do just yet.
Send me feedback with the usual details (url, browser and TM version, output of your Browser Console, etc) to see if there's anything I can do.
See the above points, but if it doesn't work, check if we were able to set our own custom policy, it'll be assigned to the variable TTP.
Instead of using things like
someDomElement.innerHTML += "<div class='myClass'><p>some <b>content</b></p></div>";
use this approach
var e = document.createElement("div");
e.className = "myClass";
e.innerHTML = TTP.createHTML("<p>some <b>content</b></p>");
someDomElement.appendChild(e);
Or, actually, just
someDomElement.insertAdjacentHTML("beforeend", TTP.createHTML("<div class='myClass'><p>some <b>content</b></p></div>"));