Native execution bridge for sandboxed scripting languages

Techniques herein include receiving, at a scripting language component of a native execution bridge, a request to execute one or more scripting language commands, and sending the commands from the scripting language component to a native execution component of the native execution bridge for determination, based at least in part on a security policy, whether to execute the one or more scripting language commands as corresponding native commands outside the scripting language component. In response to determining to execute the commands, the commands are translated into one or more natively executable commands and are executed. In some embodiments, the scripting language component determines, based on a security policy, whether commands are permissible, and only if they are, forwarding those commands to the native execution component for translation and execution.

FIELD OF THE INVENTION

The techniques described herein relate to native execution of scripting languages, and in particular to native execution bridges for sandboxed scripting languages.

BACKGROUND

Computer applications are ubiquitous in the daily lives of many. Rarely does an hour pass without interacting with at least one computer program on at least one device. That device may be your phone, computer, television, automobile, bank machine, etc. An issue with these applications, though, is that they lack scalability of features. The companies developing the programs want to deliver more features to the users (or have third parties deliver those additional features), and the users of the programs want to receive more features. The issue is, however, that including all features in a program initially can be prohibitive in terms of application size (e.g., megabytes or gigabytes of memory needed) and application adaptability (for later-developed objects that could run with the application). One solution would be to deliver new or additional features after a program has been installed would be to allow for JavaScript objects to be run in the application, and to deliver new features as JavaScript objects. This approach presents its own challenges. For example, with this approach new JavaScript objects running within the application do not run natively, but instead run in a JavaScript Core (or other JavaScript execution environment) within the application and are therefore inefficient (e.g., in terms of computing power) and limited (e.g., to commands available in the JavaScript Core).

The techniques described herein address those issues.

SUMMARY

The attached claims serve as a summary of the invention.

DETAILED DESCRIPTION

General Overview

As noted above, applications often have scalability issues. Even if an application allows for loading and execution of JavaScript (or other scripting language) programs or objects, there is an issue with inefficiency (e.g., because the computer programs run on an interpreter and are not as fast as natively-executing commands) and/or access to commands or memory (e.g., because JavaScript and other interpreters limited access to natively executable commands and memory).

A system may be developed to allow native execution on mobile devices of some commands from JavaScript by use of a bridge from the JavaScript Core to a native execution component. Commands in JavaScript are executed in the JavaScript environment of a native application, and the bridge translates some of the commands to native commands, thereby improving the efficiency of the execution of those commands. This native execution may allow for more efficient execution of commands written in JavaScript. The issue with this approach is, however, that there is no way to differentiate the access provided among the scripting objects running in the JavaScript environment. That is, each JavaScript object running has access to all of the native commands that the hosting application has via the simple bridge. This is an important issue because, for example, if one allows the loading of JavaScript components programmed by others (third parties), there is no limit to the commands, memory, etc. to which those programs have access.

Consider an application deployed to a smartphone with a such a bridging scripting language environment running in the application, and the bridging scripting language environment allows the loading of third-party plug ins. If the application running on the smart phone has access to critical memory (e.g., contacts) and/or sensors (e.g., the camera), then the third-party plugins running in the bridging scripting language environment would also have access to the memory and/or sensors. This can cause security and other issues.

The techniques herein overcome these issues.

The techniques herein provide a scripting language environment or “sandbox” running within the native application. The scripting language sandbox may have therein a component that acts as a bridge between the scripting objects running in the scripting language sandbox and a native execution component running outside of the scripting language sandbox. The scripting language component of the bridge running in the scripting language sandbox may communicate with the native execution portion of the bridge in order to pass commands scripting language programs running in the sandbox to be translated and executed natively by the native execution component of the bridge.

In some embodiments, the native execution component will check a security policy associated with the scripting language program executing in the sandbox in order to determine whether the particular commands the scripting language program is attempting to execute are permissible for the scripting language program. For example, the scripting language object may be a newly-downloaded third-party object related to billing running within a support ticket application running on a phone. The billing object may have been permitted access to the contacts on the phone, but not the camera or global positioning system (GPS). Notwithstanding that the support ticket application may have access to the camera and GPS, if the billing object attempts to access the camera or GPS it will be denied because its security policy does not allow for such access. In some embodiments, the limitation on execution of impermissible commands is handled by the native execution component of the bridge (e.g., by not translating and executing those commands when received from the scripting sandbox portion of the bridge). In some embodiments, the limitation on execution of impermissible commands is handled by the scripting language component of the bridge, in which case the scripting language component may delete, disregard, or otherwise not pass on for execution commands that are impermissible for the scripting language object.

