I'm building a CMS system and I want to restrict third party javascript includes that users can embed within their site.
I will use tracking as an example scenario as it best describes what I want to achieve.
Defining "blocked": Where the script cannot interact with any elements on the page (i.e. watch form elements and catch data from submitted forms) or user visits where the data is obfuscated and fundamentally useless.
So, with the above example in mind I would expect that the functionality of Tableau to be reduced. Things like Heatmap reports would no longer work (as we are blocking interaction with the DOM the client events should not work). Also I assume looking at the architecture of Caja a visit would appear to come from the Cajoled service and not from the users browser?
Looking at Google Caja it seems it may be the choice, but the focus is always around entire HTML/CSS/JS (a gadget/app) where what I'm looking for is slightly less reduced in that sense. Perhaps there is an alternative solution
Is it something that can be setup to be generic, or does it need specific work for every white-list/black-list item?
EDIT - Looking at it, there are various types of sandboxing scripts available but they all look relatively unsupported or in per-production stages of their development.
JSandbox https://github.com/eligrey/jsandbox
Caja will not do all of what you want “out of the box”, but there's a good chance it has useful components for your sandbox.
Caja itself does not at all support your proposed “whitelisted scripts” model; the guiding principle is that no code should be “trusted” more than it needs to do its job, and so we focus on authorization based on the intended use of a program, not the author of it. If you want a whitelist of full-page-access scripts then that is something you will need to build yourself, but it wouldn't be that complex a problem and probably needs to integrate closely with your CMS anyway.
Now, supporting running scripts with “reduced” functionality is something Caja can help with. However, it's unclear exactly what sort of reduction you want.
If all you want to do is run code and get data input/output, then just SES is sufficient to handle that easily; all sandboxed code in Caja is automatically run under SES, or if it suits your application you can load SES without Caja, which is slightly lighter weight but requires more understanding of how to write capability-safe JavaScript.
(This is also the same role which the other JS sandboxes you mentioned fill. Compared to the other options you mention, SES probably (I haven't looked at them in detail) makes it easier to support close interaction with the sandboxed code, such as function calls both ways with no asynchronous callbacks involved.)
If you want to provide filtered access to simple APIs, then Caja can do that easily using the “taming” facility.
On the other hand, if you want to provide limited access to the DOM of an existing page, then Caja has nothing ready-made for you, but might be modifiable for the purpose. As you've apparently noticed, Caja's DOM taming layer is focused on giving the sandboxed code complete control of a fragment of the page, not access to selected aspects of the entire page. Doing this would require some modification. (One case that would be particularly easy to support, if it is of interest, is to provide read-only access to the entire page; Caja supports this for its own needs, but there just doesn't happen to be a published way to ask for it.)
If you are still interested in using Caja, I recommend you start a discussion on google-caja-discuss and describe exactly what kind of reduced functionality you want to support.
Disclaimer: I work for Google on the Caja project, but this post is entirely my own perspective and opinion.