Ecosystem Building Block: Scripting Engine Use Cases and Considerations
A well-defined API enables unlimited capability extension of a system, as demonstrated in our previous article. Client-server or inter-server communication is two most common API use cases. There is less common model of API consuming mechanics called scripting engine. This article is intended for engineers developing extensible platform and exhibits use cases, benefits and considerations of scripting engine.
Extensibility
According to Wikipedia, extensibility is a software engineering and systems design principle where the implementation takes future growth into consideration. The term extensibility can also be seen as a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change — typically enhancements — while minimizing impact to existing system functions.
There are 3 types of extensibility:
- White-Box. Under this form of extensibility, a software system can be extended by modifying the source code, and it is the most flexible and the least restrictive form. Windows Dynamic-link Library (DLL), Linux Dynamic Library Loading, Java Class Loader are some existing mechanics to extend platform capabilities. These mechanics exposes runtime environment to the extensions without sandboxing, which severely hurts security.
- Black-Box. In black-box extensibility (also called data-driven frameworks) no details about a system’s implementation are used for implementing deployments or extensions; only interface specifications are provided. This type of approach is more limited than the various white-box approaches. Black-box extensions are typically achieved through system configuration applications or the use of application-specific scripting languages by defining components interfaces. RESTful API, GraphQL API, Remote Procedure Call are some examples of this type.
- Gray-box. Gray-box extensibility is a compromise between a pure white-box and a pure black-box approach, which does not rely fully on the exposure of source code. Programmers could be given the system’s specialization interface which lists all available abstractions for refinement and specifications on how extensions should be developed. Scripting engine falls to this category.
When to Use Scripting Engine
Based on our exploration, there are a number of situations where scripting engine is suitable.
Extensible Native Applications
Extensible native desktop applications usually employ feature add-ons to enhance the default capabilities, for example is Chrome Web Browser Extensions. Another successful example is Warcraft 3 Mods. From this game platform, Defense of the Ancients was born. WeChat Open Platform is another example for mobile platform.
This type of extension is by nature embedded in the host application and the only way to interact with underlying API is by executing script or directly accessing runtime library. Scripting engine was chosen for obvious practicality reason.
Web-Based SaaS Add-Ons
Google Docs add-ons enables user to enhance default Google Docs capability. Similar to native applications, this use case is embedded in the app, rendering scripting engine beneficial.
More complete coverage of this type of extensions is covered in API and Platform Extensions article.
Formula-calculating
Formula calculation is inherently impossible to enumerate. It is more justifiable to let users define the formula and let the system evaluates the formula for calculation. One example of this use case is catapa.com. Catapa is Human Resources Intelligent System that empowers small and medium businesses to focus more on their core business, initially focusing on payroll and individual tax. One of the Catapa’s feature is calculating health insurance deducted for each employee. Each company may have different calculation formula. It is next to impossible to enumerate all possible formula, hence scripting engine is usable so that user can simply type in a custom formula.
Considerations of Scripting Engine
We did small research to get deeper understanding of scripting engine model. We took Java as our technology foundation and Javascript as accepted language. The script is run on top of Nashorn scripting engine.
By the time this article was written, we understood that Nashorn was going to be deprecated and replaced by GraalVM. However, GraalVM was still in release candidate version.
Language Choice
Since the primary users of scripting engine is end users, scripting language should be carefully chosen to reduce complexity and increase chance of successful application. Well known language like JavaScript is a wise choice since it has been most popular language for last few years. Using well known language also contributes to easier execution since there are already many script runners available, for example is Nashorn scripting engine to run ECMAScript on Java.
However, at some point we will need higher support and flexibility and we will also need a new language. For example is WXML (WeiXin Markup Language) which is used by WeChat to integrate WeChat Open Platform Mini Program. This type of language has indeed steeper learning curve and execution complexity.
Integration Point
Platform integration point should be designed based on what goals it should achieve. As demonstrated here, each of the platforms (Facebook App, Chrome Extensions, Firefox WebExtensions, Google Docs) has their own unique mechanics. Facebook App was designed with App terminology, enabling user to consume games, lifestyle helpers, or any social networking-related app. The apps are presented to users as a list users can visit. Chrome and Firefox extensions are designed to enhance browsing experience, e.g: by blocking ads, analyzing traffic, debugging web apps, etc. The extensions are presented as application menu. Similarly Google Docs extensions are also presented as application menu, but with goal to improve document creation experience.
What we should do as platform developers are as follows:
- Find out what can be extended or customized by users. It is encouraged to be based on business requirement.
- Design potential integration points.
- Design minimum API to satisfy early prototype.
- Test the API and the integration points, find out what is missing.
- If new API is needed or requested, back to step 3 by adding new API version.
Creating generic platform may be not as straightforward since it is impossible to make generic API at once without iteration. Forward compatibility pattern, iterative development and API versioning may be some of useful techniques in developing the API.
Level of Freedom and Security
Albeit still more limited than white-box extensibility, there are still inherent threat to the overall system security. This mechanic accepts untrusted script and runs it in our runtime environment. Based on our research, the system is prone to following threats but not limited to:
- Accessing forbidden API (OWASP 2017 A5 — Broken Access Control). Without correct access control, script writer can call business-specific forbidden API.
- Accessing disk (OWASP 2017 A5 — Broken Access Control). Direct disk access simply means giving your safe to a burglar.
- Accessing network (OWASP 2017 A5 — Broken Access Control). If the script can access sensitive information, network access provides way to leak the data to outside system.
- Infinite script runtime. Writing
while (true);and let it executed occupies the CPU and prevents the application from executing other requests. - Memory exhaustion. Reserving gigabytes of array list occupies the RAM and prevents the application from executing other requests.
Script sandboxing is one of feasible solution to prevent the script from doing malicious actions. We utilized Delight Nashorn Sandbox in our research. Delight wraps Nashorn sandbox and leverages its capability with sandboxing utilities.
To prevent threats #1, #2 and #3, Delight provides capability to limit certain number of APIs to be called. By default, Delight blocks all access to Java API. However, we can consciously whitelist certain API to be available.
Forbidding threats #4 and #5 is also supported by Delight via setMaxCPUTime and setMaxMemory API.
Conclusion
There are multiple mechanics of developing extensible platform. When black-box extensibility is not enough, we can go lower to gray-box or even white-box. One of the example is by employing scripting engine. However, there are some considerations to be taken care of since exposing lower abstraction affects negatively to some aspects, namely: language choice, integration point choice and security. Special attention should also be put to avoid unnecessary threat exposure.
Special thanks to Ricky Chandra Johanes for the wholesome effort during his internship @ GDP Labs.