The techniques herein are particularly beneficial as they allow for new scripting language objects (and corresponding features) to be added to programs without performing many of the traditional tasks, such as compiling every possible feature into the application before distribution. This is beneficial because an application with all features already compiled in would be unduly cumbersome, adding many features that only some users would actually want included. These techniques also overcome the issue with the approach of allowing loading of objects to run in a JavaScript environment. Objects running in JavaScript environments are inherently limited in terms of efficiency since they are interpreted on the fly by the JavaScript environment. Objects running in JavaScript are also inherently limited in terms of the availability of access to the memory and commands on the device on which they run. These techniques also overcome the issues with systems such as React Native. Since React Native is built to allow first-party developers a way to write in JavaScript, there are no security measures associated with objects running in React Native. Therefore, it could be very dangerous to use a React Native object written by someone else since it would have no limitation on access to memory or commands.

Processes for Translation and Native Execution of Scripting Language Programs Using a Bridge

FIG. 1AandFIG. 1Bdepict example processes100and101for native execution of allowable commands translated from scripting language objects running in a scripting language sandbox. As an overview, process100ofFIG. 1Aoptionally begins by showing102a choice of available objects that can run as part of a natively-executing program (e.g., as part of application201running in native execution environment200ofFIG. 2), and receiving104a selection of one of those objects. The selected object may be a scripting language object written by a third party and may provide functionality and features to the application201running in the native execution environment200. The scripting language execution sandbox230may receive110commands to execute from a scripting object235. If it is determined120that those commands are not for native execution, they may be executed122in the scripting language sandbox. If it is determined120that the commands are for native execution, they may be sent130from the scripting language component220to the native execution component210of the bridge250. If the native execution component210of the bridge250determines140using a security policy for the scripting object235that the commands are permissible, then the commands are translated and executed160. Otherwise, optional error handling150may occur.

Returning to the top ofFIG. 1A, process101optionally begins by showing102choices of available objects for inclusion in and/or execution with a native application. Consider, for example, the natively-executing application201ofFIG. 2, which, in some embodiments, may run on a device320(ofFIG. 3), such as a smart phone. The natively-executing application201may present on the screen of the device320an array of choices of objects available for use with the natively-executing application201. These may be objects written in a scripting language, and that are compatible with the natively-executing application201, object that are available for purchase for use with the natively-executing application201, object that have already been purchased for use with the natively-executing application201, and/or the like. The objects available for use with the natively-executing application201may be provided by a developer associated with developer computer331and/or be available from a scripting object store330. For example, the objects may have been developed and later uploaded from a developer computer331to a scripting object store330. In some embodiments, the objects may also be provided directly from a provider computer310or a developer computer331, or may be stored in and received from network based storage340and/or341. In some embodiments, the scripting objects presented102may have associated therewith security policies that define what native actions, memory, and/or commands the object may be able to execute (discussed elsewhere herein).

As a particular example, the natively-executing application201may be a support ticket application and may have available objects useable with the support ticket application. The objects may be, for example related to billing for support tickets completed. One such object may provide billing components and may have a security policy indicating that it can access the contacts and email on the device using native commands. Another billing component may have a security policy allowing it to access contacts, email, global positioning system (GPS—for location confirmation of activities billed) and the camera (to take pictures of receipts and finished products).

The process100optionally includes receiving104a selection of an object from among available objects. If a user was shown102those objects, then the user may select one or more of those objects and then the application may receive104a selection from the user. The objects may then be downloaded or otherwise transferred for execution by, e.g., the scripting language execution sandbox230within the natively-executing application201(see, e.g., scripting object235executing within the scripting language execution sandbox230). In some embodiments, if the natively-executing application201is executing on device320ofFIG. 3, then a selection show102on the display of device320may have been selected by a user and the natively-executing application201(running on device320) may receive104the selection of an object and download that scripting object (e.g., from scripting object store330) to the device320to be run in the scripting language execution sandbox230. Returning to the example above, the support ticket application may present a list of available or previously-purchased objects, such as the two billing objects, and a user may select one (or both) of those objects within the application, and the support ticket application may receive104that selection.

In some embodiments, if optional steps102and104are omitted, the process100begins by receiving110a request to execute a scripting language commands at a scripting language component of a bridge. In some embodiments, the process100receives110the request to execute the scripting language commands after the receipt104of selection of a scripting object, and the scripting language commands are from the selected object. The scripting object, however, may have been received, imported, downloaded, or obtained in any appropriate manner (e.g., installed from the memory of the device320on which the natively-executing application201is executing, automatically uploaded from a provider computer310or the like).

