SmartClient requires unsafe-eval and/or unsafe-inline in the CSP

[Azar]

Dear Isomorphic Team,

I am writing to request official documentation and technical clarification regarding SmartClient’s Content Security Policy (CSP) requirements, specifically the need for unsafe-eval and/or unsafe-inline.
In particular, we are looking for detailed information on:

• Why SmartClient requires unsafe-eval and/or unsafe-inline in the CSP.
• What specific technical mechanisms ensure that this usage is safe, including:
  • How dynamic code generation is performed
  • What guarantees exist that no user‑controlled input is ever executed
  • What internal sandboxing, validation, or controlled execution paths are used
  • Any architectural constraints that prevent exploitation

We are operating in an environment with strict security and compliance requirements, so having official, detailed documentation from Isomorphic on these points is essential for our security review and CSP design.
If there are existing whitepapers, security guides that can address these topics, we would greatly appreciate access to them.
Alternatively, a formal statement or knowledge base article covering the above points would also be very helpful.
Thank you in advance for your assistance and for any materials you can provide.

Best regards,
Azar

[Isomorphic]

This is already discussed in depth here:

https://forums.smartclient.com/forum...-clarification

In a nutshell, supporting these restrictions does not increase safety in any meaningful way, and would only serve to cripple the product, slow it down, and make it more difficult to work with. It would also take a lot of initial and ongoing engineering effort, pure waste.

Let us know if you want a more in-depth answer than is already supplied in the linked thread (which is already pretty in-depth). Just note that we would consider that a waste as well, because paying for the product to be crippled is not in your budget.

[Azar]

To clarify, we are not asking for any changes to the framework itself. Our goal is simply to ensure we can provide accurate, consistent explanations to customers when they ask why these CSP directives are required.

To support this, we would greatly appreciate:

• An official documentation page, or
• A technical bulletin/statement

that outlines the technical reasons behind the framework’s reliance on unsafe-eval and/or unsafe-inline.

This would be extremely helpful for us, as we also provide this information to customers evaluating our Device Management product, which has been using the SmartGWT framework successfully for the past two years. Having an authoritative reference from Isomorphic strengthens our ability to address customer concerns and reinforces confidence in the underlying technology.

Please let us know if such documentation already exists or if it would be possible to publish something we can share.

Thank you for your support.

[Isomorphic]

The previously provided forums list is already an authoritative reference, but if you want to spend a few hours having us take exactly the same information and reformat it so that it is part of the reference (so would appear in the JavaDoc), we can do that - let us know.

Just as a side note, our stance on CSP is the most common one amongst advanced UI frameworks.

It's widely acknowledged that the committee who came up with the name "unsafe-eval" made a huge blunder which has wasted a lot of people's time.