Implement non-eval based Vega execution path

For security reasons, many modern web sites lock down their Content Security Policy with the script no-eval CSP rule, which prevents the new Function() code. Vega heavily relies on the dynamically generated expressions. While this may provide some performance benefits, it would be good to have a possibly-slower expression interpreter alternative (configurable).

As an experiment, I have created an alternative sandbox approach, but this might not be suitable to some complex apps: https://github.com/nyurik/csp-vega-test

[jheer]

The (safe) use of a Function constructor underlies multiple Vega features, including not only expressions, but also compilation of visual encoding procedures. It’s unlikely that we (at UW) will focus efforts on building an alternative interpreter for these functions. However, we’re certainly open to reviewing 3rd party contributions.

In Vega 3, Function constructor calls arise due to a single line in the vega-runtime repository. Future extensions might start there, replacing the use of Function.apply with a custom JS parser/evaluator.

For background context, the Vega parser generates output JS code for expressions and visual encoders, included within an output dataflow graph description. The runtime (typically invoked from vega-view) parses this description into a dataflow instance, including instantiation of functions.

Given the effort and potential performance implications of such changes, I recommend first following a sandbox approach if feasible.

[dlaliberte]

redesigns the encoders to run through the expression parser, such that all code generation will pass through the expression language framework.

This sounds like it will indeed be safer, but it will result in much more code being run through the expression language framework than is minimally necessary. That is what I am seeing after your changes to encode/entry.js:

const colorValue = (type, x, y, z) =>
  `(${type}(${[x, y, z].map(entry).join(',')})+'')`;

In my previous comment, I gave an example of how expressions which would be generated to create a color (like that one) could instead be factored out into a function (makeColorStyle) that could be pre-compiled as part of the library. This would also be just as safe as running the equivalent expression text through the expression language framework, but it would result in much faster runtime performance since the interpreter would not have to be operating over that part of the code.