Once an object is in the scripting language execution sandbox230of the natively-executing application201, it will attempt to execute, which can cause receipt110of the request to execute the scripting language commands at the scripting language execution sandbox230. The request can then be assessed in order to determine120whether it is for local script interpretation or for native execution. If the received110commands are not determined120to be for native execution, e.g., if they are commands that can be executed by the scripting environment, then they are executed122in the scripting language execution sandbox230. Executing scripting language commands may include interpreting the commands and having the scripting language execution sandbox230executing the interpretation. As discussed elsewhere herein, the scripting language execution sandbox230(such as a JavaScript core or JSC) may limit access to memory and/or commands that would be available for native execution. For example, the JSC may not provide to scripting object any access to the GPS, contacts, email, memory, and/or a number of other commands and aspects of a device320. Thus, in order to obtain more thorough access, a scripting object235may have to utilize the script language component220of the bridge to communicate with the native execution component210of the bridge in order to obtain the better access to the device's320capabilities.

If the received110commands are determined120to be for native execution, then they are sent130from the script language component220of the bridge250to the native execution component210of the bridge250. Sending130from the script language component220to the native execution component210can be via any appropriate manner or protocol, including calling an application program interface; or via a protocol over TCP/IP, HTTP(S), FTP, etc. For example, in some embodiments, the native execution component210and the script language component220are the embodied in the same program and are only conceptually distinct, in which case the commands are not actually sent130, but instead, are simply shared within that common program. For example, the bridge250may be a single program or be part of a single program, and the script language component220and the native execution component210may be conceptual or components of the bridge250running in a single program.

The commands are checked140against the security policy for the object to see if they are permissible for native execution. As discussed additionally elsewhere herein, each scripting object might have its own security policy, and commands that the object is attempting to have executed natively may be checked against the policy. Returning to the example discussed elsewhere herein, there may be two billing objects available for a support ticket system, one with access to contacts and email (useful for contacting people related to the ticket for billing purposes), and the other may have access to GPS and the camera (useful for confirming location of work performed and taking pictures of receipts and completed jobs) as well as the contacts and email. Each object would have a security policy reflecting those permissions. If, for example, the first scripting object, which only has access to email and contacts, attempts to access GPS location data, then those commands would fail when checked140against the security policy for that scripting object.

If it is determined140that the commands are permissible, they are translated and executed160. In some embodiments, the native execution component210of the bridge will perform the translation of the commands determined140to be permissible, though the translation of the commands could be performed by another component not pictured inFIG. 2. Translation of commands might be a one-to-one mapping of commands. For example, a “print” command in the scripting language may translate to a similar native command. Additionally, some commands may map to more than one native command, and other sets of more than one scripting language command may map to a single native command. In some embodiments, a bridge's translation components could be that implemented as part of React Native, and utilize the bridge translation made available by React Native.

If it is determined140that the commands are not permissible under the security policy, then, optionally, the script language component220, the native execution component210or other element of application201may perform error handling150. The error handling150may take any appropriate form, such as returning an exception to the calling scripting object, flagging the attempted execution prohibited by the policy, prompting a user of a device on which the program is running that unpermitted access was attempted (e.g., including the type of access attempted and the scripting object that attempted it), logging the error, and/or failing silently while not executing the requested native command. For example, if a scripting object235attempts to print to the screen of a device320, that error may not be flagged at all, while the attempting printing to the screen may not happen. If, on the other hand, the scripting object235attempts to access the contacts on a device and it does not have permission, that may be flagged for review by the provider of the original application201since it may represent phishing or other nefarious behavior.

Returning to the support ticket application example with the two billing scripting objects, if the first billing object (with just permissions to email and contacts) had been chosen and loaded to the scripting language execution sandbox230, and if it attempted to have a command performed natively to which it did not have permission (e.g., accessing the microphone of device320), then the attempt would be determined140impermissible. The impermissible attempt may optionally have error handling150performed (e.g., by the scripting language execution sandbox230) such as flagging the error for review by the provider of the application201. If the billing object attempts to have a command natively executed to access email (and it does have permission for such commands), then the attempt would be determined140permissible and the command would be translated and executed160by the native execution component210of the bridge250.

Additional Processes

The features of process100are presented in a particular order and are discussed as being performed by particular hardware and/or system elements. There are numerous different embodiments of the process consistent with the spirit of the techniques disclosed herein. For example, returning toFIG. 1B, process101progresses in some manners similar to process100. Similar features, activities, and steps are numbered similarly inFIG. 1AandFIG. 1B. A primary difference between process100and process101is where and when the determination is made as to whether natively-executing commands would be permissible for a particular scripting object235. In process101ofFIG. 1B, that check is made by the scripting language component220of the bridge250(as opposed to by the native execution component210in process100), and the determination is made before sending commands to from the script language component220to the native execution component210of the bridge250. This change necessitates a few other changes, which are discussed below.

