
package com.smartgwt.client.docs;

/**
 * <h3>Content Security Policy (CSP)</h3>
 * <h3>Content Security Policy (CSP) and Component Frameworks</h3>
 *  <P>
 *  The browser Content Security Policy mechanism includes <code>script-src</code> directives
 *  such as <code>'unsafe-eval'</code> and <code>'unsafe-inline'</code> that restrict the use of
 *  <code>eval()</code>, <code>new Function()</code>, inline event handlers, and dynamic script
 *  loading.  These restrictions were introduced to mitigate injection attacks in applications
 *  where untrusted user input is carelessly concatenated into executable code &mdash; a class
 *  of vulnerability that arises primarily from naive application-level coding practices, not
 *  from the use of mature, security-audited frameworks.
 *  <P>
 *  Smart GWT does <b>not</b> currently support running under a CSP policy that disables
 *  <code>unsafe-eval</code> or <code>unsafe-inline</code>.  This is a deliberate architectural
 *  decision, not an oversight.  The sections below explain why.
 *  <P>
 *  <h3>Why CSP Provides No Meaningful Security Benefit for Component Frameworks</h3>
 *  <P>
 *  CSP's <code>script-src</code> directives were designed to protect against a specific
 *  threat: an attacker who can inject a string into an HTML page such that it is executed as
 *  code.  This threat is real when application developers use patterns like:
 *  <pre>
 *      element.innerHTML = "&lt;img onerror='steal(document.cookie)' src=x&gt;";
 *      eval("processData(" + userInput + ")");
 *  </pre>
 *  <P>
 *  In a Smart GWT application, developers do not write code like this.  The framework
 *  manages all DOM rendering, event handling, and server communication through controlled
 *  internal pathways.  User-supplied data flows through typed DataSource fields, validated
 *  both client- and server-side, and is never interpolated into executable contexts.  The
 *  attack surface that CSP was designed to close simply does not exist in a properly built
 *  Smart GWT application.
 *  <P>
 *  Smart GWT has been deployed by major banks, defense contractors, intelligence agencies,
 *  and financial institutions worldwide for over two decades, passing hundreds of independent
 *  security audits, with no history of meaningful injection exploits against the framework
 *  itself.  This real-world security track record is far more significant than compliance with
 *  a header that addresses an inapplicable threat model.
 *  <P>
 *  <h3>Most Advanced Frameworks Cannot Fully Support CSP</h3>
 *  <P>
 *  Smart GWT is not unusual in this regard.  The more capable and feature-rich a JavaScript
 *  framework is, the more likely it is to rely on dynamic code generation for core
 *  functionality.  Among major frameworks:
 *  <ul>
 *  <li><b>Vue.js and Ember.js</b>: Both rely on
 *      dynamic template compilation at runtime, which
 *      requires <code>unsafe-eval</code>.  Avoiding it
 *      requires a precompilation build step that eliminates
 *      runtime template compilation entirely, meaning
 *      templates cannot be composed or modified dynamically
 *      at runtime.</li>
 *  <li><b>Angular</b>: The JIT (Just-In-Time) compiler
 *      requires <code>unsafe-eval</code>.  The AOT
 *      (Ahead-Of-Time) mode avoids it, but at the cost of
 *      eliminating dynamic template compilation, requiring a
 *      heavyweight precompilation build, and producing larger
 *      deployment bundles.  Many Angular libraries and
 *      plugins still assume JIT availability.</li>
 *  <li><b>Ext JS / Sencha</b>: Uses dynamic code generation
 *      extensively for templates, formulas, and data binding,
 *      and does not fully support strict CSP.</li>
 *  </ul>
 *  <P>
 *  Frameworks that do claim full CSP support tend to be either much simpler (providing no
 *  comparable dynamic features), or they achieve compatibility only through a precompilation
 *  step that sacrifices the ability to compose, modify, or generate UI definitions at
 *  runtime.  Every framework that has undertaken CSP compatibility documents resulting
 *  performance penalties, increased bundle sizes, and reduced runtime capabilities.
 *  <P>
 *  <h3>Capabilities and Performance Lost Under CSP Restrictions</h3>
 *  <P>
 *  Smart GWT uses <code>eval()</code>, <code>new Function()</code>, and related facilities
 *  for their intended purpose: high-performance code generation, powerful dynamic features,
 *  and runtime flexibility.  These are not naive uses of dangerous APIs &mdash; they are
 *  deliberate architectural choices that deliver significant value.  Disabling them would
 *  degrade or eliminate the following capabilities:
 *  <P>
 *  <b>User-Defined  Formula Fields,
 *   Summary Fields, and
 *   Dynamic Properties</b>
 *  <P>
 *  End users can define calculated grid columns using
 *  spreadsheet-like formula expressions (e.g.,
 *  <code>A + B * 0.1</code>) and summary templates (e.g.,
 *  <code>#{lastName}, #{firstName}</code>).  These are
 *  compiled into JavaScript functions for evaluation on
 *  every grid row.
 *   Dynamic Properties
 *  use the same mechanism: a component property value can
 *  be computed from data values and other application
 *  context via a {@link com.smartgwt.client.widgets.UserFormula} or
 *  {@link com.smartgwt.client.widgets.UserSummary} expression &mdash; for example,
 *  deriving a grid column's
 *  {@link com.smartgwt.client.widgets.grid.ListGridField#getTitle title} from a formula like
 *  <code>ruleScope.currentUser.region</code>.  Without
 *  dynamic code generation, none of these user-defined
 *  function capabilities would be available.
 *  <P>
 *  <b>Server Communication Performance</b>
 *  <P>
 *  Smart GWT uses an optimized pseudo-JSON serialization format for server responses that
 *  supports JavaScript Date constructors and other non-strict-JSON constructs.  Deserializing
 *  these responses falls back to <code>eval()</code> when <code>JSON.parse()</code> cannot
 *  handle the format.  Under CSP restrictions, every server response would need to use strict
 *  JSON, requiring additional server-side serialization overhead and client-side date
 *  reconstruction, measurably slowing all DataSource operations.
 *  <P>
 *  <b>The {@link com.smartgwt.client.docs.Debugging Developer Console}</b>
 *  <P>
 *  The Smart GWT Developer Console is a powerful debugging tool that allows developers to
 *  evaluate arbitrary JavaScript expressions against live application state, inspect component
 *  trees, watch DataSource traffic, and profile performance.  All of this depends on dynamic
 *  code evaluation.  Without it, the single most important tool for diagnosing issues in
 *  running Smart GWT applications would be non-functional.
 *  <P>
 *  <b>{@link com.smartgwt.client.docs.Reify Reify} (Low Code Visual Builder)</b>
 *  <P>
 *  Reify enables visual, drag-and-drop application construction that generates Smart GWT
 *  component trees from declarative screen definitions.  Screens loaded from the server
 * (via {@link com.smartgwt.client.rpc.RPCManager#loadScreen RPCManager.loadScreen()} and {@link
 * com.smartgwt.client.rpc.RPCManager#createScreen RPCManager.createScreen()}) are instantiated
 *  by evaluating their JavaScript representation at runtime.  CSP restrictions would make it
 *  impossible to load or create screens dynamically, defeating the purpose of the tool.
 *  <P>
 *  <b>{@link com.smartgwt.client.docs.IntegratingAI AI Integration} and
 *   AI-Generated Components</b>
 *  <P>
 *  Smart GWT's AI features allow natural-language operations like filtering grids, adding
 *  calculated columns, and generating entire data-bound components from user descriptions.
 *  The AI engine produces JavaScript component definitions that must be dynamically evaluated
 *  to create live UI.  Chain-of-Thought prompt templates also use dynamic expression
 *  evaluation for variable interpolation.  These features are fundamentally incompatible with
 *  CSP <code>eval</code> restrictions.
 *  <P>
 *  <b>The FileLoader and Dynamic Module Loading</b>
 *  <P>
 *  FileLoader supports background loading and caching of JavaScript and CSS resources
 *  to optimize application startup time.  The <code>scriptInclude</code>
 * {@link com.smartgwt.client.types.RPCTransport RPC transport} enables cross-domain communication
 * by dynamically
 *  injecting <code>&lt;script&gt;</code> tags.  Both mechanisms are restricted under strict
 *  CSP policies.
 *  <P>
 *  <b>Internal Performance Optimizations</b>
 *  <P>
 *  Throughout the framework, <code>new Function()</code> is used to generate optimized
 *  accessor functions, criteria evaluators, and serialization routines.  These dynamically
 *  compiled functions are significantly faster than interpreted alternatives because the
 *  JavaScript engine can JIT-compile them with full optimization.  Replacing them with
 *  generic, data-driven alternatives would produce measurably slower execution across many
 *  hot code paths, including DataSource filtering, record validation, grid rendering, and
 *  sort operations.
 *  <P>
 *  <h3>Effective Alternatives to CSP for Application Security</h3>
 *  <P>
 *  Rather than crippling the framework to comply with a policy that addresses an inapplicable
 *  threat, organizations concerned about application-level code quality have several effective
 *  alternatives:
 *  <ul>
 *  <li><b>Static analysis</b>: Tools like ESLint (and dozens of alternatives) can enforce
 *      rules that prohibit <code>eval()</code> and similar patterns in
 *      <i>application-level</i> code, which is where injection risks actually originate.</li>
 *  <li><b>Strict mode</b>: JavaScript <code>"use strict"</code> prevents certain unsafe
 *      patterns at the language level.</li>
 *  <li><b>TypeScript and ES6+ tooling</b>: Type checking and module systems used for
 *      application code naturally prevent the string-interpolation patterns that lead to
 *      injection vulnerabilities.  Smart GWT has excellent
 *      {@link typeScriptSupport TypeScript support}.</li>
 *  <li><b>Code review</b>: Security-sensitive organizations already mandate code review,
 *      which catches injection patterns far more reliably than blunt runtime restrictions
 *      that also disable legitimate framework functionality.</li>
 *  </ul>
 *  <P>
 *  These approaches target the actual source of risk &mdash; application code written by
 *  developers who may be inexperienced with security &mdash; without degrading the
 *  capabilities of battle-tested framework code.
 *  <P>
 *  <h3>Official Stance and Feature Sponsorship</h3>
 *  <P>
 *  Smart GWT does not plan to add CSP <code>unsafe-eval</code> compatibility to its
 *  roadmap, because doing so would mean permanently maintaining a crippled, slower variant
 *  of the framework with no genuine security benefit.
 *  <P>
 *  However, for customers who face an intractable organizational requirement for CSP
 *  compliance, we offer the possibility of creating a restricted mode through our
 * <a href='https://www.smartclient.com/services/index.jsp' target='_blank'>Feature
 * Sponsorship</a>
 *  program.  Such an effort would produce
 *  a version of the framework that can run under <code>unsafe-eval</code> restrictions, with
 *  the following caveats:
 *  <ul>
 *  <li>A significant subset of features (including the
 *      Developer Console, user-defined formula and summary
 *      fields, Dynamic Properties, Reify screen loading,
 *      AI-generated UI, the <code>scriptInclude</code>
 *      transport, and others) would be <b>unavailable</b>
 *      in this mode.</li>
 *  <li>Server communication, DataSource operations, and component rendering would be
 *      <b>measurably slower</b> due to the elimination of dynamically compiled code paths.</li>
 *  <li>Certain browser-specific workarounds that currently use dynamic code generation would
 *      be removed, potentially introducing <b>new edge-case bugs</b> related to memory
 *      management and accessibility.</li>
 *  <li>The resulting restricted mode would <b>not be backwards compatible</b> with existing
 *      applications that use any of the affected features.</li>
 *  <li>Because the full-capability and restricted modes would need to be maintained
 *      in parallel, Feature Sponsorship for this work involves substantial <b>initial and
 *      ongoing</b> costs.</li>
 *  </ul>
 *  <P>
 *  If your organization has this requirement, contact Isomorphic Software to discuss scope
 *  and sponsorship terms.
 */
public interface CspSupport {
}
