(while we work this out via email I thought I'd post this answer)
The root cause here is a major change in 3.3.3, released April 6th 2015.
> Work to close a number of script injection holes. URLLoader will now HTML
escape all arguments passed on the URL, and specific form element modules
do some extra work to nonetheless correctly prepopulate their selections.
You can also see it in the release notes here:
http://sideviewapps.com/apps/sideview-utils/release-notes/
The dashboards having the problem here after the upgrade were taking a $foo$ token that had come from the page URL, via URLLoader, and were plugging that value into HTML and Javascript that an HTML module was constructing on the page. And in such a way that the $foo$ token needed to be un-escaped HTML (specifically the argument was going into an argument to a subsequent URL).
Unfortunately this use case is itself inherently a script-injection hole. ie, it is easy to construct a URL to such a page that an attacker could use to make that page's link do something malicious.
The solution will be to ultimately rewrite the functionality a bit. The solution that I'd probably use would be to use a Link module instead of the HTML module to make the link on the page, and then attach a customBehavior to that Link module to retrieve the $foo$ token from the context and do the application logic onclick. However it's possible that a Link module and a Redirector (mod some ValueSetter modules) could also do the same job without any custom JS.
I'll probably update again after our private email thread gets to a full solution.