Where process100and process101are similar, the discussion of those aspects of process101are not repeated here and should be considered similar to or parallel with those for process100. For example, optionally showing102choices of objects and receiving104a selection of a choice of a scripting object are similar in process101to what is described for process100. Receiving110the request to execute scripting language commands; the determination120of whether the commands require native execution; and, when they do not require native execution, executing122the scripting language commands in the scripting language sandbox are all similar in processes100and101and discussion of each is not reiterated here.

If it is determined120that native execution of commands is requested, then the scripting language component220determines140whether the requested commands are permissible for native execution under the security policy for the scripting object. Although the determination140is made by the script language component220in process101as opposed to by the native execution component210of the bridge, the determination140of process101parallels that of process100. For example, each scripting object might have its own security policy, and the script language component may check the commands that the object is attempting to have executed natively against the policy. If the script language component220determines that the security policy for the object states that execution of the requested objects is permissible, then the commands are sent130to the native execution component for translation and execution160, and both the sending130of the commands from the script language component220to the native execution component210and the translations and execution160of the commands by the native execution component210are similar for process101to what is described above with respect to process100.

If the script language component220of the bridge250determines140that the commands are impermissible under the policy for the object, then the process101may optionally perform error handling150similar to the error handling150described above for process100.

Example Bridge for Translation and Native Execution of Scripting Language Programs

FIG. 2depicts an example native execution environment implementing a native execution bridge for sandboxed scripting language programs. A natively-executing application201running in a native execution environment200. In some embodiments, the native execution environment may be an operating system running on a device, such as device320ofFIG. 3. Natively-executing application201may have running therein a scripting language execution sandbox230. In some embodiments, the scripting language execution sandbox230may be a JavaScript Core (JSC) or other scripting language execution environment. The scripting language execution sandbox230limits access of objects running therein (e.g., scripting object235) to memory, commands, and other aspects of the native execution environment200and/or the device320. The scripting language execution sandbox230may have one or more scripting objects235executing therein. When a scripting object attempts to execute a command that would cause the script language component220of the bridge250to request translation and execution by the native execution component210of the bridge250, either the script language component220or native execution component210will determine whether the policy associated with the scripting object235would allow such a native command. If allowed, the native execution component210of the bridge250will execute (or cause execution) of the native commands on behalf of the script language component220and the scripting object235.

As discussed additionally elsewhere herein, bridge250may have the script language component220and native execution component210running as two separate processes or programs, and the bridge250may be conceptual in the sense that it is the name of the two separate processes or programs together. In such embodiments, the communication between the script language component220and the native execution component210would be via application program interface, remote procedure call, etc. or via a communication mechanism such as https, SSL, FTP, TCP/IP, etc. In some embodiments, the bridge250and its script language component220and native execution component210are all one program, or one set of programs or functions. In this case, communication between the script language component220and the native execution component210could additionally be by procedure or function call, shared memory or variables, or the two components could be executing as a single program. The bridge250may also be integral to and a part of scripting language execution sandbox230and/or application201.

In some embodiments, the native execution environment200performs some or all of processes100and/or101. Further, native execution environment200may execute on one or more components ofFIG. 3, such as on device320or321.

System Overview for Translation and Native Execution of Scripting Language Programs

FIG. 3depicts additional example systems implementing a native execution bridge for sandboxed scripting language programs. A scripting object store330, provider computer310, devices320and321, developer computer331, and storage mechanism340and341may all be coupled to a network390and be able to communicate via the network. Each of the devices320and321, scripting object store330, developer computer331, and provider computer310may run as part of the same process and/or on the same hardware (not depicted inFIG. 3), or may run separately. Further, each may run on a single processor or computing device or on multiple computing devices, such as those discussed with respect toFIG. 4and elsewhere herein.

As discussed elsewhere herein, an application may be provided by a provider computer310to a device320or321. That application may have scripting objects available from the scripting object store330, where those objects were developed by programmers and provided by the developer computer331to the scripting object store330. The device320or321may be used to select and download scripting objects from the scripting object store to the device320or321. From there processes100and/or101may be used to determine whether and what commands attempting execution on the device320or321are permissible under the policy for the object.

As discussed herein the various processes100and101, etc. may run in parallel, in conjunction, together, or one process may be a subprocess of another. Further, any of the processes may run on the systems or hardware discussed herein, including those depicted inFIG. 2,FIG. 3, andFIG. 4.

Hardware Overview

Computer system400may be coupled via bus402to a display412, such as an OLED, LED or cathode ray tube (CRT), for displaying information to a computer user. An input device414, including alphanumeric and other keys, is coupled to bus402for communicating information and command selections to processor404. Another type of user input device is cursor control416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor404and for controlling cursor movement on display412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. The input device414may also have multiple input modalities, such as multiple 2-axes controllers, and/or input buttons or keyboard. This allows a user to input along more than two dimensions simultaneously and/or control the input of more than one type of action.