Securely enabling the rendering of hybrid website interfaces based on trusted and untrusted code components

Abstract

Systems, methods, and computer program products configured to securely enable rendering of a hybrid website interface are provided. An exemplary website building system provides a primary execution environment configured to execute one or more trusted website code definition elements, provides one or more sandbox execution environments configured to execute one or more untrusted website code components, provides one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements, and causes rendering of a hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components are executed via the one or more proxy translation components.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 597,902, filed November 10, 2023, U.S. Provisional Patent Application No. 63 / 590,914, filed October 17, 2023, U.S. Provisional Patent Application No. 63 / 582,286, filed September 13, 2023, and U.S. Provisional Patent Application No. 63 / 477,320, filed December 27, 2022, each of which is incorporated by reference in its entirety.

[0002] Exemplary embodiments of the present disclosure relate generally to secure website systems, and more particularly to systems and methods configured to securely integrate externally hosted or third-party code, or other potentially untrusted or insecure code, into a website and enable the rendering of a hybrid website interface. [Background technology]

[0003] Various website building systems provide tools, such as application programming interfaces (APIs), plug-ins, widgets, and the like, to enable website developers to communicate with externally hosted applications or services when creating or editing a website. However, such communication offers limited functionality and is fraught with security vulnerabilities and performance issues. Through applied effort, ingenuity, and innovation, many of these identified deficiencies and problems have been resolved by developing structured solutions in accordance with embodiments of the present disclosure, many examples of which are described in detail herein. Summary of the Invention

[0004]

[0006] Generally, embodiments of the present disclosure provided herein include improved systems and methods configured to securely integrate externally hosted or third-party code, or other potentially untrusted or insecure code, into a website and enable rendering of a hybrid website interface. According to one exemplary embodiment of the present disclosure, a website construction system configured to enable rendering of a hybrid website interface based on at least one trusted website code definition element and at least one untrusted website code component is provided, the website construction system including at least one processor and at least one non-transitory memory including program code, the at least one non-transitory memory and the program code configured, using the at least one processor, to cause the website construction system to at least: provide a primary execution environment configured to execute the one or more trusted website code definition elements; provide one or more sandbox execution environments configured to execute the one or more untrusted website code components; provide one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; and cause rendering of a hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components have been executed via the one or more proxy translation components.

[0005] According to another exemplary embodiment of the present disclosure, there is provided a website construction system configured to enable rendering of a hybrid website interface based on at least one trusted code structure and at least one untrusted code structure, the website construction system including at least one processor and at least one non-transitory memory including program code, the at least one non-transitory memory and the program code configured to cause, using the at least one processor, the website construction system to at least: access a code repository to identify at least one untrusted website code structure and at least one trusted website code structure; translate the at least one untrusted website code structure into a primary execution environment proxy translation component, wherein the at least one untrusted website code structure continues to operate within a sandbox execution environment; generate a primary execution environment configured to execute the at least one trusted website code structure and the primary execution environment proxy translation component; and cause rendering of the hybrid website interface after the at least one trusted website code structure and the at least one untrusted website code structure have been executed via the primary execution environment proxy translation component.

[0006] According to another exemplary embodiment of the present disclosure, a computer-implemented method for automatically performing trusted code splitting on an untrusted candidate code corpus is provided, the computer-implemented method including applying a trusted code identification model to the untrusted candidate code corpus to automatically identify one or more trusted code sections; extracting one or more trusted code sections from the untrusted candidate code corpus; generating one or more trusted computer-executable functions based on the one or more trusted code sections; and generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus.

[0007] According to another exemplary embodiment of the present disclosure, a computer-implemented method for implementing secure code-based content in a supply chain is provided, the computer-implemented method including: receiving, at a trusted entity, code-based content from a code synthesis entity; identifying, at the trusted entity, at least one trusted code section of the code-based content; compiling, at the trusted entity, the at least one trusted code section for execution in a primary execution environment; and generating, at least based on the compiled trusted code section, an executable code package.

[0008] The above summary has been provided solely for the purpose of summarizing some exemplary embodiments to provide a basic understanding of some aspects of the present disclosure. Accordingly, it should be understood that the above-described embodiments are merely examples and should not be construed in any way to narrow the scope or spirit of the present disclosure. It should be understood that the scope of the present disclosure encompasses many potential embodiments in addition to those summarized herein, some of which are further described below. Other features, aspects, and advantages of the present subject matter will become apparent from the description, drawings, and claims.

[0009] Having described certain exemplary embodiments of the present disclosure in general terms above, non-limiting and non-exhaustive embodiments of the present disclosure will now be described with reference to the accompanying drawings, which are not necessarily drawn to scale, and in which the components shown are in accordance with the principles of the present disclosure. Some components may or may not be present in certain embodiments. Some embodiments may include fewer (or more) components than shown in the drawings. Some embodiments may include components arranged in a different way. [Brief explanation of the drawings]

[0010] [Figure 1A] 1 is a flowchart of operations that enable rendering of a hybrid website interface according to some example embodiments described herein. [Figure 1B] 3 is a signal diagram of an example data flow according to some example embodiments described herein. [Figure 2] 10 is a flowchart of operations for enabling rendering of a hybrid website interface according to other example embodiments described herein. [Figure 3A] FIG. 2 is a schematic control / data flow diagram at runtime for rendering a hybrid website interface, according to some example embodiments described herein. [Figure 3B] FIG. 10 is another schematic control / data flow diagram at runtime for rendering a hybrid website interface, according to certain example embodiments described herein. [Figure 3C] FIG. 10 is another schematic control / data flow diagram of a runtime for rendering a hybrid website interface having a multi-tier or nested-tier sandbox execution environment, according to some example embodiments described herein. [Figure 4A]FIG. 2 is a signal diagram of an example data flow for a J compiler, according to some example embodiments described herein. [Figure 4B] FIG. 10 is a signal diagram of another exemplary data flow for a J-compiler according to another exemplary embodiment described herein. [Figure 5] FIG. 1 is a schematic block diagram of example components of an example hybrid website interface rendering system, according to some example embodiments described herein. [Figure 6] FIG. 1 is a schematic block diagram of example components of an example website building system, according to some example embodiments described herein. [Figure 7] FIG. 2 is a schematic block diagram of an example repository of an example content management system of a website building system, according to some example embodiments described herein. [Figure 8] FIG. 2 is a schematic block diagram of example modules or circuits for use in an example server device, according to some example embodiments described herein. [Figure 9] 1 is a schematic block diagram of an example module or circuit for use in an example client device, according to some example embodiments described herein. [Figure 10] 1 is a flowchart of operations that enable rendering of a hybrid website interface, according to some example embodiments described herein. [Figure 11] 1 is a flowchart of operations for automatically performing reliable code splitting on an unreliable candidate code corpus, according to certain example embodiments described herein. [Figure 12] 1 is a flowchart of operations for implementing secure code-based content in a supply chain, according to certain example embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0011] One or more exemplary embodiments will now be described more fully below with reference to the accompanying drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without these specific details (and without applying them to any particular network environment or standard). It is clear that some, but not all, embodiments have been shown and described herein. It should be understood that the embodiments may be embodied in many different forms, and thus, the disclosure should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. As used herein, descriptions may refer to a server device or a client device as an example of an "apparatus." However, elements of the apparatus described herein may be equally applicable to the claimed systems, methods, and computer program products. Therefore, use of such terms should not be construed to limit the spirit and scope of the embodiments of the present disclosure.

[0012] overview Developers and / or users may, for several reasons, desire to add or embed third-party applications into websites; however, allowing third-party code to execute as part of a web page, website, or system is problematic because such untrusted third-party code may be insecure, malicious, compromised, and / or contain bugs. For example, such executable third-party code may intentionally or unintentionally contain malicious functionality, vulnerabilities, and / or allow attackers to access the website or, even worse, the underlying system. Furthermore, methods for integrating third-party or potentially untrusted code during website construction or editing may require developers to explicitly identify and / or manually handle the isolation of secure code from untrusted code / elements.

[0013] Similarly, a site owner or designer may determine that certain written code, components, or subcomponents, although created in-house and not necessarily third-party code, may be less secure or insecure compared to other secure organizational code, components, or subcomponents of a web page, website, or system. Untested or poorly tested code may contain bugs, and to prevent such potentially flawed code from harming tested code or other portions of a web page, website, or system, the site owner or designer may wish to compartmentalize or isolate such less-tested code from more-tested code. It may be desirable and preferred to maintain the security of a web page, website, or system while efficiently providing inter-component isolation. In other words, it may be desirable to obtain the functionality of such potentially insecure code or components without the supply chain risks associated with intentionally or unintentionally distributing such potentially insecure code into a website or underlying system. It may further be desirable and preferred to maintain the security of such web pages, websites, or systems without requiring the site owner or designer to explicitly handle the necessary separation and isolation of such code or otherwise handle the flow and control of data between different types of code.

[0014] The use of iFrame tags or elements or other isolation techniques to allow developers to embed third-party applications or widgets into websites has drawbacks. Indeed, the use of iFrames on websites, where the iFrame loads the entire third-party application, including both the logical code and the visible design elements of the third-party application, may lead to SEO (search engine optimization), performance, and / or accessibility issues for the website. Content displayed via such iFrames may not be indexed or may be indexed incorrectly, affecting the search engine rankings of the underlying website. impacts website load speed or latency (e.g., search engine crawlers may not be able to cross-index multiple related iFrames to effectively identify and consolidate such content). The use of iFrames, which must load both the logical code and the visible design elements of the third-party application or widget, may also, or instead, adversely affect the loading speed or latency of a website. For example, a browser must essentially open a new browser window instance to execute each iFrame and load both the logical code and the visible design elements of the third-party application or widget. This is computationally expensive and can lead to performance issues due to memory requirements, processing power, etc.

[0015] This problem only worsens as the number of iFrames increases for any particular website. Indeed, generating and comparing virtual Document Object Model (DOM) trees in such conventional systems and methods requires significant computational effort. Details regarding DOM tree comparison algorithms are described in commonly owned U.S. Patent No. 9,817,804, entitled "SYSTEM FOR COMPARISON AND MERGE OF VERSIONS IN EDITED WEBSITES AND INTERACTIVE APPLICATIONS," filed February 11, 2015, as U.S. Patent Application No. 14 / 619,145, which is incorporated herein by reference in its entirety. As is apparent in light of the foregoing disclosure, it would be desirable and advantageous to maintain the security of a web page, website, or system while reducing computational load and memory requirements, minimizing performance impact, producing a low-latency user experience, improving SEO indexing, and supporting more streamlined execution of trusted and untrusted code.

[0016] Furthermore, one of the challenges of running secure code is the difficulty of checking what the code does without executing it. Even when the code is executed, defense mechanisms tend to be very complex and involve attempting to mitigate a large attack surface that must be maintained, applied, and monitored in real time, while trying to avoid significant impacts to performance, application load times (e.g., important for web, mobile, and serverless computing), and stability. While code can be run in a sandbox environment with only a subset of APIs exposed to the sandbox, such whitelisted APIs still need to be made available, monitored, loaded, impact performance and stability, and verified to be secure.

[0017] Furthermore, systems that rely on compilers for security may still be susceptible to supply-chain attacks. For example, code-based content may be split into secure and non-secure portions using a compiler. If the compiler is performed by a code supplier of the code-based content, there may be some advantages for the code consumer (e.g., not needing to know or understand dependencies and requirements, benefiting from easier consumption, content being pre-compiled, etc.) and the code supplier (e.g., a simplified distribution model because the consumer does not need to consider many variables), but the code supplier has all the control and may modify or adjust the compiled content after compilation (e.g., injecting unwanted code into so-called secure artifacts), exposing the code consumer to risk. Alternatively, if the compiler is performed by the code consumer, the code consumer bears the burden of assuming responsibility for configuring the compiler, policies, environment, etc. The content may not be consumed “as is” from the internet, a CDN, a package manager, etc., and using the content as intended by the code supplier may alter or degrade the user experience.

[0018] To overcome these and other problems, applicant has determined that in some embodiments, it is advantageous to separate the logical code of a website from the design or visible design elements of the website. In other words, various embodiments of the present disclosure enable the ability to create a safe, stable, low-latency system in which UI components or visible design elements (e.g., DOM) execute in a main context (e.g., a primary execution environment) and other code (e.g., potentially malicious logic of components that are not visible) executes in one or more sandbox contexts (e.g., sandbox execution environments), such that the website achieves the beneficial functionality of trusted and untrusted code without incurring undue risk to the UI components or underlying systems that may be intentionally or unintentionally delivered by the execution of such code.

[0019] By separating logical code from the visible design and isolating such logical code in one or more sandbox contexts (e.g., sandbox execution environments) in accordance with various embodiments of the present disclosure, the risk of potentially malicious code within such logical code is, by definition, extremely limited. Developers of such code executing in sandbox execution environments have complete freedom to do what they want, but do not have access to the primary execution environment or any other context of any other code developer. Indeed, potentially malicious code (e.g., untrusted website code components) cannot affect the global scope of the website or system or otherwise contaminate other parts because they cannot take over any part of the UI that is not owned by either the potentially malicious code or its corresponding visible design element (e.g., trusted website definition element) running in the main context (e.g., primary execution environment).

[0020] Various embodiments of the present disclosure also implement a proxy translation component that communicatively links untrusted website code components to trusted website code definition elements and vice versa. Such a proxy translation component preferably preserves the rendering or execution order of website code elements / components by representing or emulating corresponding website code elements / components of one context in the execution environment of another context.

[0021] Various embodiments of the present disclosure also minimize the computational expense and memory requirements associated with rendering an associated UI while further maintaining the security of a web page, website, or system. For example, performance issues are improved because data only needs to be compared between individual components (e.g., comparing the proxy translation component's recorded data with the proxy translation component's previously recorded data) and no virtual DOM tree needs to be generated solely for the comparison. In fact, the data compared tends to be much smaller compared to such virtual DOM trees. Example embodiments of the present disclosure enable the rendering of third-party UI elements, features, or components using single object messaging method (OMM) messages, regardless of the compositional nature (e.g., single-layer or multi- / deeply nested code structure) of untrusted website code components of the third-party code. Applicant has also determined that when working with mutable objects in a sandbox execution environment, it can be complicated to take an untrusted code component, generate a ViewState, do a Diff, create a JSON Patch, post it from the sandbox execution environment to the primary execution environment, patch the previous view state in the main object, get the new object, and then do another algorithm to resolve the reconciliation, so it is faster to use immutable data structures compared to mutable data structures in various embodiments of the present disclosure, but the system does not know what has changed because it does not have the previous version to compare to. By using objects, the system can easily check if a version is different from the previous version, and objects offer a significant improvement in performance.

[0022] Applicant has determined that it is desirable to construct and / or improve specific algorithms that are necessarily restructured or new to implement specific operations in accordance with various embodiments of the present disclosure. For example, array reconciliation and JSON Diff benefit from item movement support. Traditionally, for array reconciliation, algorithms perform diffs on array elements one by one when updating the DOM. However, DOMs generally use only indexes (not keys), and one-by-one replacement during updates is inefficient. Alternatively, exemplary embodiments of the present disclosure can track object identification information using key properties to facilitate array reconciliation with movement support. Rather than using replacement, the algorithm checks various possibilities and determines the minimum number of operations required by moving (thereby preserving) child DOMs whenever possible. Using movement, as opposed to replacement, reduces inefficiencies associated with steps that include node recomputation, node update, and component recreation. Supporting movement preserves the state of child components, improving the efficiency of DOM operations. Similarly, the JSON Diff algorithm may be configured to support object movement using the same or a similar algorithm.

[0023] Given the large volume of code and the variety of programming languages, efficiently and effectively identifying website code segments or snippets as potentially malicious or insecure from a consolidated website code repository is a computationally challenging task. Accordingly, various embodiments of the present disclosure apply machine learning and / or rule-based models to previously identified untrusted website code components, trusted website definition elements, and proxy translation components, as well as additional sources (e.g., application store information, code configuration, version tracking systems, developer instructions, etc.) to learn the relationships between underlying codes, thereby informing embodiments herein as to which code is potentially untrusted or insecure and which code can be verified as trusted or secure. Knowing which code is potentially untrusted or insecure and which code can be verified as trusted or secure allows embodiments herein to efficiently identify untrusted website code components, trusted website definition elements, the need to create proxy translation components, trusted code sections, and / or untrusted code sections.

[0024] Applicant has also determined that it would be advantageous to selectively identify and extract trusted code sections from a potentially untrusted candidate code corpus and compile such selectively identified trusted code sections into trusted computer-executable functions that can be executed in an insecure main context (e.g., a primary execution environment). For example, various embodiments of the present disclosure may automatically perform trusted code splitting by applying a trusted code identification model to the untrusted candidate code corpus to automatically and selectively identify one or more trusted code sections therein. The trusted code identification model may be configured to, for example, apply static code analysis to non-executable code to inspect the untrusted candidate code corpus and identify, mark, and / or infer candidate trusted code sections within the untrusted candidate code corpus based on, for example, one or more code analysis factors. For example, by using detectable or recognized code patterns previously deemed safe, the trusted code identification model will skip over obfuscated code, tricky code patterns, or other forms of attacks that may attempt to access private and / or unauthorized APIs because those "smart attack vectors" are likely to be exploited. This is because the "rule" is not covered by a detectable or recognized code pattern.

[0025] Various embodiments of the present disclosure may further partition the untrusted candidate code corpus into functional structures including two or more functions that can be run or executed in a primary execution environment or a sandbox execution environment. That is, selectively identified trusted code sections may be extracted or removed from the untrusted candidate code corpus. In some embodiments, the selectively identified trusted code sections may be generated (e.g., compiled) as trusted computer-executable functions that run in the primary execution environment, and the remaining untrusted code sections in the untrusted candidate code corpus may be generated (e.g., compiled) as untrusted code computer-executable functions that run in the sandbox execution environment, thereby creating a secure system. In some examples, the present disclosure contemplates that such secure code partitioning may be performed in a pre-execution preparation or compilation stage (e.g., in preparation of an executable code package). In other examples, the compilation and execution stages may be integrated so that secure code partitioning can be performed during execution (e.g., runtime) or just-in-time (JIT).

[0026] While the focus of this disclosure is to provide a secure system for executing code, the applicant has also determined that, in some cases, it is acceptable or even desirable for certain executable code to be unable to execute in order to protect the system from potentially malicious code. Furthermore, such secure code partitioning may advantageously reduce the need for a runtime layer of security because the secure code partitioning is performed at compile time. For example, a particular section of code may not have a detectable or recognized code pattern that can be verified by a trusted code identification model and therefore fails to meet the requirements to be identified as a trusted code section. Such a code section may require an API that is unavailable in the sandbox execution environment, but is not extracted or retrieved from the untrusted candidate code corpus, but instead is generated (e.g., compiled) as an untrusted computer-executable function that runs in the sandbox execution environment. At runtime, such an untrusted computer-executable function cannot run in the sandbox execution environment because the required API is unavailable. In other words, this code may be considered an attempt to subvert the sandbox and / or circumvent the security system, and therefore, it is acceptable for this code not to run in the sandbox execution environment.

[0027] Applicant has also determined that it would be preferable to incorporate a third-party trusted entity into the middle of the code supply chain to compile and create a secure supply chain for secure artifacts and provide such secure artifacts to code consumers. Similar to digital authentication, adding such a trusted player to the code supply chain prevents code suppliers from tampering with trusted code, allows code consumers to know that trusted code has not been tampered with, and allows code suppliers to still provide products without having to disclose all of their code to code consumers.

[0028] Having provided an overview of the present disclosure, exemplary methods, system architectures, and apparatus for implementing exemplary embodiments and features of the present disclosure are described below, followed by a set of definitions that are called out throughout this application. While various embodiments of the present disclosure are described herein with reference to hybrid website interface rendering systems and / or website building systems, the present disclosure also provides that the embodiments herein may be implemented in a variety of systems, including visual design systems, experimentation systems, end-user websites or applications, native applications, and the like. It is contemplated that the present invention may be equally applicable to a variety of website building systems and / or non-website building systems, such as application building systems, dynamic view allocation systems, application generation systems, and page analysis visual editors. Details regarding exemplary website building systems and non-website building systems are described in commonly owned U.S. Patent No. 9,996,566, entitled "VISUAL DESIGN SYSTEM FOR GENERATING A VISUAL DATA STRUCTURE ASSOCIATED WITH A SEMANTIC COMPOSITION BASED ON A HIERARCHY OF COMPONENTS," filed July 31, 2016 as U.S. Patent Application No. 15 / 224,579, which is incorporated herein by reference in its entirety.

[0029] Overview and Implementation of Exemplary Hybrid Website Interface Rendering Operations Exemplary embodiments of the present disclosure may proceed in several ways to enable the rendering of a hybrid website interface. Accordingly, various processes according to the present disclosure are described herein.

[0030] 1A , exemplary operations for enabling the rendering of a hybrid website interface are shown. In particular, FIG. 1A is a flowchart broadly illustrating a series of operations or process blocks in a method 100 that may be performed or implemented by a system or apparatus for enabling the rendering of a hybrid website interface, in accordance with some exemplary embodiments of the present disclosure. To avoid unnecessarily complicating the description, the operations of method 100 shown in FIG. 1A are described as being performed by a hybrid website interface rendering server, although some or all of the steps may also be performed by, with the assistance of, and / or under the control of, a system, such as a hybrid website interface rendering system or a website building system, and / or a client device (e.g., one or more of client devices 508A-508B).

[0031] For example, hybrid website interface rendering system 510 or website construction system 610 may be configured to perform method 100 for multiple different web pages, websites, etc. The operations illustrated in FIG. 1A may be performed by, with the assistance of, and / or under the control of server device 800 (e.g., shown in FIG. 8) and / or client device 900 (e.g., shown in FIG. 9). Performance of the operations may invoke one or more of memory 802, 902, processor 804, 904, input / output module 806, 906, communication module 808, 908, hybrid website interface rendering module 810, 910, and / or code splitting module 812, 912, as described in more detail below with respect to FIGS. 8 and 9.

[0032] 1A, a flowchart illustrates a method 100 that includes, at block 102, providing a primary execution environment configured to execute one or more trusted website code definition elements. In some embodiments, a hybrid website interface rendering server (e.g., hybrid website interface rendering server 512) embodied by server device 800 may include means such as memory 802, processor 804, input / output module 806, communications module 808, hybrid website interface rendering module 810, and code splitting module 812, which collectively are configured to provide a primary execution environment. An example of a primary execution environment 301 is shown above the central horizontal line 303 in FIG. 3A.

[0033] The primary execution environment is an insecure (i.e., not isolated from other environments or systems) or trusted environment, such as a web window, capable of executing code such as JavaScript (JS). In various embodiments, the primary execution environment may be a front-end (e.g., in client-side rendering), a back-end (e.g., in server-side rendering), or a combination thereof. The illustrated hybrid website interface rendering module 810 forms part of server-side software executed by a server, such as hybrid website interface rendering server 512. Although various references are made herein to a "server" or "servers," such references are not intended to imply a monolithic server. Rather, as will be apparent to those skilled in the art in light of this disclosure, the operations and functions assigned to the disclosed servers may be implemented in a cloud computing environment and thereby completed by multiple servers.

[0034] In various embodiments, the primary execution environment may be a browser window, thread, or any server-side technology used to render the main portion of a web page. In a further example, the present disclosure contemplates that some or all of the functionality of the hybrid website interface rendering module 810 may, optionally, be implemented by a client-side software application executing on one or more client devices 508A-508B, and the present disclosure is not limited to the specifically identified placement of software executed by the hybrid website interface rendering server 512. For example, in the case of server-side rendering, the primary execution environment is running on the device, platform, or software used to render the page content (HTML, CSS, or other) sent to the browser (or another user agent). Furthermore, in some embodiments, the hybrid website interface rendering server 512 providing one or more sandbox execution environments (e.g., as described in block 104 below) may be implemented on a separate server from the hybrid website interface rendering server 512 providing the primary execution environment (e.g., as described in block 102).

[0035] Although block 102 is described with respect to a single primary execution environment, it is contemplated by this disclosure that multiple primary execution environments may be used. In other words, any window or session that performs UI rendering may create, request, or provide a separate primary execution environment, for example, as an essentially separate instance.

[0036] In various embodiments, the primary execution environment is configured to execute one or more trusted website code definition elements. The trusted website code definition elements correspond to elements or code constructs that are deemed inherently safe or trustworthy by a system (e.g., via machine learning) and / or a user (e.g., a website designer or code writer). For example, in some embodiments, the trusted website code definition elements utilize a declarative programming language that can be verified to be secure via static analysis. Static code analysis involves analyzing or otherwise inspecting code without executing the program (e.g., non-executable code) to identify and / or understand the underlying code constructs. The declarative programming language (e.g., HTML, CSS, and / or JSX, etc.) is inherently secure and / or can be translated / compiled into verifiably secure code that can be executed in the primary context environment. The exact details of the declarative programming language used depend on the actual embodiment.

[0037] In some embodiments, the trusted website code definition element may include such a declaration. A trusted website code definition element defines the task or desired result of the element using a J programming language or other secure code. The functionality of the trusted website code definition element is typically UI-related. In other words, in some embodiments, the trusted website code definition element defines a function (e.g., via a J compiler) that accepts data and, when invoked, creates and / or updates one or more structures in the DOM of the hybrid website interface (e.g., returns an update function). In some embodiments, the DOM of the hybrid website interface is associated with at least one document data structure, and the at least one document data structure includes one or more of a tree-structure data structure, a forest-structure data structure, a federated architecture data structure, a graph data structure, a lookup table, an object database, a flat data structure, a hash table, or any combination thereof.

[0038] In particular embodiments, the trusted website code definition elements define the structure of the state (e.g., via a J compiler). When compiled, the trusted website code definition elements render UI code (e.g., HTML) to create and / or update the UI. That is, when the declarative programming language is compiled to generate generated code, the generated code can respond to event handlers of untrusted website code components or otherwise be triggered by untrusted website code components that virtually perform other DOM-related operations to render UI code (e.g., HTML) and create and / or update the UI.

[0039] In some embodiments, the trusted website code definition element does not include logic code or logic code subcomponents, while in other embodiments, the trusted website code definition element includes sections that include instructions, which are subsequently compiled (e.g., via a J compiler) into logic instructions.

[0040] In a non-limiting example context, a hybrid website interface ("Website A") includes a counter function. The inset below depicts an exemplary trusted website definition element ("JE Counter") for such a counter function for Website A.

number

[0041] As shown, the exemplary trusted website definition element JE counter executing in a primary execution environment (e.g., primary execution environment 301 of FIG. 3A) includes instructions for rendering two buttons (one for minus ("-") and one for plus ("+")) and a span to render a "count." The exemplary JE counter also includes a definition that "count" is a number. The JE counter further has two references ("button ref") that identify those elements for events. Most notably, the JE counter is logic-free and does not pose any security risks. The present disclosure contemplates that, in some cases, HTML may introduce scripts (e.g., inline JS event handlers, etc.), but certain embodiments of the present disclosure are configured to perform static analysis of such code and remove such scripts to a sandbox execution environment. Thus, in this non-limiting example context, the JE counter is considered a trusted website code-defining element that can be compiled into secure code.

[0042] Continuing with the JE counter example, the definition actually defines (and is later compiled into) a function of the following indented form:

number

[0043] The JE counter function accepts data, represented as a ViewState, which in the example above is defined in the data section of the JE counter file. When called, the function uses the ViewState function to create the defined structure in the DOM. The function also returns an update function that, when called with the new ViewState, updates the DOM accordingly. The data section of the JE counter file defines the ViewState structure. The root DIV JE defines the DOM structure that the function creates. Instructions embedded in the HTML, such as "forEach" (to render a list), "if" (to conditionally render), or "{variable}" (to render a value), complete the declarative JE counter file structure.

[0044] Continuing with the JE counter example, the JE counter definition file is side-effect-free and compiles to a side-effect-free function and a side-effect-free update function. A side-effect-free function, by definition, means that what it creates on the DOM structure is secure. Because the DOM structure is well-defined and declarative, it is easy to verify that it does not introduce vulnerabilities (e.g., JS event handlers). For example, in some embodiments, a simple whitelist / blacklist of DOM elements and attributes (e.g., imposed by the J compiler with no runtime penalty) can verify that the DOM structure does not introduce vulnerabilities. The combination of trusted side-effect-free website code definition elements, such as JE counters, and a well-defined DOM allows the J compiler to generate secure code.

[0045] In some embodiments, the trusted website code definition elements and / or untrusted website code components are manually identified by a user of various embodiments of the present disclosure. For example, in some cases, method 100 optionally includes receiving one or more pre-separated or pre-identified trusted website code definition elements from client device 508. In other embodiments, the method optionally includes receiving a set of integrated modules (e.g., a website code structure), which may include one or more instructions (e.g., embedded or separate) indicating how the set of integrated modules should be divided into trusted website code definition elements and untrusted website code components. In yet another embodiment, the method optionally includes analyzing the received website code structure and determining how the set of integrated modules should be divided into trusted website code definition elements and untrusted website code components. Such analysis may include analysis of website code, data from additional sources (e.g., application store information, code configuration, version tracking system, historical user data, etc.), or some combination thereof. Such program analysis may, in some embodiments, be based on various criteria defined by the system user.

[0046] In yet another embodiment, the hybrid website interface rendering server 512 (e.g., the hybrid website interface rendering system 510) optionally provides for the use of machine learning models designed to leverage artificial intelligence in connection with determining trusted website code definition elements and / or untrusted website code components. That is, such program analysis and / or determination may be performed by one or more trained machine learning models to programmatically determine and classify website code structures as trusted website code definition elements or as untrusted website code components. For example, in various embodiments of the present disclosure, the hybrid website interface rendering module 810 and / or the code splitting module 812 are configured to analyze a plurality of website code structures, which are configured to render a hybrid website interface, parse the plurality of website code structures, and programmatically determine and classify at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0047] In identifying, determining, and / or classifying website code structures as trusted or untrusted website code components, the hybrid website interface rendering server 512 (e.g., hybrid website interface rendering system 510) can draw from a range of information sources that can be fed to machine learning models to make suggestions or predictions regarding trusted and untrusted website code components. For example, any one or more of the data described herein (e.g., tracking data, historical data, etc.) and correlations thereof can be used in connection with the machine learning models. Some embodiments of the present disclosure, such as the website building system 610 described below with respect to FIG. 6, that create and / or update multiple websites, have access to a large amount of unique data that can further be used as a training corpus in connection with the machine learning models. In addition to the tracking data (e.g., data communicated view OMM) and historical data (e.g., previous identification of trusted website code definition elements and untrusted website code components) of most embodiments of the present disclosure, certain embodiments of the website building system 610 may use or access designer selection patterns, latency timing data associated with the execution of various website code structures, tested website code structures previously unrelated to hybrid website interfaces, data related to the use of website building blocks, website editing history interactions, editing history interactions, history editing interactions, electronic interaction data, transaction editing data, user preferences and their changes over time, business-related data (e.g., user revenue or projected revenue of other financial assets or transactions, whether a user has a user of users (UoU), etc.), previous results of hybrid website interface rendering configurations, trust levels in third-party code, risk levels associated with websites and / or users, and the like, which may be further used in connection with the machine learning models.

[0048] In some embodiments, different website code structures can be analyzed by machine learning models to programmatically determine trusted and untrusted website code components. Further, in some embodiments, the hybrid website interface rendering server 512 (e.g., hybrid website interface rendering system 510) can use a The machine learning-based models employed can be trained using such tracking data, historical data, etc. For example, in some embodiments, unsupervised learning structures, supervised learning structures, reinforcement learning structures, deep learning structures, clustering algorithms, etc. are implemented to programmatically determine correlations between various data and data formats to make suggestions or predictions regarding trusted and untrusted website code components.

[0049] 1A, block 104, method 100 further includes providing one or more sandbox execution environments configured to execute one or more untrusted website code components. For example, in some embodiments, hybrid website interface rendering server 512 embodied by server device 800 may include means such as memory 802, processor 804, input / output module 806, communication module 808, hybrid website interface rendering module 810, code splitting module 812, etc., collectively configured to provide one or more sandbox execution environments. An exemplary sandbox execution environment 302 is shown below central horizontal line 303 in FIG. 3A.

[0050] A sandbox execution environment is an isolation mechanism or environment for securely executing potentially untrusted code (e.g., one or more untrusted website code components). A sandbox execution environment is a secure environment (i.e., architecturally isolated from other environments or systems) in which code such as JS can be executed. Exemplary server-side sandbox execution environments include any server sandbox, such as a VM, micro-VM, container, web assembly sandbox, or node.js worker. Exemplary client-side sandbox execution environments include web workers (e.g., those defined by the W3C and WHATWG standards-setting organizations) for running background, independent, or asynchronous scripts or code (e.g., in a separate thread or process), iFrames, or any other technology or client-side code isolation mechanism. Details regarding iFrames and other mechanisms for integrating third-party applications into websites are described in commonly owned U.S. Patent No. 10,509,850, entitled "THIRD PARTY APPLICATION COMMUNICATION API," filed February 10, 2014 as U.S. Patent Application No. 14 / 176,166, which is incorporated herein by reference in its entirety. Exemplary embodiments of the present disclosure that use iFrames as a sandbox execution environment for executing such potentially untrusted code / elements reduce performance issues because the sandbox execution environment, for example, does not execute the entire third-party application, but instead executes only the logical code and not the visible design elements of the third-party application.

[0051] Exemplary embodiments of the present disclosure may use an iFrame as a sandbox execution environment for executing such potentially untrusted code / elements, but the iFrame itself runs invisible using a small area (e.g., width and height 4px or less) or is positioned off-screen using negative X and Y positions. For example, a Technical iFrame may be used that can execute scripts but is hidden from users, help tools, and keyboard navigation. In some embodiments, it may be hidden from search engine optimization (SEO) robots (e.g., by using content="noindex,nofollow"). Such hidden iFrames can be loaded quickly, reducing the performance hit compared to typical iFrames loaded with lazy-load behavior. There are no iFrames in the DOM, and in terms of load time, embodiments of the present application are much faster. For example, a table of 100x100 items where each frame updates 100 numbers in the table may be hidden from the user, help tools, and keyboard navigation. In rendering the table, embodiments of the present disclosure were three times more efficient than applications that only applied iFrames.

[0052] A myriad of other isolation mechanisms or environmental technologies (e.g., <object>element, <embed> tag, <portal>Any technology using HTML elements (including, but not limited to, Google Chrome® Portal, Asynchronous JavaScript And XML (AJAX), web components, etc.) is contemplated by this disclosure and the claims are not limited to the examples provided.

[0053] In various embodiments, the sandbox execution environment is configured to execute one or more untrusted website code components. The untrusted website code components correspond to components or code constructs that are deemed potentially or inherently unsafe by a system (e.g., via machine learning) and / or a user (e.g., a website designer) and may not be trusted to execute in the primary execution environment. For example, in some embodiments, the untrusted website code components utilize a scripting programming language such as JS.

[0054] In one embodiment, the untrusted website code component may be a third-party application or third-party code (e.g., a code construct generated outside the system). However, the untrusted website code component need not be third-party code or otherwise generated outside the system. In some embodiments, the untrusted website code component is code generated by the same website designer who generated the trusted website code definition element that executes in the primary execution environment. That is, in a non-limiting example context, the website designer may desire that a sandbox execution environment be provided and configured to execute untested, intensively tested, or otherwise insufficiently tested code in order to isolate or compartmentalize such potentially buggy or unsafe code from the thoroughly tested code executing in the primary execution environment. In yet other embodiments, certain third-party code may be designated as a trusted website code definition element if such third-party code is sufficiently tested and trusted to be considered safe.

[0055] In some embodiments, an untrusted website code component utilizes such scripting programming language or other insecure code to create data (e.g., tracking data) that its associated trusted website definition element renders. That is, the functionality of an untrusted website code component typically relates to directing UI and / or other components (e.g., logic, DB, etc.) not associated with the corresponding trusted website definition element. For example, in one embodiment, an untrusted website code component may be structured to communicate or send new data to its associated trusted website definition element using some API when some trigger is given. An untrusted website code component defines event handlers for its associated trusted website definition element. For example, an untrusted website code component listens for events from DOM elements created by its associated trusted website code definition element and / or child components of the untrusted website code component (e.g., nested untrusted website code components, nested trusted website code definition elements, etc.).

[0056] In various embodiments, the untrusted website code component is a declarative process. The untrusted website code component may define event handlers using a declarative programming language, which is then compiled into code that executes in the primary execution environment. Additionally or alternatively, in various embodiments, the untrusted website code component may define DOM manipulations directly using a declarative programming language, which is then compiled into code that executes in the primary execution environment, thereby enabling the untrusted website code component to interact with the DOM created by the trusted website code definition element. In some embodiments, the untrusted website code component includes a logic code subcomponent. Additionally or alternatively, in some embodiments, the untrusted website code component includes a presentation subcomponent. For example, the untrusted website code component may include both an untrusted website code subcomponent and a trusted website code definition element subcomponent, which are recursively split into trusted computer-executable functions and untrusted executable functions for execution in the primary execution environment and the sandbox execution environment, respectively, as described with respect to FIGS. 10-12 .

[0057] Continuing with reference to the non-limiting example context presented herein with respect to website A including a counter function, the inset diagram below depicts an exemplary untrusted website code component ("JC Counter") for such counter function of website A.

number

[0058] As shown, the CounterConstructor function constructs an exemplary untrusted website code component JC Counter in a sandbox execution environment (e.g., sandbox execution environment 302 of FIG. 3A). "createState" creates a reactive state pair of a read value function, count, and an update value function, setCount. The reactive state means that any other functions that read the value of the count function will be re-executed whenever the count value is updated.

[0059] As further shown, the JC counter has two buttons for "onclick" on either of the two buttons described above for the JE counter, which then update the count state. The JC Counter includes event handlers (e.g., subtractors and adders) for the JC Counter and a render function that returns the count state used in rendering and updating the trusted website code definition element JE Counter. That is, using the same refs as the JE Counter, when the website user clicks or otherwise interacts with either the "-" or "+" button (rendered by the JE Counter), the corresponding event handler is invoked, updating the "count," and such "count" data (e.g., state) is automatically exported or output to the JE Counter to update the UI accordingly. In other words, in the illustrated JC Counter example, the click handler is invoked each time a button is clicked in the UI, which in turn invokes setCount, thereby updating the state. The render function invokes the count reader function, which is re-executed any time the count state changes, causing the trusted website code definition element JE Counter to be updated. Additionally, the API function reset is used to reset the counter.

[0060] Continuing with the JC Counter example, the JC Counter is also a function (e.g., denoted as JC Constructor Function) that returns a render function, i.e., a ViewState that is input to the trusted website code definition element (e.g., JC Counter). To complete the full component functionality (e.g., API functions and properties, access to selected DOM elements, etc.), the JC Constructor Function may return additional API functions of the untrusted website code component JC Counter (e.g., "reset" for JC Counter) in addition to the render function. This function takes a first function parameter, Props<> (the Props of the JC Counter) <counterprops>) to support component properties. The function also accepts a second parameter, refs, which is a proxy transform component that allows access to selected DOM elements defined in trusted website code definition elements JE counters that have a ref attribute for event registration.

[0061] In one embodiment, the hybrid website interface rendering module 810 may be configured to provide a single sandbox execution environment. If one or more untrusted website code components are generated by a single third-party developer or supplier, such untrusted website code components may be executed or run in a single sandbox execution environment. In other embodiments, the hybrid website interface rendering module 810 may be configured to provide multiple sandbox execution environments. For example, if a first untrusted website code component is generated by a first third-party developer or supplier and a second untrusted website code component is generated by a second third-party developer or supplier, such untrusted website code components may be executed or run in two different sandbox execution environments. Similarly, if a third-party application embeds or nests code from other suppliers or additional parties (e.g., fourth-party code, fifth-party code, etc.), such untrusted website code components may be executed or run in two or more different / nested sandbox execution environments. Non-limiting example contexts of such multi-layer sandboxes are described in further detail with respect to FIG. 3C.

[0062] In some embodiments, a single untrusted website code component or multiple untrusted website code components may correspond to a single trusted website code definition element, but there must be a corresponding trusted website code definition element for each untrusted website code component. In other words, at least one trusted website code definition element is required for various embodiments of the present disclosure. The minimum required in

[0063] Furthermore, although providing a primary execution environment in block 102 is shown as occurring before providing one or more sandbox execution environments in block 104, the present disclosure contemplates that blocks 102 and 104 may occur in any order (e.g., block 102 may be performed consecutively after block 104, block 104 may be performed consecutively after block 102, block 104 may be performed before block 102 is completed, etc.), may occur simultaneously, etc. For example, providing a primary execution environment configured to execute one or more trusted website code definition elements and providing one or more sandbox execution environments optionally includes mapping a rendering order of the one or more trusted website code definition elements across the execution environments.

[0064] 1A, block 106, method 100 further includes providing one or more proxy translation components configured to communicatively link one or more untrusted website code components to at least one of the one or more trusted website code definition elements. For example, in some embodiments, hybrid website interface rendering server 512 embodied by server device 800 may include means such as memory 802, processor 804, input / output module 806, communication module 808, hybrid website interface rendering module 810, code splitting module 812, etc., collectively configured to provide one or more proxy translation components.

[0065] As described in block 106, in some embodiments, the proxy translation component is configured to communicatively link one or more untrusted website code components (i.e., executing in the sandbox execution environment) to at least one of the one or more trusted website code definition elements (i.e., executing in the primary execution environment). For example, in some embodiments, one or more proxy translation components (e.g., generated by the J compiler 400 as described with respect to FIGS. 4A and 4B ) are used to represent or emulate a trusted website code definition element JE or an untrusted website code component JC in a matching context. In some embodiments, the trusted website code definition element JE executing in the primary execution environment is configured to receive a trigger event and send the trigger event downstream to a subsequent proxy translation component executing in the primary execution environment (e.g., a primary execution environment proxy translation component such as a JC bridge or JC stub, as described below), which communicates the message to its corresponding untrusted website code component JC executing in the sandbox execution environment. In yet another embodiment, the trigger event is a client event resulting from a user interaction with a browser running on a client device (e.g., client device 508).

[0066] In some embodiments, the proxy translation component may be of two types: bridge type or stub type. A bridge type proxy translation component acts as a proxy to a trusted website code definition element JE or an untrusted website code component JC that has both a parent node and a child node. A stub type proxy translation component acts as a proxy to a trusted website code definition element JE or an untrusted website code component JC that has a parent node but no child nodes. It is contemplated by this disclosure that the proxy translation component may be of other types, and this disclosure is not limited to the specifically identified bridge type and stub type of proxy translation component.

[0067] In some embodiments, the proxy translation component may optionally be a primary execution environment proxy translation component (e.g., a JC bridge or a JC stub) that operates in the primary execution environment and maintains the rendering order location of the corresponding untrusted website code component JC. For example, the primary execution environment proxy translation component (e.g., a JC bridge or a JC stub) functions as if it were the untrusted website code component JC in the primary execution environment and is responsible for providing the recorded “ViewState” to the trusted website code definition element JE, registering event handlers on the trusted website code definition element JE, and returning them to the untrusted website code component JC. For example, in some embodiments, the untrusted website code component JC executes in the sandbox execution environment, and the output of the execution of the untrusted website code component JC includes tracing data, which is communicated to the corresponding primary execution environment proxy translation component (e.g., a JC bridge or a JC stub) that is executing in the primary execution environment. In some embodiments, the primary execution environment proxy translation component creates child untrusted website code components (e.g., in the case of nested components) as if they were created by a trusted website code definition element.

[0068] Such secure code components may execute in either the primary execution environment or the sandbox execution environment. Additionally or alternatively, in some embodiments, secure code components are used by event handlers of trusted website code definition elements and / or as actions triggered by untrusted website code components.

[0069] Additionally or alternatively, in some embodiments, the proxy translation component may optionally be a sandbox execution environment proxy translation component (e.g., a JE bridge or a JE stub) that operates in a sandbox execution environment (e.g., including a nested context or nested execution environment) and preserves the rendering order location of corresponding trusted website code definition elements.

[0070] The proxy translation component enables various embodiments of the present disclosure to operate with a single Object Messaging Method (OMM) message per update cycle that can invoke update methods of all untrusted website code components JCs in the sandbox execution environment, which in turn can invoke updates of all trusted website code definition elements in the primary execution environment. The sandbox execution environment proxy translation component (e.g., a JE Bridge or JE Stub as shown in Figures 2-4) enables a single tree to be constructed in a secure context (e.g., the sandbox execution environment) for all untrusted website code components JCs, rendering all data within the sandbox execution environment and recording all inputs to trusted website code definition elements. Additionally or alternatively, the primary execution environment proxy translation component (e.g., a JC Bridge as shown in FIGS. 2-4) may construct a single tree for all trusted website code definition elements in the primary execution environment, thereby rendering all trusted website code definition elements into a DOM using the recorded data of the sandbox execution environment proxy translation component (e.g., a JE Bridge as shown in FIGS. 2-4) as input provided to the trusted website code definition elements by the primary execution environment proxy translation component (e.g., a JC Bridge as shown in FIGS. 2-4). Two such trees, i.e., the trusted website code definition elements and the primary execution environment proxy translation component (e.g., a JC Bridge as shown in FIGS. 2-4), may be constructed. The first tree of untrusted website code components and sandbox execution environment proxy translation components (e.g., JC, JE bridge, and JE stubs as shown in FIGS. 2-4 ) and the second tree of untrusted website code components and sandbox execution environment proxy translation components (e.g., JC, JE bridge, and JE stubs as shown in FIGS. 2-4 ) together enable a single message exchange using the OMM to enable full rendering of the DOM. Example embodiments of the present disclosure can aggregate multiple messages sent from one execution environment to another (propagating messages within the recipient tree) to affect such full rendering or otherwise conserve bandwidth and communication between multiple execution environments.

[0071] Additionally, in some embodiments, a declarative programming language (JLang) expression may also be extracted from the untrusted website code component JC to be executed in the primary execution environment as a secure code component or function. In other words, various embodiments of the present disclosure extract a declarative programming language (JLang) expression from a presentation code subcomponent of the untrusted website code component and compile the extracted declarative programming language (JLang) expression to form a secure code component or function that executes in the primary execution environment (e.g., thereby enabling support for gated APIs (GAPIs) that are gated in a secure manner by user activation). In various embodiments of the present disclosure, two or more programs (a program executing trusted code in a primary execution environment that invokes one or more other programs executing untrusted code in a sandbox execution environment) are running. APIs designated as GAPIs (e.g., APIs gated by user interaction, such as the "window.open" or "HTMLMediaElement.play" APIs (or other modal windows)) are typically prevented from operating when using two or more programs. The GAPI is a browser API that can only be activated when a user is actively interacting with a website (e.g., for security or user experience reasons) to ensure that applications cannot abuse the API (e.g., popup prevention mechanisms). Thus, the GAPI can prevent the use of background scripts as part of the browser security model. Asynchronous calls to the GAPI (e.g., postMessage to a Worker or iFrame) or HTTP requests may not work due to GAPI usage restrictions.Various embodiments of the present disclosure enable the ability to write untrusted code compiled into trusted code to handle events directly within a first program (i.e., the primary execution environment running the trusted code) so that the GAPI can be called synchronously. In other words, a portion of an untrusted website code component written in a declarative programming language (e.g., JLang) may be, for example, an event handler that is compiled into secure code that runs in the primary execution environment directly following an event, thus enabling use of the GAPI. Because the untrusted code for the event handler is written in a declarative programming language, a compiler (e.g., J compiler 400 as shown in Figures 4A and 4B) can verify that it is "safe" and does not cause any intentional side effects that could compromise the secure environment. A non-limiting contextual example of an event handler with a declarative programming language for the GAPI is as follows:

number

[0072] In the above example, the counter plays an audio file (e.g., defined as an audio element in the trusted website code definition element JE) when the counter value is an even number. $onXXX represents a function in a declarative programming language, which is then extracted from the untrusted website code component, replaced with an identifier, compiled into a safe function, and included in the corresponding primary execution environment proxy translation component (e.g., JC Bridge) of the untrusted website code component.

[0073] Continuing with this example, when an event handler of a trusted website code definition element (e.g., a click event handler of a subtraction element) is triggered, the primary execution environment proxy translation component (e.g., a JC bridge) processes the event, executes the extracted and compiled declarative programming language expression, tracks the result of the declarative programming language expression, and sends it back to the sandbox execution environment along with an identifier. Next, an event handler of an untrusted website code component is triggered (e.g., .then()) and receives as input the value returned from the declarative programming language expression. The J compiler then verifies that the declarative programming language expression can be compiled into a safe code representation.

[0074] 1A, block 108, method 100 further includes causing rendering of a hybrid website interface after at least one trusted website code definition element and one or more untrusted website code components have been executed via one or more proxy translation components. For example, in some embodiments, hybrid website interface rendering server 512 embodied by server device 800 may include means such as memory 802, processor 804, input / output module 806, communication module 808, hybrid website interface rendering module 810, code splitting module 812, etc., which collectively render a hybrid website interface to client device 508A via a browser window. 508B is configured to cause the rendering of a hybrid website interface on the visual display of 508B.

[0075] 1B is a signal diagram of an exemplary data flow represented by method 100. FIG. 1B shows an exemplary signal diagram illustrating data flow interactions between exemplary components of system 500 of FIG. 5, including a hybrid website interface rendering server, a repository, and a client device, when implementing hybrid website interface rendering, according to one embodiment. Method 100 is described as being performed by client device 508, hybrid website interface rendering server 512, and hybrid website interface rendering repository 514. These system components may be similar to those described with respect to hybrid website interface rendering system 510 shown in FIG. 5.

[0076] FIG. 2 is a flowchart broadly illustrating a series of operations or process blocks in a method 200 performed or implemented by a system or device to enable rendering of a hybrid website interface in accordance with another exemplary embodiment of the present disclosure. As with FIG. 1A , the operations of method 200 illustrated in FIG. 2 are described as being performed by a hybrid website interface rendering server 512 to avoid unnecessarily overcomplicating the discussion. The operations illustrated in FIG. 2 may be performed by, with the assistance of, and / or under the control of, a server device 800 (e.g., shown in FIG. 8 ) and / or a client device 900 (e.g., shown in FIG. 9 ). In this regard, performance of the operations may invoke one or more of memory 802, 902, processor 804, 904, input / output module 806, 906, communication module 808, 908, hybrid website interface rendering module 810, 910, and / or code splitting module 812, 912, as described in more detail below with respect to FIGS. 8 and 9 .

[0077] 2 , a flowchart illustrates a method 200 that includes accessing a code repository to identify at least one untrusted website code component and at least one trusted website code definition element at block 202. For example, in some embodiments, the hybrid website interface rendering server 512 embodied by the server device 800 may include means such as a memory 802, a processor 804, an input / output module 806, a communications module 808, a hybrid website interface rendering module 810, and a code splitting module 812, which are collectively configured to access the code repository to identify at least one untrusted website code component and at least one trusted website code definition element.

[0078] In some embodiments, a plurality of website code structures configured to render a hybrid website interface are stored in a code repository (e.g., hybrid website interface rendering repository 514, third-party system 570, a combination thereof, etc.). For example, in some embodiments, one or more integrated sets of website code structures may include one or more instructions (e.g., embedded or separate) indicating how the website code structures should be divided into trusted website code components and / or untrusted website code components.

[0079] In yet another embodiment, the method 200 optionally includes analyzing the website code structure in a code repository and analyzing the website code structure in a trusted website. and determining how the website code structures should be split into trusted website code definition elements and untrusted website code components. Such analysis may include analysis of the website code structure, data from additional sources (e.g., application store information, code configuration, version tracking systems, etc.), or some combination thereof. Such program analysis, in some embodiments, may be based on various criteria defined by a system user. In yet other embodiments, such program analysis, determination, and / or identification may be performed by one or more trained machine learning models to programmatically determine and classify website code structures as trusted website code definition elements or as untrusted website code components. In various embodiments of the present disclosure, the hybrid website interface rendering module 810 and / or the code splitting module 812 analyze the website code structures in the code repository, parse the website code structures, and programmatically determine and classify at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0080] Turning to block 204 of FIG. 2 , a flowchart illustrates a method 200 that includes converting at least one untrusted website code component into a primary execution environment proxy translation component, while the at least one untrusted website code component continues to operate within a sandbox execution environment. For example, in some embodiments, the hybrid website interface rendering server 512 embodied by the server device 800 may include means such as a memory 802, a processor 804, an input / output module 806, a communications module 808, a hybrid website interface rendering module 810, and a code splitting module 812, which are collectively configured to convert at least one untrusted website code component into a primary execution environment proxy translation component. In some embodiments, the primary execution environment proxy translation component (e.g., a JC bridge or a JC stub) functions as if it were an untrusted website code component (JC) in the primary execution environment and is responsible for providing a “ViewState” recorded to the trusted website code definition element (JE), registering event handlers on the trusted website code definition element (JE), and returning them to the untrusted website code component (JC). In some embodiments, the primary execution environment proxy translation component creates child untrusted website code components (e.g., in the case of nested components) as if they were created by a trusted website code definition element.

[0081] Turning to block 206, a flowchart illustrates method 200 including generating a primary execution environment configured to execute at least one trusted website code definition element and a primary execution environment proxy translation component. For example, in some embodiments, hybrid website interface rendering server 512 embodied by server device 800 may include means such as memory 802, processor 804, input / output module 806, communication module 808, hybrid website interface rendering module 810, code splitting module 812, etc., collectively configured to generate a primary execution environment. The primary execution environment is an unsecured (i.e., not isolated from other environments or systems) or trusted environment, such as a web window, capable of executing code such as JS.

[0082] Turning to block 208, the flowchart illustrates the process of establishing at least one trusted website. 8 illustrates a method 200 that includes causing rendering of a hybrid website interface after the untrusted website code definition element and at least one untrusted website code component are executed via a primary execution environment proxy translation component. For example, in some embodiments, the hybrid website interface rendering server 512 embodied by the server device 800 may include means such as a memory 802, a processor 804, an input / output module 806, a communications module 808, a hybrid website interface rendering module 810, and a code splitting module 812, which are collectively configured to cause rendering of a hybrid website interface for visual display on the client devices 508A-508B via browser windows.

[0083] In a non-limiting context, Figure 3A illustrates a simplified runtime control / data flow diagram for rendering a hybrid website interface according to various embodiments disclosed herein. Figure 3A illustrates the major components of an exemplary embodiment and the proposed flow between them. In the illustrated embodiment, the application logical structure (e.g., the one in which a developer writes the application) has an application main root (MainRoot[1]), which uses a first untrusted website code component (JC[2]) and a first trusted website code definition element (JE[3]), which in turn uses another second untrusted website code component (JC[4]), which uses another second trusted website code definition element (JE[5]) to render the hybrid website interface. The logical data flow of the rendering is represented by dashed line (6).

[0084] Continuing with the non-limiting example context shown in FIG. 3A , various embodiments of the present disclosure may actually execute website code at runtime by executing a first untrusted website code component (JC[2]), a second untrusted website code component (JC[4]), a first proxy translation component (JE Bridge[8]), and a second proxy translation component (JE Stub

[10] ) in a sandbox execution environment 302 (e.g., below the center horizontal line 303) using communication line (7), while a first trusted website code definition element (JE[3]), a second trusted website code definition element (JE[5]), and another proxy translation component (JC Bridge[9]) execute in the primary execution environment 301 (e.g., above the center horizontal line 303) to render a hybrid website interface.

[0085] FIG. 3B illustrates a similar but more complex use case of a control / data flow diagram at runtime for rendering a hybrid website interface, according to various embodiments disclosed herein. In the illustrated embodiment, the untrusted website code component JC and the trusted website code definition element JE communicate bidirectionally (e.g., from JC to JE and from JE to JC) using Object Messaging Methods (OMM). For example, the untrusted website code component JC sends the trusted website code definition element JE data to render when triggered, or which declarative programming expressions to execute (and their inputs). The trusted website code definition element JE returns data about events occurring in the DOM to the untrusted website code component JC. The J Compiler creates the code and interfaces necessary to implement such communication. Information exchanged between the untrusted website code component JC and the trusted website code definition element JE can include canonical data (e.g., content information), pointers to pre-compiled declarative programming language expressions, and actual event data. It may include pre-defined (e.g., and pre-compiled) declarative programming language expressions, declarative programming language expressions compiled during runtime using an analytical just-in-time (JIT) version of the J compiler, etc.

[0086] 3B , during site load / initialization, main root [1] is invoked by a website browser or any computer program, and main root [1] invokes (e.g., using any available OMM) sandbox root [2] running in sandbox execution environment 302. In other words, various embodiments of the present disclosure receive a code execution request, which triggers an execution instruction to a trusted root website code definition component (e.g., main root [1]) in primary execution environment 301, which then sends another execution instruction to an untrusted root website code component (e.g., sandbox root [2]) in sandbox execution environment 302.

[0087] At this point, the sandbox execution environment 302 executes the code in the sandbox tree, simulating the same invocation / rendering order (e.g., depth-first search or other related methods) as the trusted website code definition element JE would be invoked / rendered. However, because this execution is performed in the sandbox execution environment 302, it does not result in or perform actual rendering. Instead, it simply keeps track of and / or records the data being modified in the untrusted website code component JC while the sandbox execution environment 302 "replays" or simulates the rendering of the code. During this process, proxy translation components, JE bridges

[11] ,

[12] ,

[13] ,

[14] , and JE stubs

[15] ,

[16] ,

[17] ,

[18] , track the input data received from the untrusted website code component JC. The untrusted website code component JC begins execution by executing the sandbox root [2], and the sandbox execution environment 302 is responsible for setting up the necessary isolation structures and supporting elements (e.g., Workers, iFrames, or other isolation mechanisms) at runtime.

[0088] Continuing with reference to the illustrated embodiment of FIG. 3B , during site load / initialization, tracking data is sent back to the main root [1], which executes the actual rendering sequence of the trusted website code definition element JE and the proxy translation component in the primary execution environment 301. During this process, the JC Bridge

[21] ,

[22] ,

[23] ,

[24] ,

[25] ,

[26] ,

[27] , and

[28] provide tracking data from the proxy translation components (JE Bridge and JE Stub) to the trusted website code definition element JE for the actual rendering and initial rendering of the hybrid website interface. In the illustrated example shown in FIG. 3B , data tracked by the proxy translation component JE Bridge

[11] is used as input data for rendering the trusted website code definition element JE

[31] , while data tracked by the proxy translation component JE Bridge

[13] is used as input for rendering the trusted website code definition element JE

[33] . It is contemplated by the present disclosure that such runtime execution may occur for user code, generated code, and / or third-party code.

[0089] Continuing with reference to the illustrated embodiment of FIG. 3B, during website serving, different events (e.g., from the user, from other servers, over the network, WBS events, including website events, etc.) may be received that necessitate updating the hybrid website interface rendering. Client events (e.g., arising from user interaction with a browser) are handled by the trusted website. The event is received or "caught" using an event listener in the trusted website code definition element JE, and when the event arrives, the trusted website code definition element JE passes it "up" to the corresponding JC bridge, which then sends a message (e.g., via any associated OMM) to its corresponding "twin" untrusted website code component JC running in the sandbox execution environment 302, which may trigger "virtual rendering" downstream. The output data of the untrusted website code component JC is tracked / recorded and sent back to the proxy translation component JC bridge, the data is compared, and rendering by the trusted website code definition element JE is effected (e.g., updated rendering) if necessary.

[0090] In accordance with the present disclosure, system embodiments may be responsible for routing events and / or messages between untrusted website code components JC and trusted website code definition elements JE (e.g., via any associated OMM), and it is contemplated that other event routing tasks may be handled external to the system of the present invention. Exemplary object messaging methods (OMM) include HTML5 PostMessage, use of URL fragment identifiers for messages, dedicated communication web services, via HTML5 local storage, via HTML5 local file system access APIs, dedicated browser plug-ins, local shared objects (LSOs) (e.g., Flash cookies), and other communication methods that may be developed in the future. Details regarding some of these communication methods are described in commonly owned U.S. Patent No. 10,509,850, entitled "THIRD PARTY APPLICATION COMMUNICATION API," filed February 10, 2014 as U.S. Patent Application No. 14 / 176,166, which is incorporated herein by reference in its entirety. Myriad other communication methods are contemplated by this disclosure, and the scope of the claims is not limited to the examples provided.

[0091] In some embodiments, the proxy translation component may optionally include compiled declarative programming language code (e.g., extracted from the corresponding untrusted website code component) that performs some expression on the event received from the trusted website code definition element, and invokes the GAPI or extracts data from the event and / or DOM model to send back to the event handler of the untrusted website code component JC. For example, with continued reference to the illustrated embodiment of FIG. 3B , if an event is triggered by the trusted website code component JE

[33] running in the primary execution environment 301, the trusted website code component JE

[33] reports the event to the proxy translation component JC Bridge

[23] , which in turn sends a message (e.g., using an OMM message or other means) to the untrusted website code component JC

[32] running in the sandbox execution environment 302. The untrusted website code component JC

[32] performs a simulated or virtual rendering of itself and the downstream tree of the untrusted website code component, thereby tracking data on the proxy translation component JE Bridge

[13] and JE Stubs

[15] ,

[16] . This tracking data is then sent back to the primary execution environment 301 and used to actually render the subtree of the proxy translation component JC Bridge

[23] .

[0092] 3C illustrates another, more complex use case of a control / data flow diagram for rendering a hybrid website interface with a multi-tier or nested-tier sandbox execution environment, according to various embodiments disclosed herein. Various embodiments of the present disclosure are directed to a scenario in which website code or an application uses third-party code (e.g., including JC and JE) that in turn interacts with other third-party code (e.g., The sandbox execution environments 302A and 302B may be logically nested, such as when using multiple third-party code structures (e.g., JC and JE). Such multiple third-party code structures may be provided (or executed) by a single third party or developer, or by multiple additional parties (e.g., a third party, a fourth party, a fifth party, etc.). In such cases, the runtime layout becomes a tree of trusted website code definition elements JE and proxy translation components within the primary execution environment 301, with two or more sandbox execution environments 302A, 302B, each executing the potentially unsafe code of each third-party code, including instances where one third-party code is nested within another.

[0093] As shown in the embodiment of Figure 3C, a website page constructed using various embodiments of the present disclosure generally has a single trusted website code definition element tree and multiple untrusted website code component trees. It is further contemplated by the present disclosure that a page may include multiple display contexts (e.g., separate popup windows) that are treated by various embodiments of the present disclosure as separate instances (e.g., each with its own execution environment, 301, 302A, 302B, trusted website code definition element tree, and untrusted website code component tree).

[0094] 3C , during the compilation phase, the J compiler reads the trusted website code definition element JE and untrusted website code component JC of the main or primary website or application, as well as the trusted website code definition element and untrusted website code component JC of the third party and fourth party. The J compiler then generates three bundles: (i) a secure bundle that includes code generated from the trusted website code definition element JE of the main or primary website or application, from the trusted website code definition element JE of the third party code, and from the trusted website code definition element JE of the fourth party code, (ii) a sandbox 1 bundle that includes the untrusted website code component JC of the third party code, and (iii) a sandbox 2 bundle that includes the untrusted website code component JC of the fourth party code. As shown by JC[2] and JC[4] executing in primary execution environment 301 in the embodiment of FIG. 3C, the present disclosure contemplates that any third-party code from the main application may optionally be included in the secure bundle as a "trusted" JC (e.g., after being compiled from a declarative programming language and therefore verified for security, and assuming they are initially trusted at a higher level).

[0095] 3C, during the runtime phase, the main root [1] running in the primary execution environment 301 is invoked by a website browser or any computer program and begins rendering "trusted" JCs [2], [4] and trusted website code definition elements JEs [3] without sandboxing or isolation mechanisms. As discussed above, "trusted" JCs [2], [4] are third-party code component structures that have achieved a sufficient level of trust to allow them to optionally run in the primary execution environment 301.

[0096] Continuing with reference to the illustrated embodiment of FIG. 3C, when the trusted website code definition element JE[3] tree reaches the third-party untrusted website code component JC[5], the trusted website code definition element JE[3] will Invokes (e.g., via an OMM message) another computer program running in the sandbox execution environment 302A. In other words, in some embodiments, the rendering order includes at least the trusted root website code definition element (e.g., main root[1]) of the primary execution environment 301 and the untrusted root website code component (e.g., sandbox root

[18] ) of the first sandbox execution environment 302A.

[0097] Continuing with reference to the illustrated embodiment of FIG. 3C, the code (e.g., sandbox tree) in the first sandbox execution environment 302A simulates the same invocation / rendering order as the trusted website code definition element JE would be invoked / rendered in the sandbox / secure environment, as described above. During this process, the proxy translation component JE Bridge [8] tracks input data received from the untrusted website code component JC [6]. Because the untrusted website code component JC is from another third party (e.g., a fourth party), the first sandbox execution environment 302A simulates fourth-party code, such as the proxy translation component JC Bridge

[11] ,

[12] , which records the input data of the corresponding untrusted website code component JC. The recorded data from the proxy translation component, JE Bridge, and JC Bridge is returned by the sandbox root

[18] to the trusted website code definition element JE [3] executing in the primary execution environment 301, thereby enabling the rendering of the remainder of the trusted website code definition element tree.

[0098] Continuing with reference to the illustrated embodiment of FIG. 3C, when rendering of the trusted website code definition element tree reaches a trusted website code definition element JC with an untrusted website code component JC (e.g., JC[7]) from a fourth party, it invokes a second program running in the second sandbox execution environment 302B. Additionally or alternatively, in some embodiments, rendering of the proxy translation component JE Bridge [8] in the first sandbox execution environment 302A triggers fourth-party rendering. The fourth-party code executes in the Sandbox 2 tree within the second sandbox execution environment 302B, simulating the invocation / rendering order of the fourth-party trusted website code definition element in a different sandbox / secure environment. During this process, the proxy translation component JE Stub

[16] ,

[17] records input, which is then returned to the trusted website code definition element JE[7] by the sandbox root

[13] of the second sandbox execution environment 302B, thereby continuing the rendering process.

[0099] A non-limiting contextual example of a multi-tier or nested-tier sandbox execution environment according to Figure 3C is provided below. This example demonstrates the composition of components into a composite component (e.g., a table component built with row and cell components). The untrusted website code component (JC) of the table component provides the following:

number

[0100] The Trusted Website Code Definition Element (JE) for the Table Component provides:

number

[0101] The Tableau component's Untrusted Website Code component (JC) provides:

number

[0102] The Tableau Component's Trusted Website Code Definition Element (JE) provides:

number

[0103] The Untrusted Website Code component (JC) of the table cell component provides:

number

[0104] The Trusted Website Code Definition Element (JE) for the table cell component provides:

number

[0105] Such examples are intentionally trivial, but demonstrate the functionality of composition and can still be rendered in a single message cycle between the primary and sandbox execution environments.

[0106] It is contemplated by the present disclosure that various embodiments of the system may use multiple execution units executing the same structure (e.g., because JC and JE trees are aligned / homomorphic). It is also contemplated by the present disclosure that various embodiments of the system may execute using a simulation mode (e.g., executing a JC tree and sending the results to a trusted website code definition element). If the system needs to support interaction (e.g., due to a user click or a change in database information), various embodiments of the system may be configured to re-execute only the subtree associated with the node to which the interaction event applies. Such a simulation may need to provide specific handling (e.g., if any) of the side effects of the executed code.

[0107] This disclosure contemplates that in some cases, code may not be properly categorized as a trusted website code definition element JE or an untrusted website code component JC. This disclosure also contemplates that code may be capable of execution in both the primary execution environment 301 and the sandbox execution environment 302. For example, code related to metering, profiling, security, provisioning, underlying infrastructure, or other system aspects that is neither a trusted website code definition element nor an untrusted website code component, or both.

[0108] 10 , exemplary operations for enabling rendering of a hybrid website interface according to another embodiment of the present disclosure are shown. In particular, FIG. 10 is a flowchart broadly illustrating a series of operations or process blocks in a method 1000 that may be performed or implemented by a system or apparatus for enabling rendering of a hybrid website interface according to some exemplary embodiments of the present disclosure. To avoid unnecessarily complicating the explanation, the operations of method 1000 shown in FIG. 10 are described as being performed by a hybrid website interface rendering server, although some or all of the steps may also be performed by, with the assistance of, and / or under the control of, a system such as a hybrid website interface rendering system or a website building system, and / or a client device (e.g., one or more of client devices 508A-508B).

[0109] For example, a hybrid website interface rendering system 510 or The website building system 610 may be configured to perform the method 1000 for a plurality of different web pages, websites, code-based content, etc. The operations illustrated in Figure 10 may be performed by, with the assistance of, and / or under the control of a server device 800 (e.g., shown in Figure 8) and / or a client device 900 (e.g., shown in Figure 9). Performance of the operations may invoke one or more of memory 802, 902, processor 804, 904, input / output module 806, 906, communication module 808, 908, hybrid website interface rendering module 810, 910, and / or code splitting module 812, 912, as described in more detail below with respect to Figures 8 and 9.

[0110] 10 , a flowchart illustrates a method 1000 that includes identifying one or more trusted code sections in an untrusted candidate code corpus at block 1002. For example, the untrusted candidate code corpus may include multiple website code structures configured to render a hybrid website interface, and such an untrusted candidate code corpus may be stored in one or more code repositories (e.g., hybrid website interface rendering repository 514, third-party system 570, a combination thereof, etc.).

[0111] In some embodiments, block 1002 is performed, at least in part, by a compiler. For example, in some embodiments, the compiler applies one or more analyses to selectively identify such trusted code sections. The compiler may use static analysis to analyze uncompiled code and identify one or more trusted code sections based on one or more algorithms, pattern matching, rules, etc. That is, the compiler may use one or more code analysis factors to make suggestions or predictions for identifying trusted code sections. For example, identifying one or more trusted code sections includes identifying one or more detectable code patterns, such as matching sections of candidate untrusted code with predetermined patterns of code that are considered safe.

[0112] Code that may be considered trusted code may be defined by a user (e.g., a system provider, a vendor, a third party, a website, an application designer, a developer, etc.), a set of rules or patterns, a machine learning algorithm, a verification process, etc., or some combination thereof. For example, a user may predefine that certain code syntax is trusted code. In another example, trusted code may be code defined to use APIs that are unavailable in a sandbox execution environment and have recognized patterns that can be verified using static analysis and / or machine learning. In yet another embodiment, identifying one or more trusted code sections is based at least in part on code sections that use one or more permitted APIs. In some embodiments, the compiler may apply static analysis to match code sections in the untrusted candidate code corpus with predetermined code patterns (e.g., detectable code patterns). In other words, in a preliminary stage, certain patterns of trusted code are identified as trusted code sections. In yet another embodiment, the compiler applies a trusted identification model as described in more detail herein with respect to FIG. 11 .

[0113] 10, block 1004, the method 1000 further includes extracting one or more trusted code sections from the untrusted candidate code corpus. For example, selectively removing one or more trusted code sections from the untrusted candidate code corpus such that only untrusted code remains in the untrusted candidate code corpus. The sections (i.e., one or more division points) in the untrusted candidate code corpus extracted from the trusted code sections become placeholders with associated identifiers through which later information (e.g., at runtime) can be transmitted between the trusted and untrusted code sections (e.g., trusted and untrusted computer-executable functions communicatively interconnected, such as via intercommunication). In this way, information remains able to flow through the code after one or more trusted code sections have been extracted from the candidate code corpus. In some embodiments, block 1004 is performed, at least in part, by a compiler. For example, in some embodiments, a compiler extracts one or more trusted code sections from the untrusted candidate code corpus.

[0114] At block 1006 of FIG. 10 , method 1000 further includes generating one or more trusted computer-executable functions based on the one or more trusted code sections. In some embodiments, block 1006 is performed, at least in part, by a compiler. For example, the extracted one or more trusted code sections are used to generate (e.g., compile) one or more respective trusted computer-executable functions capable of executing the respective one or more trusted code sections. A trusted computer-executable function may receive as input the output of another computer-executable function (e.g., an untrusted computer-executable function). Additionally or alternatively, another computer-executable function (e.g., an untrusted computer-executable function) may receive as input the output of the trusted computer-executable function. The one or more trusted computer-executable functions optionally execute or are expected to execute in the primary execution environment.

[0115] Turning to block 1008 of FIG. 10 , method 1000 further includes generating one or more untrusted computer-executable functions based on the one or more untrusted code sections remaining in the untrusted candidate code corpus. For example, the one or more untrusted code sections may be defined by one or more division points resulting from the one or more trusted code sections being extracted. In some embodiments, block 1008 is performed, at least in part, by a compiler. For example, in some embodiments, a compiler extracts one or more trusted code sections from the untrusted candidate code corpus. The one or more untrusted code sections may then be used to generate (e.g., compile) respective one or more untrusted computer-executable functions capable of executing the respective one or more untrusted code sections. The untrusted computer-executable function may receive as input the output of another computer-executable function (e.g., a trusted computer-executable function). Additionally or alternatively, the other computer-executable function (e.g., a trusted computer-executable function) may receive as input the output of the untrusted computer-executable function. One or more untrusted computer-executable functions are optionally executed or expected to be executed in a sandbox execution environment.

[0116] Additionally or alternatively, method 1000 optionally further includes statistically generating a report based on one or more compilation performance metrics during compilation (e.g., during block 1008) and providing the statistically generated report to a user. For example, an untrusted computer-executable function may require access to an API that is unavailable to the untrusted computer-executable function in the sandbox execution environment; method 1000 may optionally include reporting such issue to a user via the statistically generated report so that it can be addressed during compilation and before proceeding to block 1010.

[0117] At block 1010 of FIG. 10 , method 1000 further includes rendering a hybrid website interface after one or more trusted computer-executable functions are executed in the primary execution environment and one or more untrusted computer-executable functions are executed in the sandbox execution environment. For example, a provider hosting a website service may receive code-based content from a third party configured to provide a hybrid website interface. To securely execute the third-party code-based content, the provider may perform a code splitting operation in accordance with embodiments described herein. Once the third-party code-based content is compiled as one or more trusted computer-executable functions in the primary execution environment and one or more untrusted computer-executable functions in the sandbox environment, the provider may securely execute the code in each environment, thereby rendering the hybrid website interface that the code-based content is configured to provide. By executing untrusted code in the sandbox execution environment, the provider executing the third-party code-based content is protected from potentially malicious or erroneous code.

[0118] Overview and Embodiments of Exemplary Reliable Code Splitting Operations Exemplary embodiments of the present disclosure may proceed to automatically perform reliable code splitting on an unreliable candidate code corpus in several ways. Accordingly, various processes according to the present disclosure are described herein.

[0119] Turning now to FIG. 11 , exemplary operations for automatically performing reliable code splitting on an unreliable candidate code corpus are shown. In particular, FIG. 11 is a flowchart broadly illustrating a series of operations or process blocks of a method 1100 that may be performed or implemented by a system or apparatus for automatically performing reliable code splitting, according to some exemplary embodiments of the present disclosure. To avoid unnecessarily complicating the explanation, the operations of method 1100 shown in FIG. 11 are described as being performed by a hybrid website interface rendering server, although some or all of the steps may also be performed by, with the assistance of, and / or under the control of a hybrid website interface rendering server, a system (e.g., a hybrid website interface rendering system or a website building system), and / or a client device (e.g., one or more of client devices 508A-508B).

[0120] For example, website construction system 610 may be configured to perform method 1100 for a plurality of different web pages, websites, code-based content, etc. The operations illustrated in Figure 11 may be performed by, with the assistance of, and / or under the control of server device 800 (e.g., shown in Figure 8) and / or client device 900 (e.g., shown in Figure 9). Performance of the operations may invoke one or more of memory 802, 902, processor 804, 904, input / output module 806, 906, communication module 808, 908, hybrid website interface rendering module 810, 910, and / or code splitting module 812, 912, as described in more detail below with respect to Figures 8 and 9.

[0121] 11, a flowchart illustrates a method 1100 that includes applying a trusted code identification model to an untrusted candidate code corpus to automatically and selectively identify one or more trusted code sections at block 1102. In some embodiments, a server embodied by server device 800 (e.g., hybrid website interface rendering server 512) includes memory 802, The system may include means such as a processor 804, an input / output module 806, a communications module 808, a hybrid website interface rendering module 810, and a code splitting module 812, which are collectively configured to apply a trusted code identification model to an untrusted candidate code corpus. In some embodiments, trusted code sections are code sections that are trusted to execute in a primary execution environment and are considered inherently safe or secure.

[0122] An untrusted candidate code corpus may include multiple code sections (e.g., website code structures configured to render a hybrid website interface), and such an untrusted candidate code corpus may be stored in one or more code repositories (e.g., hybrid website interface rendering repository 514, third-party system 570, a combination thereof, etc.).

[0123] One or more trusted code sections may be selectively identified by applying a trusted code identification model to an untrusted code corpus. That is, the trusted code identification model may apply one or more analyses to identify such trusted code sections. For example, in some embodiments, the trusted code identification model may apply one or more algorithms (e.g., array adjustment), pattern matching, and / or rules to identify trusted code sections. That is, the trusted code identification model may apply one or more defined rules and / or match one or more defined code patterns to identify sections of code in the candidate untrusted code corpus as trusted code sections. In yet another embodiment, the trusted code identification model may use one or more policies to define which identifiable code patterns and / or APIs are considered trusted given a particular use case. For example, the trusted code identification model may be used to enforce third-party permissions by restricting which code patterns and APIs third-party code can execute in the primary execution environment. That is, embodiments of the present disclosure may benefit from any collected business information regarding use of the same / previous code from other uses or similar situations.

[0124] In some embodiments, the trusted code identification model may use one or more code analysis factors to make suggestions or predictions regarding trusted code sections. For example, in some embodiments, the trusted code identification model applies one or more trusted code identification rules to automatically identify one or more trusted code sections, where the one or more trusted code identification rules are based on one or more code analysis factors. In a non-limiting example context, the trusted code identification model may identify one or more potential trusted code sections based on code analysis factors, such as collected and / or historical code identification data that demonstrates the same or similar code sections are being performed elsewhere throughout the WBS.

[0125] Additionally or alternatively, in some embodiments, the trusted code identification model may use one or more code analysis factors to make suggestions or predictions regarding untrusted code sections. For example, in some embodiments, the trusted code identification model applies one or more trusted code identification rules to automatically identify one or more untrusted code sections (e.g., based on the code sections not satisfying the trusted code identification rules), where the one or more trusted code identification rules are based on one or more code analysis factors. In another non-limiting example context, the trusted code identification model may use one or more code analysis factors to identify untrusted code sections elsewhere throughout the WBS, such as past use of such code for malicious purposes. One or more potentially unreliable code sections may be identified based on one or more code analysis factors, such as collected and / or historical code identification data (e.g., security history) that demonstrates execution of the same or similar code sections in

[0126] In yet some further embodiments, the trusted code identification model may be an AI-based model or a non-AI-based model. For example, in a non-limiting example, the trusted code identification model may be a non-AI-based model that applies pattern matching to an abstract syntax tree (AST), which is a tree representation of source code. The trusted code identification model may identify one or more detectable code patterns that were previously deemed safe and / or optionally unsafe (e.g., past use of a detectable code pattern for malicious purposes). In particular, the trusted code identification model may apply static analysis to match sections of a candidate untrusted code corpus in the AST with predetermined code patterns (e.g., detectable code patterns). In another example, the trusted code identification model is a non-AI-based model that identifies trusted code sections (or untrusted code sections) based on naming conventions. In yet a further example, identifying one or more trusted code sections is based at least in part on corresponding trusted code sections using one or more authorized APIs. Additionally or alternatively, in some embodiments, identifying one or more untrusted code sections may be based at least in part on corresponding untrusted code sections using one or more unauthorized APIs. In yet another example, the trusted code identification model applies declarative code recognition, as described herein, to identify declarative code as trusted code sections.

[0127] In some embodiments, the trusted code identification model is optionally iteratively trained to identify one or more detectable code patterns in trusted code sections (or untrusted code sections) in a supervised training process. For example, the trusted code identification model may be trained based on one or more of system provider-defined trusted code, vendor-defined trusted code, or third-party-defined trusted code. Additionally or alternatively, in some embodiments, the trusted code identification model is optionally iteratively trained to identify one or more detectable code patterns in trusted code sections in an unsupervised training process.

[0128] A non-limiting contextual example of the code splitting operation according to block 1102 is provided below. This example demonstrates applying a reliable code identification model to a sample unreliable candidate code corpus to automatically identify one or more reliable code sections. In this contextual example, the unreliable candidate code corpus includes:

number

[0129] In this example context, the security policy is enforced by the sandbox execution environment. The goal is to disallow the trusted code from interacting with the DOM and / or DOM events, and selectively extract or extract such DOM event interactions for compilation into trusted code that can be executed in the primary execution environment. Thus, in this example context, the relevant rules applied by the trusted code identification model include: (1) event is a parameter of the event handler, of Type Event (native browser event type). (2) Allow access to event.target.value (3) Allow access to event.which (4) Do not allow access to any other event attributes

[0130] Using these identified rules, the trusted code identification model processes the code sections in the untrusted candidate code corpus and identifies any section of code that conforms to the given rules as a trusted code section. Continuing with the non-limiting example context, the trusted code identification model identifies (event.target).value as HTMLInputElement, setEditText(value), and event.which as trusted code sections. Any remaining code not identified as trusted code is identified as untrusted code sections by default.

[0131] 11 , block 1104 of method 1100 further includes extracting one or more trusted code sections from the untrusted candidate code corpus. In this manner, the untrusted candidate code corpus is split at one or more points of the extracted trusted code sections. Such trusted code sections may be split or extracted to ultimately be compiled for execution in the primary execution environment. The remaining code in the untrusted candidate code corpus is ultimately compiled for execution in one or more sandbox execution environments.

[0132] 11 , method 1100 further includes generating one or more trusted computer-executable functions based on the one or more trusted code sections. In other words, the code sections identified as trusted code sections in block 1102 and extracted from the untrusted candidate code corpus in block 1104 may be compiled as one or more trusted computer-executable functions. A trusted computer-executable function is a computer-executable function that can be executed in a primary execution environment. Continuing with reference to the non-limiting example context, the trusted code sections may be generated as the following trusted computer-executable functions:

number

[0133] In some embodiments, the trusted computer-executable functions may be generated in compliance with one or more predetermined rules.

[0134] 11 , the method 1100 further includes generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus. For example, one or more untrusted computer-executable functions may be generated, each untrusted computer-executable function being based on one or more sections of untrusted code. The untrusted computer-executable functions are computer-executable functions that may be executed in a sandbox execution environment. Continuing with the non-limiting example context above, the remaining untrusted code sections may be generated as the following untrusted computer-executable functions:

number

[0135] Like trusted computer-executable functions, untrusted computer-executable functions may be generated in accordance with one or more predetermined rules.

[0136] In some embodiments, generating one or more trusted computer-executable functions and generating one or more untrusted computer-executable functions may include generating an intercommunication path between the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions. The intercommunication path may be configured to transmit one or more execution input parameters, one or more execution return values, or a combination thereof, between the one or more trusted computer-executable functions during execution of the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions. By generating such an intercommunication path, the present disclosure provides, for example, the ability to capture results of execution of the trusted computer-executable functions in the primary execution environment and return or place such captured results into the untrusted computer-executable function (i.e., in place of the extracted trusted code section) to continue execution in the sandbox execution environment. That is, in some embodiments, a placeholder with a corresponding identifier is placed in place of the extracted trusted code in the untrusted computer-executable function executing in the sandbox execution environment, and the captured results from the primary execution environment are returned to the placeholder. In other words, trusted code sections are extracted from untrusted code, replaced with identifiers, and compiled into safe, trusted computer-executable functions that can be executed in the primary execution environment. Events are processed in the primary execution environment, and the results of the execution of the trusted computer-executable functions are tracked and sent back to the sandbox execution environment using the identifiers. An event handler of the untrusted computer-executable function is then triggered (e.g., .then()) and receives as input the value returned from the trusted computer-executable function. Thus, even if the code is currently divided into trusted and untrusted computer-executable functions according to given rules, information such as input parameters and / or return values ​​can flow between some generated functions as needed.In this way, the code can function correctly when executed at runtime, even after being separated into several generated functions that execute in different execution environments. For example, in some embodiments, one or more trusted computer-executable functions and one or more untrusted computer-executable functions securely and efficiently obtain the intended results of the untrusted candidate code corpus (e.g., a hybrid website interface). They are executed in the primary and sandbox execution environments, respectively, to render the

[0137] In another non-limiting example context, an exemplary untrusted candidate code corpus for rendering a to-do list is provided below.

number

[0138] According to block 1102 of method 1100, a trusted code identification model can be applied to such an untrusted candidate code corpus. In this non-limiting example context, the trusted code identification model applies the following relevant rules to identify safe patterns of code: (1) Read event.target.value (2) Read event.keyCode (3) Reading a const variable (4) Using strings (5) The event.preventDefault() event is a parameter of the event handler and is of Type Event (native browser event type).

[0139] Using these identified rules, the trusted code identification model may process code sections in the untrusted candidate code corpus for rendering the to-do list and identify sections of code that conform to the given rules as trusted code sections. Continuing with the non-limiting example context, the trusted code identification model identifies event.target as HTMLInputElement).value, event.keyCode===ENTER_KEY)?event.preventDefault():”, and event.keyCode as trusted code sections. The remaining code not identified as trusted code is identified as untrusted code sections by default.

[0140] Continuing with the to-do list example, embodiments of the present disclosure may further include extracting the trusted code section identified from the untrusted candidate code corpus according to block 1104. That is, event.target as H TMLInputElement).value, event.keyCode===ENTER_KEY)?event.preventDefault():”, and event.keyCode are extracted, removed, or otherwise separated from the unreliable candidate code corpus.

[0141] Continuing with reference to the to-do list example, embodiments of the present disclosure may further include generating one or more trusted computer-executable functions based on the one or more trusted code sections, and generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the candidate untrusted code corpus, according to blocks 1106 and 1108, respectively. For example, the extracted trusted code sections may be replaced with a placeholder and a unique ID, as indicated by handler$.

number

[0142] The extracted trusted code sections may then be compiled into trusted computer-executable code functions for execution in the primary execution environment.

number

[0143] In some embodiments, multiple code structures may be generated from each source code structure. That is, the present disclosure contemplates that a compiler may be configured for, for example, simultaneous generation of multiple code variants. For example, given a source code section, at least one trusted code section and at least one untrusted code section may be identified in accordance with various embodiments described herein. Thus, at least one trusted computer-executable code function or trusted website code component may be generated, and at least one untrusted computer-executable code function or untrusted website code component may be generated. When trusted website code definition elements and untrusted website code components are generated, corresponding element bridges and component bridges may also be generated. Additionally or alternatively, multiple types of code structures may be generated. For example, for each generated code structure, there may be a respective type generated corresponding to static site generation (SSG), server-side rendering (SSR), client-side rendering (CSR), etc.

[0144] In some embodiments, multiple code structures may be generated from each source code structure for optimization, efficiency, simplification, etc. For example, if the code structure includes an "if" statement, one code structure may be generated corresponding to a true evaluation of the "if" statement, and another code structure may be generated corresponding to a false evaluation of the "if" statement. In some embodiments, multiple code structures may be generated from a source code structure based on whether the code structure is static, dynamic, or hybrid, and / or based on processes and / or properties associated with the code structure.

[0145] In various embodiments, decisions regarding generated code structures (e.g., trusted computer-executable functions, untrusted computer-executable functions, website code definition elements, untrusted website code components, SSG-based code structures, SSR code-based structures, CSR-based code structures, etc.) may be performed by the compiler rather than at runtime. In other words, which code structures are generated and how they are configured may be determined by the compiler outside of runtime.

[0146] 11 , method 1100 optionally further includes executing one or more trusted computer-executable functions in the primary execution environment and one or more untrusted computer-executable functions in the sandbox execution environment. In a non-limiting example, executing the one or more trusted computer-executable functions in the primary execution environment and the one or more untrusted computer-executable functions in the sandbox execution environment may render a hybrid website interface.

[0147] While the focus of this disclosure is to provide a secure system for executing code, this disclosure contemplates that, in some cases, non-executable code may be acceptable or even desirable. For example, a particular section of code in the untrusted candidate code corpus may not have a detectable or recognized code pattern or may not otherwise qualify as a trusted code section, and therefore may not meet the requirements to be identified as a trusted code section. For example, an attacker may use malicious code to attempt to exploit a system running on or connected to the malicious code. In other examples, erroneous code may unintentionally pose a security and / or stability threat to a system running on or connected to the erroneous code. In either scenario, the malicious / erroneous code may result in an unrecognized code pattern, resulting in the particular code not being identified and / or extracted as a trusted code section, and such code may be executed in the sandbox execution environment, even if such code section requires an API that is not available in the sandbox execution environment. It is not extracted or retrieved from the untrusted candidate code corpus, but instead is generated (e.g., compiled) as an untrusted computer-executable function. At runtime, such untrusted computer-executable functions cannot be executed in the sandbox execution environment because the required APIs are not available. Such code executing in the sandbox execution environment cannot access sensitive APIs because they are not available in the sandbox execution environment, and the vulnerable system The system is no longer exposed to the threat of malicious / errant code. In other words, this code may be considered an attempt to subvert the sandbox and / or circumvent the security system, and therefore it is acceptable that this code cannot be executed in the sandbox execution environment.

[0148] Additionally or alternatively, method 1100 optionally further includes generating a function structure at block 1112 of Figure 11. For example, in some embodiments, a first trusted computer-executable function of the one or more trusted computer-executable functions is communicatively coupled to a second untrusted computer-executable function via an intercommunication path such that, during execution, an output of the first trusted computer-executable function serves as an input to the second untrusted computer-executable function, or an output of the second untrusted computer-executable function serves as an input to the first trusted computer-executable function. Still further, the second untrusted computer-executable function may be communicatively coupled to a third trusted computer-executable function such that, during execution, an output of the second untrusted computer-executable function serves as an input to the third trusted computer-executable function, or an output of the third trusted computer-executable function serves as an input to the second untrusted computer-executable function.

[0149] In a non-limiting example, the structures of functions f1(), f2(), and f3() may be generated from function f() based on identifying one trusted code section and two untrusted code sections within f(). For example, the untrusted candidate code corpus may include one section of identifiable trusted code. After a code splitting operation, one section of trusted code is extracted and the remaining untrusted code is split into two sections. f1() and f3() are untrusted computer-executable functions based on the first and second sections of untrusted code, respectively. f2() is a trusted computer-executable function based on the section of trusted code. At runtime, the untrusted computer-executable functions f1() and f3() are executed in a sandbox execution environment, while the trusted computer-executable function f2() is executed in a primary execution environment. The output of f1() serves as the input to f2(), and the output of f2() serves as the input to f3(). Thus, the runtime execution is formally performed as f() ≈ f3(f2(f1())).

[0150] In another non-limiting example, a more complex structure of functions f1(), f2(), f3(), f4(), and f5() may similarly be generated based on two trusted code sections and three untrusted code sections. f1(), f3(), and f5() are untrusted computer-executable functions based on the first, second, and third sections of untrusted code, respectively. f2() and f4() are trusted computer-executable functions based on the first and second sections of trusted code, respectively. At runtime, the untrusted computer-executable functions f1(), f3(), and f5() are executed in a sandbox execution environment, while the trusted computer-executable functions f2() and f4() are executed in a primary execution environment. The output of f1() serves as input to f2(), the output of f2() serves as input to f3(), the output of f3() serves as input to f4(), and the output of f4() serves as input to f5(). Therefore, the runtime execution is formally performed as f() ≈ f5(f4(f3(f2(f1())))).

[0151] Overview and Embodiments of Exemplary Secure Code-Based Content Implementations Exemplary embodiments of the present disclosure may proceed to implement secure code-based content in a supply chain in several ways. Accordingly, various processes according to the present disclosure are described herein.

[0152] Turning now to FIG. 12 , exemplary operations for implementing secure code-based content in a supply chain are shown. In the embodiment shown in FIG. 12 , a flowchart illustrates a method 1200 that, at block 1202, includes receiving code-based content from a code synthesis entity at a trusted entity. In some embodiments, the code synthesis entity may generate, produce, sell, etc., the code-based content. The code synthesis entity may send such code-based content to the trusted entity for processing. For example, a code supply chain may include a code synthesis entity, a trusted entity, and a code consuming entity. In such a code supply chain, the trusted entity may receive the code-based content from the code synthesis entity to help facilitate a safe and secure supply chain for the code-based content to be consumed.

[0153] In some embodiments, the code synthesis entity may generate the code-based content using a library or framework that supports code-splitting operations according to various embodiments described herein. For example, the code synthesis entity may optionally perform code-splitting operations on the code-based content before transmitting the code-based content to a trusted entity for testing, development, etc. In some embodiments, the code synthesis entity may optionally generate a candidate secure distribution of the code-based content after such code-splitting operations. In some embodiments, the code synthesis entity may transmit to the trusted entity the original code-based content (that has not undergone such code-splitting operations), the candidate secure distribution of the code-based content, and / or portions thereof (e.g., only the trusted code section of the code-based content after performing the candidate secure distribution).

[0154] Turning to block 1204 of FIG. 12 , method 1200 further includes identifying, at the trusted entity, at least one trusted code section of the code-based content. For example, depending on the portions and / or format of the code-based content transmitted by the code synthesis entity to the trusted entity, the trusted entity may or may not be required to perform a code splitting operation to identify the trusted code sections. For example, if the code synthesis entity transmits only trusted code sections of the code-based content (after performing a candidate secure distribution), the trusted entity may identify the received content as at least one or more trusted code sections. In another example, if the trusted entity receives the original code-based content (that has not undergone such a code splitting operation) and / or a candidate secure distribution of the code-based content, the trusted entity may perform a code splitting operation that includes identifying one or more trusted code sections of the code-based content received from the code synthesis entity. For example, the trusted entity may apply a trusted code identification model to automatically identify one or more trusted code sections of the code-based content. The trusted code identification model may apply one or more analyses to identify such trusted code sections, such as those described herein with respect to FIG. 11 . For example, in some embodiments, the trusted code identification model may apply one or more algorithms, pattern matching, and / or rules to identify trusted code sections, or the trusted code identification model may be an AI-based model according to various embodiments described herein. That is, the trusted code identification model may use one or more code analysis factors to reliably identify trusted code sections. The trusted entity may also make suggestions or predictions regarding which code sections (and / or which code sections) can be trusted. Additionally, the trusted entity may modify the results of the code splitting operation on the candidate secure distribution of the code base content.

[0155] In some embodiments, the trusted entity may optionally verify the code-based content. For example, in some cases, method 1200 optionally includes the trusted entity verifying the code-based content at some time after block 1202. In some embodiments, after receiving the code-based content from the code synthesis entity, the trusted entity may verify (e.g., approve) that the code-based content complies with one or more agreements, regulations, etc. The trusted entity may perform the verification at any time after receiving the code-based content, such as before or after performing any code splitting operations. The trusted entity may block, reject, and / or approve code-based content pending verification.

[0156] Turning to block 1206 of FIG. 12 , method 1200 further includes, at the trusted entity, compiling at least one or more trusted code sections for execution in the primary execution environment. For example, the trusted entity may generate (e.g., compile) the one or more trusted code sections as one or more trusted computer-executable functions for execution in the primary execution environment. That is, at runtime, such trusted computer-executable functions are executed in the primary execution environment. In some embodiments, the trusted entity may optionally further compile one or more untrusted code sections for execution in the sandbox execution environment. For example, if the trusted entity, the code consuming entity, and / or the fourth party are executing the untrusted code sections as part of an executable code package, the trusted entity may generate (e.g., compile) the one or more untrusted code sections as one or more untrusted computer-executable functions in the sandbox execution environment. At runtime, such untrusted computer-executable functions are executed in the sandbox execution environment.

[0157] In some embodiments, the code synthesis entity may execute such untrusted code sections in a sandbox execution environment operating on the code synthesis entity's system and provide the results of such execution to the code consuming entity, thereby eliminating the need for the trusted entity to compile the untrusted code sections. In this manner, the code consuming entity knows that the extracted trusted code has not been tampered with because it has been compiled and / or verified by the trusted entity, but the code synthesis entity need not disclose all of the code to the code consuming entity. In yet another embodiment, the code consuming entity may receive (e.g., consume) the compiled untrusted code sections directly from the code synthesis entity and, because such compiled untrusted code sections are executed in a sandbox execution environment, may execute such compiled code safely.

[0158] 12, block 1208, the method 1200 further includes generating an executable code package based at least on the compiled trusted code sections. For example, the trusted entity may generate an executable code package (e.g., a bundle in the case of browsers and JavaScript ecosystems) that includes the compiled trusted code sections (e.g., trusted computer-executable functions) for subsequent execution in the primary execution environment. In this embodiment, the trusted entity may optionally further generate an executable code package based on the one or more compiled untrusted code sections. For example, the trusted entity may generate an executable code package that includes trusted code sections (e.g., trusted computer-executable functions) compiled for later execution in the primary execution environment and that includes untrusted code sections (e.g., untrusted computer-executable functions) compiled for later execution in the sandbox execution environment. In some embodiments, the trusted entity may optionally further verify (e.g., approve) that the executable code package complies with one or more agreements, regulations, etc. In some embodiments, the trusted entity may optionally further transmit the executable code package to a code consuming entity.

[0159] In some embodiments, the executable code package enables a code consuming entity to consume the trusted code sections. For example, the code consuming entity may receive an executable code package including trusted code sections (e.g., trusted computer-executable functions) compiled for execution in a primary execution environment. The code consuming entity may then execute the executable code package. In some embodiments, the code consuming entity may consume the trusted code sections from a trusted entity. For example, the trusted entity may execute the executable code package including trusted code sections (e.g., trusted computer-executable functions) compiled for execution in a primary execution environment and send data indicative of the results of the execution to the code consuming entity.

[0160] In some embodiments, the executable code package enables a code consuming entity to consume the untrusted code sections. For example, the code consuming entity may receive an executable code package including untrusted code sections compiled for execution in a sandbox execution environment. The code consuming entity may then execute the executable code package. In some embodiments, the code consuming entity may consume the untrusted code sections from a trusted entity. For example, the trusted entity may execute the executable code package including the untrusted code sections compiled for execution in a sandbox execution environment and send data indicative of the results of the execution to the code consuming entity. In some embodiments, the code consuming entity may consume the untrusted code sections from a code synthesis entity. For example, the code synthesis entity may execute a candidate secure distribution of code-based content including the untrusted code sections compiled for execution in a sandbox execution environment and send data indicative of the results of the execution to the code consuming entity.

[0161] In a non-limiting example context, a code synthesis entity may use method 1200 or the like to selectively expose its code to code consuming entities. For example, in server-side rendering (SSR), embodiments of the present disclosure may be used to identify certain code as untrusted (e.g., with a $ suffix) so that the code remains at and can be executed by the code synthesis entity, thereby enabling the code synthesis entity to make decisions regarding what types of code to send to code consuming entities. For example, in the following code example for a guestbook application, code with a $ suffix may be executed server-side to be excluded from clients:

number

[0162] In another non-limiting example context, a code synthesis entity may use method 1200 or the like to selectively expose its code to code consuming entities. For example, in a static site generation (SSG), embodiments of the present disclosure may be used to identify certain code as untrusted (e.g., having a $$ suffix) so that the code remains with the code synthesis entity and even resolves certain items at build time, thereby improving the speed at which the website is rendered. For example, in the following code example for a guestbook application, the code with a $$ suffix is ​​resolved at build time (e.g., the title, the number of assignments to the guestbook name, etc.), and the code that loads the guestbook vote count is resolved server-side and is not even sent to the client:

number

[0163] 1-3C, 10, 11, and 12 illustrate flowcharts and signal diagrams illustrating the operation of apparatuses, methods, systems, and computer program products according to example embodiments contemplated herein. Each method or process described herein may include any number of operational blocks defining a process and / or portions thereof. It should be understood that in some embodiments, the various processes and / or subprocesses described herein may be combined in any manner, such that an embodiment may be configured to combine, perform parallel and / or serially, aspects of the various processes. In some embodiments, at least one additional and / or at least one alternative operation is performed in one or more of the described processes, and / or at least one operation is deleted from one or more of the described processes.

[0164] Similarly, although operations are shown in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or in any sequential order, or that all of the illustrated operations be performed, to achieve desirable results, unless otherwise stated. In certain situations, multitasking and parallel processing may be preferred. Similarly, in some cases, actions recited in the claims can be performed in a different order and still achieve desirable results.

[0165] Additionally, optional operations may be illustrated in one or more of the process or flow diagrams depicted herein using dashed lines (or "broken lines"). In this regard, the processes described herein are merely examples, and the scope of the disclosure is not limited to the exact operations illustrated and described, nor is the illustrated and described operations intended to be within the scope and spirit of the embodiments described herein and encompassed by the appended claims. It should be understood that the present invention should not be limited to the above.

[0166] In some embodiments, one or more of the devices, apparatuses, modules, and / or systems disclosed herein, alone or in combination, are configured to perform any number and / or combination of the processes described herein. Each of the described processes may be modified or implemented in any of a myriad of ways without departing from the spirit of the present disclosure. In some embodiments, a process is embodied in a computer-implemented method executable by any of a myriad of computing device implementations or combinations thereof described herein, including the client device 508, hybrid website interface rendering system 510, hybrid website interface rendering server 512, etc. described herein.

[0167] Furthermore, it will be understood that each flowchart block, and combinations of flowchart blocks, may be implemented by various means, such as hardware, firmware, processors, modules, circuits, and / or other devices associated with executing software that includes one or more computer program instructions. As will be understood, any disclosed computer program instructions may be loaded into a computer or other programmable device (e.g., hardware) to produce a machine, such that the resulting computer or other programmable device implements the functions specified in the flowchart blocks. For example, one or more of the operations described above may be implemented by a device that executes computer program instructions. These computer program instructions may also be stored in a computer-readable memory that can direct the computer or other programmable device to function in a particular manner, such that the instructions stored in the computer-readable memory create an article of manufacture, the execution of which implements the functions specified in the flowchart blocks. The computer program instructions may also be loaded onto a computer or other programmable device to perform a series of operations on the computer or other programmable device to create a computer-implemented process, such that the instructions, executing on the computer or other programmable device, provide operations for implementing the functions specified in the flowchart blocks. In this regard, for example, computer program instructions may be stored by a memory 802 of a server (e.g., hybrid website interface rendering server 512) and executed by a processor 804 of the server (e.g., hybrid website interface rendering server 512).

[0168] The flowchart blocks support a combination of means for performing the specified functions and a combination of operations for performing the specified functions. It will be understood that one or more blocks of the flowcharts, and combinations of blocks of the flowcharts, may be implemented by a dedicated hardware-based computer system that performs the specified functions, or a combination of dedicated hardware and computer instructions.

[0169] Exemplary System Architecture The methods, apparatus, systems, and computer program products of the present disclosure may be embodied by any of a variety of computing devices. For example, the methods, apparatus, systems, and computer program products of the exemplary embodiments may be embodied by a network device (e.g., an enterprise platform), such as a server or other network entity, configured to communicate with one or more devices, such as one or more client devices. Additionally or alternatively, the computing device may include a stationary computing device, such as a personal computer or computer workstation. Still further, the exemplary embodiments may be embodied by any of a variety of mobile devices, such as a personal digital assistant (PDA), a mobile phone, a smartphone, a laptop computer, a tablet computer, a wearable, or any combination of the foregoing devices. Therefore, it may be embodied.

[0170] FIG. 5 illustrates a block diagram of an exemplary computing system that may be specially configured with embodiments of the present disclosure in which it may operate. In this regard, FIG. 5 provides an overview of a computing system 500 that may include one or more devices and subsystems configured to perform some or all of the various operations and processes described herein. In some examples, such a system 500 implements the rendering of a hybrid website interface via a hybrid website interface rendering system 510 in accordance with some embodiments described herein. In other words, the various illustrated devices of the computing system 500 communicate in some embodiments to enable the rendering of a hybrid website interface. In other examples, such a system 500 implements trusted code splitting in accordance with some embodiments described herein. In other words, the various illustrated devices of the computing system 500 communicate in some embodiments to enable trusted code splitting.

[0171] The computing system 500 is shown with a hybrid website interface rendering system 510 communicatively connected to one or more client devices 508A-508B (referred to as "client devices 508"; the depiction of the client devices in "B" of FIG. 5 is for illustrative purposes only) via a network 502. In other words, a user may access the hybrid website interface rendering system 510 via at least one communications network 502 using one or more of the client devices 508A-508B. In some embodiments, each of the client devices 508A-508B is embodied by one or more user-facing computing devices embodied in hardware, software, firmware, and / or combinations thereof configured to perform some or all of the hybrid website interface rendering functionality described herein. That is, the client devices 508A-508B may include circuitry, modules, network processors, suitable network servers, and / or other types of processing devices (e.g., the controllers or computing devices of the client devices 508). For example, in some embodiments, client device 508 is embodied by a personal computer, a desktop computer, a laptop computer, a computing terminal, a smartphone, a netbook, a tablet computer, a personal digital assistant, a wearable device, a smart home device, and / or other network device that may be used for any suitable purpose in addition to performing some or all of the hybrid website interface rendering functionality described herein. In some example contexts, client devices 508A-508B are configured to execute one or more computing programs to perform various functions described herein.For example, client devices 508A-508B may execute a web-based application or applet (e.g., accessible via a website), a software application (e.g., an "app") installed on client devices 508A-508B, or other computer-coded instructions accessible to client devices 508A-508B.

[0172] In some embodiments, client devices 508A-508B may include various hardware, software, firmware, etc. for interacting with hybrid website interface rendering system 510. In other words, client devices 508A-508B may be configured to access hybrid website interface rendering system 510 and / or to render the hybrid website interface (e.g., via software applications running on client devices 508). The client devices 508A-508B may be configured to render information provided by the hybrid website interface rendering system 510. According to some embodiments, the client devices 508A-508B include displays for rendering various interfaces, including one or more hybrid website interfaces. For example, in some embodiments, the client devices 508A-508B are configured to display such interfaces on the displays of the client devices 508A-508B for viewing, editing, and / or otherwise interacting with at least selected documents that may be provided by the hybrid website interface rendering system 510.

[0173] Returning to FIG. 5 , in some embodiments, hybrid website interface rendering system 510 includes one or more servers, such as hybrid website interface rendering server 512. For example, hybrid website interface rendering system 510 may implement some of its functionality on a server or set of servers (e.g., hybrid website interface rendering server 512) and some of its functionality on client elements (e.g., client devices 508A-508B). In some embodiments, hybrid website interface rendering system 510 dynamically determines whether to implement some functionality on a server or a client platform. In some embodiments, hybrid website interface rendering system 510 includes other servers and components, as described below with respect to the exemplary illustrated embodiment of website building system 610 of FIG. 6 .

[0174] The hybrid website interface rendering server 512 may be any suitable network server and / or other type of processing device. In this regard, the hybrid website interface rendering server 512 may be embodied by any of a variety of devices; for example, the hybrid website interface rendering server 512 may be embodied as a computer or multiple computers. For example, the hybrid website interface rendering server 512 may be configured to receive / transmit data and may include any of a variety of fixed terminals, such as a server, desktop, or kiosk, or any of a variety of mobile terminals, such as a personal digital assistant (PDA), mobile phone, smartphone, laptop computer, tablet computer, or, in some embodiments, a peripheral device that connects to one or more fixed or mobile terminals. Example embodiments contemplated herein may have a variety of form factors and designs, but nevertheless include at least some of the components shown and described with respect to the server device 800 of FIG. 8 . The hybrid website interface rendering server 512, in some embodiments, may include several servers or computing devices performing interconnected and / or distributed functions. Notwithstanding the many configurations contemplated herein, the hybrid website interface rendering server 512 is shown and described herein as a single computing device to avoid unnecessarily overcomplicating the present disclosure.

[0175] In some embodiments, hybrid website interface rendering server 512 is configured, via one or more software modules, hardware modules, or a combination thereof, to access communication network 502 to communicate with one or more of client devices 508. Additionally or alternatively, hybrid website interface rendering server 512 is configured, via software, hardware, or a combination thereof, to perform any of a myriad of processes associated with implementing hybrid website interface rendering. In other words, hybrid website interface rendering server 512 may include circuits, modules, network processors, etc. configured to perform some or all of the hybrid website interface rendering functionality as described herein. In this regard, for example, in some embodiments, hybrid website interface rendering server 512 receives and processes data (e.g., data communicated between trusted website code definition elements, untrusted website code components, proxy translation components, untrusted candidate code corpora, trusted code identification models, etc.).

[0176] In some embodiments, hybrid website interface rendering system 510 includes at least one repository, such as hybrid website interface rendering repository 514. Such a repository may be hosted by hybrid website interface rendering server 512 or by a device that is in other ways in communication with hybrid website interface rendering server 512. As shown, in some embodiments, hybrid website interface rendering server 512 is in communication with hybrid website interface rendering repository 514. In some embodiments, hybrid website interface rendering server 512 may be located remotely from hybrid website interface rendering repository 514. In this regard, in some embodiments, hybrid website interface rendering server 512 is directly coupled to hybrid website interface rendering repository 514 in hybrid website interface rendering system 510.

[0177] Additionally or alternatively, in some embodiments, hybrid website interface rendering server 512 is wirelessly coupled to hybrid website interface rendering repository 514. In yet other embodiments, hybrid website interface rendering repository 514 is embodied as a subsystem of hybrid website interface rendering server 512. That is, hybrid website interface rendering server 512 may include hybrid website interface rendering repository 514. Additionally or alternatively, in some embodiments, hybrid website interface rendering repository 514 is embodied as a virtual repository executing on hybrid website interface rendering server 512.

[0178] The hybrid website interface rendering repository 514 may be embodied by hardware, software, or a combination thereof for storing, generating, and / or retrieving data and information utilized by the hybrid website interface rendering system 510 to perform the operations described herein. For example, the hybrid website interface rendering repository 514 may be stored by any suitable storage device configured to store some or all of the information described herein (e.g., the memory 802 of the hybrid website interface rendering server 512, or a memory system separate from the hybrid website interface rendering server 512, such as one or more database systems provided by another device (e.g., an online application or third-party provider), a back-end data server, a network database, a cloud storage device, etc., such as a network-attached storage (NAS) device, or a separate database server (e.g., in a cloud computing environment, etc., thereby completed by multiple servers). The hybrid website interface rendering repository 514 may be stored by any suitable storage device configured to store some or all of the information described herein (e.g., the memory 802 of the hybrid website interface rendering server 512, or a memory system separate from the hybrid website interface rendering server 512, such as one or more database systems provided by another device (e.g., an online application or third-party provider), a back-end data server, a network database, a cloud storage device, etc., such as a network-attached storage (NAS) device, or a separate database server (e.g., in a cloud computing environment, etc., thereby completed by multiple servers). The hybrid website interface rendering repository 514 may include data received from the hybrid website interface rendering server 512 (e.g., via memory 802 and / or processor 804), a third party, and / or the client device 508, and accordingly, a corresponding storage device may store this data. The hybrid website interface rendering repository 514 may store various data in any of a myriad of manners, formats, tables, computing devices, etc. For example, in some embodiments, the hybrid website interface rendering repository 514 includes one or more sub-repositories configured to store specific data processed by the hybrid website interface rendering system 510. The hybrid website interface rendering repository 514 includes information accessed and stored by the hybrid website interface rendering server 512 to facilitate the operation of the hybrid website interface rendering system 510.

[0179] A hybrid website interface rendering system 510 (e.g., a hybrid website interface rendering server 512) can communicate with one or more client devices 508A-508B via a communications network 502. The communications network 502 may include any one or more wired and / or wireless communications networks, including, for example, a wired or wireless local area network (LAN), a personal area network (PAN), a metropolitan area network (MAN), a wide area network (WAN), etc., or a combination thereof, as well as any hardware, software, and / or firmware (e.g., network routers, switches, hubs, etc.) necessary to implement the one or more networks. For example, the communications network 502 may include cellular, mobile broadband, Long Term Evolution (LTE), GSM / EDGE, UMTS / HSPA, IEEE 802.11, IEEE 802.16, IEEE 802.20, Wi-Fi, dial-up, and / or WiMAX networks.

[0180] Additionally, communication network 502 may include a public network such as the Internet, a private network such as an intranet, or a combination thereof, and may utilize a variety of currently available or later developed networking protocols, including, but not limited to, Transmission Control Protocol / Internet Protocol (TCP / IP)-based networking protocols. For example, a networking protocol may be a JavaScript Object Class (Object Class) transmitted over a WebSocket channel. The protocol may be customized to suit the needs of the hybrid website interface rendering system 510, such as JSON Object Notation (JSON). In some embodiments, the protocol is JSON over RPC, JSON over REST / HTTP, or the like, or a combination thereof.

[0181] In some embodiments, the hybrid website interface rendering system 510 is a standalone system. In other embodiments, the hybrid website interface rendering system 510 is embedded within a larger editing system. In certain embodiments, the hybrid website interface rendering system 510 is associated with a visual design system, and further, in some embodiments, the visual design system is one or more of a document building system, a website building system, or an application building system. It is also contemplated by the present disclosure that the hybrid website interface rendering system 510 may be used to define, create, and / or render compositions or documents of various sizes and scopes, such as page sections, single web pages, multiple web pages, complete websites, third-party applications, complex or composite page components, etc. Additionally or alternatively, the present disclosure provides a hybrid website interface rendering system 510. It is further contemplated that the web interface rendering system 510 may be used in non-web environments or embodiments, such as applications that provide execution or automation environments (e.g., Excel® supporting Excel® macros), IoT, build pipelines, etc.

[0182] An exemplary embodiment of a hybrid website interface rendering system (e.g., hybrid website interface rendering system 510 as shown in FIG. 5) is illustrated in FIG. 6. In particular, FIG. 6 illustrates a computing system 600 that includes a website building system (“WBS”) 610 as an exemplary hybrid website interface rendering system for, e.g., creating and / or updating hierarchical websites and / or reliable code splitting.

[0183] The WBS 610 may be online (i.e., the application is edited and stored on a server or set of servers), offline, or partially online (the website is edited locally but uploaded to a central server for publication). The WBS 610 may be accessed by various users over the network 602, including designers, who are users who design the website; subscribers, subscribing users or site editors; and code editors; and end users, who are "users of users" who access the created website. End users may typically access the WBS 610 in a read-only mode, although the WBS (and website) may allow end users to make changes to the website, such as adding or editing data records, adding talkbacks to news articles, or adding blog entries to blogs.

[0184] In some embodiments, WBS 610 may authorize multiple levels of users, with different permissions and capabilities associated with and / or assigned to each level. For example, users may register with WBS 610 (e.g., via a WBS server that manages users, websites, and end-user access parameters).

[0185] 6 , in addition to a hybrid website interface rendering service 612 and a hybrid website interface rendering repository 614, a WBS 610 may include a WBS site manager 605, an object marketplace 615, a runtime (RT) server 620, a WBS editor 630, a site creation system 640, and a WBS content management system 700. The WBS 610 is shown in communication with embodiments of client devices 508A-508B, which are shown as operated by a WBS vendor staff member 608A, a WBS site designer 608B (i.e., a user), a site visitor 608N (i.e., a user of users), and an external system 670. For example, the WBS vendor staff member 608A may be an employee of the associated website building system vendor and may create and maintain various WBS elements, such as templates, content / layout elements, etc. In some embodiments, the site designer 608B may use the WBS 610 to build his or her own site for use by the site visitor 608N.

[0186] Additionally or alternatively, site designer 608B may be an external site designer or consultant, although a website building system vendor may employ site designer 608B, for example, to create a template site for inclusion in WBS 610. In some embodiments, site viewers 608N may only view the system. Additionally or alternatively, in some embodiments, site viewers 608N may be permitted some form of site input or editing (e.g., sending talkbacks or posting blog posts). In yet another embodiment, WBS 610 is configured to allow viewers 608N to build (e.g., user pages) within a social networking site. The site viewers 608N may also include site designers 608B.

[0187] In some embodiments, WBS Site Manager 605 is used by site designer 608B to manage the sites he or she creates (e.g., to process payments for site hosting or to set permissions for site access). In some embodiments, WBS RT (runtime) server 620 handles runtime access by one or more (e.g., potentially many) site viewers 63. In some embodiments, such access is read-only, but in certain embodiments, such access includes interactions that may affect back-end data or front-end displays (e.g., purchasing a product or posting a comment on a blog). In some embodiments, WBS RT server 620 serves pages to site designer 608B (e.g., when previewing a site or as a front-end to WBS editor 630).

[0188] In some embodiments, object marketplace 615 enables the trading of objects (e.g., as add-on applications, templates, and element types) between object vendors and site designer 608B via WBS 610. In some embodiments, WBS editor 630 enables site designer 608B to edit site pages (e.g., manually or automatically generated), including editing content, logic, layout, attributes, etc. For example, in some embodiments, WBS editor 630 enables site designer 608B to tailor specific templates and their elements according to their business or industry.

[0189] In some embodiments, the site generation system 640 creates the actual site based on the integration and analysis of pre-specified information entered by the site designer 608B (e.g., via a questionnaire) and stored in the CMS (content management system) 700, along with information from external systems 670 and internal information maintained in the CMS 700, which may be gathered from use of the WBS 610 by other designers. Additionally or alternatively, the CMS 700 is maintained in centralized storage or locally by the site designer 608B. An exemplary repository for the CMS 700 is described below with respect to FIG. 7.

[0190] Referring to FIG. 7 , an exemplary CMS 700 is shown. WBS 610 may utilize a CMS 700 that includes a series of repositories stored across one or more servers or server farms to support the creation of various websites. For example, CMS 700 may include one or more of a user information / profile repository 712, a WBS component repository 716, a WBS site repository 709, a business intelligence (BI) repository 710, and an edit history repository 711. Additionally or alternatively, CMS 700 may include one or more of a survey type repository 701, a content element type repository 702, a layout element (LE) type repository 703, a design kit repository 704, a completed survey repository 705, a content element (CER) repository 706, a layout element (LER) repository 707, a layout selection store 708, a rules repository 713, a family / industry repository 714, and an ML / AI (machine learning / artificial intelligence) repository 715. The CMS 700 may also include a CMS coordinator 717 for coordinating and controlling access to one or more such repositories.

[0191] In accordance with the present disclosure, WBS 610 can be used to create and / or update hierarchical websites based on visual editing or automated generation based on collected business knowledge, which may be collected, for example, from external systems 670 or other sources. The term "collection of relevant content for a website being created" is intended to refer to a collection of relevant content for a website being created that may be used for website creation. Further details regarding collected business knowledge are described in commonly owned U.S. Patent No. 10,073,923, entitled "SYSTEM AND METHOD FOR THE CREATION AND UPDATE OF HIERARCHICAL WEBSITES BASED ON COLLECTED BUSINESS KNOWLEDGE," filed May 29, 2017 as U.S. Patent Application No. 15 / 607,586, which is incorporated herein by reference in its entirety.

[0192] In some embodiments, WBS 610 uses an internal data architecture to store WBS-based sites. For example, this architecture may organize the site's internal data and elements within WBS 610 as they are processed. This architecture may differ from the site's external view (e.g., what an end user sees) and may also differ from the way the corresponding HTML pages sent to a browser are organized. In some embodiments, the internal data architecture includes additional properties for each element within a page (e.g., author, creation time, access permissions, links to templates, SEO-related information, etc.) that are related to the editing and maintenance of WBS 610's sites but are not externally visible to end users (or even to some editing users). The internal version of the site may be stored in a site repository, as described in more detail below.

[0193] In some embodiments, the WBS 610 is used with an application. A visual application is a website that includes pages, containers, and components. Each page is displayed separately and includes one or more components. In some embodiments, the components include containers and atomic components. In some embodiments, the WBS 610 supports hierarchical arrangement of components using various types of container components (e.g., regular containers, single-page containers, multi-page containers, gallery containers, etc.) that contain atomic components (e.g., text, images, shapes, videos, etc.) and other components. Subpages contained within a container component are called minipages, each of which may include multiple components. Some container components may display only one of the minipages at a time, while other container components may display multiple minipages simultaneously.

[0194] In some examples, a page may use a template (general page template or component template). In an exemplary embodiment, an application master page containing components replicated on all other regular pages is a template. In another exemplary embodiment, an application header / footer that is repeated on every page is a template. In some embodiments, a template may be used for a complete page or page section. WBS 610 may provide inheritance between templates, pages, or components, possibly including multi-level inheritance, multiple inheritance, and diamond inheritance (i.e., A inherits from B and C, and both B and C inherit from D). In some embodiments, WBS 610 supports site templates.

[0195] In some embodiments, the visual arrangement of components within a page is a layout. In some embodiments, WBS 610 supports dynamic layout processing, whereby editing (or other changes affecting, e.g., externally driven content changes) of a given component may affect other components. Further details regarding dynamic layout processing can be found in U.S. Patent Application No. 13 / 771,119, filed February 20, 2013, entitled "WEB SITE DESIGN SYSTEM INTEGRATING DYNAMIC LAYOUT AND DYNAMIC CONTENT." No. 10,185,703, which is incorporated herein by reference in its entirety.

[0196] In some embodiments, WBS 610 is extended using add-on applications, such as third-party applications and components, list applications, and WBS configurable applications. In particular embodiments, such add-on applications may be added and integrated into the designed website. Such add-on applications may be purchased (or otherwise obtained) through several distribution mechanisms, such as pre-built into the WBS design environment, from an application store (e.g., WBS Object Marketplace 615 or externally integrated), or directly from a third-party vendor. Such third-party applications may be hosted on the WBS vendor's servers, the third-party application vendor's servers, and / or on a fourth-party server infrastructure.

[0197] In some embodiments, WBS610 allows for the addition of procedural code to some or all of its entities (e.g., applications, pages, elements, components, etc.). Such code can be written in a standard language (e.g., JS), an extended version of a standard language, or a language proprietary to a particular WBS610. The code that is executed may reference APIs provided by the WBS610 itself or by external providers. The code may also reference internal structures and objects of the WBS610, such as pages, components, and their attributes.

[0198] In some embodiments, procedural code elements may be activated via event triggers, which may be related to user activity (e.g., a mouse movement or click, a page transition, etc.), other user-related activity (e.g., the underlying database or a particular database record being updated by another user), a system event, or other types of conditions. The activated code may execute within a client element of the WBS (e.g., client device 508), a server platform, a combination of the two, or a dynamically determined execution platform. Further details regarding activation of customized back-end functionality are described in commonly owned U.S. Patent No. 10,209,966, entitled "CUSTOM BACK-END FUNCTIONALITY IN AN ONLINE WEBSITE BUILDING ENVIRONMENT," filed July 24, 2018 as U.S. Patent Application No. 16 / 044,461, which is incorporated herein by reference in its entirety.

[0199] 8 illustrates a block diagram of an example device that may be specially configured in accordance with an example embodiment of the present disclosure. In some embodiments, the hybrid website interface rendering system 510 and / or the hybrid website interface rendering server 512 are embodied by one or more computing systems, such as the server device 800 shown and described in FIG.

[0200] 8 illustrates a schematic block diagram of exemplary modules or circuits, some or all of which may be included in a server device 800. As shown in FIG. 8 , according to some exemplary embodiments, the server device 800 may include various means, such as a memory 802, a processor 804, an input / output module 806, a communications module 808, a hybrid website interface rendering module 810, and / or a code splitting module 812. The server device 800 may be configured to use one or more of the modules 802-812 to perform operations related to implementing hybrid website interface rendering and / or reliable code splitting as described herein. In other words, The systems, methods, apparatus, and / or computer program products described herein are configured to convert or otherwise manipulate a general-purpose computer so that the general-purpose computer functions as a specialized computer for providing the hybrid website interface rendering and / or reliable code splitting described herein.

[0201] While the use of the terms “module” and “circuit” as used herein with respect to components 802-812 is in some cases described using functional language, it should be understood that a particular implementation necessarily involves the use of specific hardware configured to perform the functionality associated with each module or circuit described herein. It should also be understood that some of these components 802-812 may include similar or common hardware. For example, two or more modules may both utilize the use of the same processor, network interface, storage medium, etc. to perform their associated functionality, such that duplicate hardware is not required for each module. In this regard, it will be understood that, for example, some of the components or modules described in connection with hybrid website interface rendering server 512 may be housed within this device, while other components or modules are housed within another of these devices or by yet another device not explicitly shown in FIG. 5 . In other words, in some embodiments, one or more external systems (e.g., remote cloud computing and / or data storage systems) may be utilized to provide at least some of the functionality described herein.

[0202] While the terms "module" and "circuit" should be broadly understood to include hardware, in some embodiments, the terms "module" and "circuit" also include software for configuring hardware. That is, in some embodiments, each of modules 802-812 may be embodied in hardware, software, or a combination thereof for performing the operations described herein. In some embodiments, some of modules 802-812 may be embodied entirely in hardware or entirely in software, while other modules are embodied in a combination of hardware and software. For example, in some embodiments, the terms "module" and "circuit" may include processing circuitry, storage media, network interfaces, input / output devices, etc.

[0203] Additionally or alternatively, in some embodiments, one or more of modules 802-812 may be combined such that a single module includes means configured to perform the operations of two or more of modules 802-812. In other words, other elements of server device 800 may provide or supplement the functionality of a particular module or circuit. For example, processor 804 may provide processing functionality, memory 802 may provide storage functionality, communications module 808 may provide network interface functionality, etc., to another module or circuit. Additionally or alternatively, one or more of modules 802-812 may be embodied by two or more sub-modules.

[0204] In some embodiments, the processor 804 (and / or a coprocessor, or any other processing circuitry assisting or otherwise associated with the processor) may communicate with the memory 802 via a bus, for example, to pass information between components of the hybrid website interface rendering server 512. The memory 802 may be non-transitory and may include one or more volatile and / or non-volatile memories, or some combination thereof. In other words, the memory 802 may be an electronic storage device (e.g., a non-transitory computer-readable storage medium). The memory 802 may be used by the server device 800 (e.g., the hybrid website interface rendering server 512). 512) may be configured to store information, data, content, applications, instructions, etc. to enable it to perform various functions according to exemplary embodiments of the present disclosure.

[0205] Although depicted as a single memory in FIG. 8 , memory 802 may include multiple memory components. The multiple memory components may be embodied on a single computing device or distributed across multiple computing devices. In various embodiments, memory 802 may include, for example, a hard disk, random access memory, cache memory, flash memory, a compact disc read-only memory (CD-ROM), a digital versatile disc read-only memory (DVD-ROM), an optical disk, a circuit configured to store information, or some combination thereof. Memory 802 may be configured to store information, data, applications, instructions, etc. to enable server device 800 to perform various functions in accordance with example embodiments described herein. For example, in at least some embodiments, memory 802 is configured to buffer data for processing by processor 804. Additionally or alternatively, in at least some embodiments, memory 802 is configured to store program instructions for execution by processor 804. Memory 802 may store information in the form of static and / or dynamic information. This stored information may be stored and / or used by server device 800 (eg, hybrid website interface rendering server 512) in the course of performing its functions.

[0206] Processor 804 may be embodied in several different ways, for example, it may include one or more processing devices configured to perform independently. Additionally or alternatively, processor 804 may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining, and / or multithreading. Processor 804 may be embodied in a variety of ways, including, for example, one or more microprocessors with associated digital signal processors, one or more processors without associated digital signal processors, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuitry, one or more computers, various other processing elements including integrated circuits such as ASICs (application-specific integrated circuits) or FPGAs (field-programmable gate arrays), or any combination thereof. Use of the term “processing circuitry” may be understood to include a single-core processor, a multi-core processor, multiple processors internal to a device, and / or a remote or “cloud” processor. Thus, while shown as a single processor in FIG. 8, in some embodiments, processor 804 includes multiple processors. The multiple processors may be embodied on a single computing device or may be distributed across multiple such devices collectively configured to function as hybrid website interface rendering server 512. The multiple processors may be in operative communication with each other and collectively configured to perform one or more functions of hybrid website interface rendering server 512 as described herein.

[0207] In an exemplary embodiment, processor 804 is configured to execute instructions stored in memory 802 or otherwise accessible to processor 804. Alternatively or additionally, processor 804 may be configured to perform hard-coded functions. Thus, whether configured by hardware or software methods, or a combination thereof, processor 804 may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment of the present disclosure while configured accordingly. Alternatively, another By way of example, if the processor 804 is embodied as an execution unit of software instructions, the instructions, when executed, may specifically configure the processor 804 to perform one or more algorithms and / or operations described herein. For example, the instructions, when executed by the processor 804, may cause the server device 800 (e.g., the hybrid website interface rendering server 512) to perform one or more of the functions of the system 500 described herein.

[0208] In some embodiments, server apparatus 800 further includes an input / output module 806 that may communicate with processor 804 to provide audible, visual, mechanical, or other output, and / or in some embodiments, to receive input indications from a user, client device 508, or another source. In this regard, input / output module 806 may include means for performing analog-to-digital and / or digital-to-analog data conversion. Input / output module 806 may include support for, for example, a display, a touchscreen, a keyboard, buttons, a click wheel, a mouse, a joystick, an image capture device (e.g., a camera), a motion sensor (e.g., an accelerometer and / or gyroscope), a microphone, an audio recorder, a speaker, a biometric scanner, and / or other input / output mechanisms. Input / output module 806 may include a user interface, and may also include a web user interface, a mobile application, a client device, a kiosk, etc. Processor 804 and / or user interface circuitry including processor 804 may be configured to control one or more functions of a display or one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored in memory accessible to processor 804 (e.g., memory 802, etc.). In some embodiments, aspects of input / output module 806 may be reduced compared to embodiments in which server device 800 may be implemented as an end-user machine or other type of device designed for complex user interaction. In some embodiments (as well as other components described herein), input / output module 806 may even be eliminated from server device 800. Input / output module 806 may communicate with memory 802, communications module 808, and / or any other components via a bus or the like.Multiple input / output modules 806 and / or other components may be included in server device 800, although only one is shown in FIG. 8 to avoid overcomplicating the disclosure (e.g., as well as other components described herein).

[0209] Communications module 808, in some embodiments, includes any means, such as a device or circuit embodied in either hardware, software, firmware, or a combination of hardware, software, and / or firmware, configured to receive and / or transmit data to and from a network and / or any other device, circuit, or module in communication with server device 800. In this regard, communications module 808 may include, for example, a network interface for enabling communication with a wired or wireless communication network. In some embodiments, communications module 808 is configured to receive and / or transmit any data that may be stored by memory 802 using any protocol that may be used for communication between computing devices. For example, communications module 808 may include one or more network interface cards, antennas, transmitters, receivers, buses, switches, routers, modems, and supporting hardware and / or software, and / or firmware / software, or any other devices suitable for enabling communication over a network. Additionally or alternatively, in some embodiments, communications module 808 includes circuitry for interacting with an antenna to cause the transmission of signals via the antenna or process the reception of signals received via the antenna. These signals may be transmitted over a wireless network, such as Bluetooth (registered trademark) The signals may be transmitted by the hybrid website interface rendering server 512 using any of several wireless personal area network (PAN) technologies, such as Bluetooth Low Energy (BLE), Bluetooth (e.g., IrDA), Ultra Wide Band (UWB), inductive radio transmission, etc. It should further be understood that these signals may be transmitted using Wi-Fi, Near Field Communication (NFC), Worldwide Interoperability for Microwave Access (WiMAX), or other proximity-based communication protocols. The communications module 808 may additionally or alternatively communicate with the memory 802, the input / output module 806, and / or any other components of the server device 800, such as via a bus.

[0210] In some embodiments, hybrid website interface rendering module 810 is included in server device 800 and is configured to perform, among other things, the functionality described herein related to enabling the rendering of a hybrid website interface. In some embodiments, hybrid website interface rendering module 810 includes hardware, software, firmware, and / or a combination of such components configured to support various aspects of such hybrid website interface rendering-related functions, features, and / or services of hybrid website interface rendering module 810 described herein (e.g., providing a primary execution environment, providing one or more sandbox execution environments, providing one or more proxy translation components, causing the rendering of a hybrid website interface, etc.).

[0211] In some embodiments, the hybrid website interface rendering module 810 provides a compilation function (e.g., J compiler 400) as described in the data flow diagram shown in Figure 4A. In some embodiments, the J compiler 400 is configured to extract declarative programming language expressions from presentation code subcomponents of untrusted website code components, compile the extracted declarative programming language expressions to form secure code components or secure functions that execute in the primary execution environment, and / or form proxy translation components (e.g., from presentation code subcomponents of untrusted website code components).

[0212] In various embodiments, the J compiler 400 reads definitions of trusted website code definition elements (JEs) and untrusted website code components (JCs), such as by reading and / or executing JSX files [1], reading HTML / CSS files [2], and / or reading another definition format. The J compiler 400 then creates a semantic representation of the untrusted website code definition element definitions (Jay JE definitions [4]), which are the first input for secure code generation. In some embodiments, the J compiler 400 extracts declarative programming language (JLang) expressions from the untrusted website code components (JCs [5]) and replaces such declarative programming language (JLang) expressions with one or more identifiers. The extracted declarative programming language (JLang) expressions form the second input for secure code generation. In yet another embodiment, the J compiler 400 compiles extracted declarative programming language (JLang) representations of trusted website code definition elements (JEs) and untrusted website code components (JCs) into secure code that can be executed anywhere (e.g., in a non-secure thread, a secure thread, or other isolated context [6]). The trusted website code definition elements (JEs) are converted into JS functions that, given the defined data, render the specified HTML and, in some cases, provide updates to the data and update the HTML according to the definition. The input for the JS rendering function is denoted as "ViewState" and This is computed by the Untrusted Website Code Component (JC): Declarative programming language (JLang) expressions are translated into event handlers and other functions with native DOM access.

[0213] 4A , the J compiler 400 creates or forms proxy translation components (e.g., a JE bridge, a JE stub, a JC bridge, and a JC stub) for trusted website code definition elements (JEs [7]) and untrusted website code components (JCs [8]), which are used as respective proxies in different contexts. Additionally or alternatively, the J compiler 400 bundles the generated trusted website code definition elements (JEs) and untrusted website code components (JCs) into two bundles: (i) a secure bundle [7] for execution in the primary execution environment [9], which includes proxy translation components (JC bridges) for the securely generated trusted website code definition elements (JEs) and untrusted website code components (JCs), and (ii) a non-secure bundle [8] for execution in the sandbox execution environment

[10] , which includes proxy translation components (JE bridges) for the untrusted website code components (JCs) and trusted website code definition elements (JEs).

[0214] Continuing with the embodiment of FIG. 4A, the J Compiler 400 generates one or more files required for the development environment (and determines the communication protocol) to recognize the signature of the function (e.g., .d.ts files, which are type definition files that enable the use of existing JS code in Typescript for Typescript support

[11] ) into which the trusted website code component (JE) is compiled. For example, using such signature files, the development experience of coding untrusted website code components, JC [3], is given standard support. The generation of signature files (e.g., .d.ts files, etc.) can be separated from the generation of secure bundles [7] and non-secure bundles [8].

[0215] Additionally or alternatively, in some embodiments, the trusted website code definition element allows for the creation of a transformation pipeline managed by the J Compiler, as shown in FIG. 4B, to modify the trusted website code definition element before generating code for it. In some embodiments, such transformations can insert values ​​from a database into the trusted website code definition element, translate text within the trusted website code definition element using a translation system, and / or transform common design patterns (e.g., converting a stack of boxes to a "forEach" dynamic structure). Incorporating a transformation pipeline into the J Compiler, as shown in FIG. 4B, adds step

[12] after reading the untrusted website code definition element (JE) definition [4] and before generating the safe code [6] and d.ts file

[11] . Step

[12] , performed during the compilation process, can execute any type of logic to execute unsafe code and transform the JE definition.

[0216] It should be appreciated that in some embodiments, hybrid website interface rendering module 810 performs one or more of such exemplary actions in combination with other modules of server device 800, such as one or more of memory 802, processor 804, input / output module 806, and communications module 808. For example, in some embodiments, hybrid website interface rendering module 810 utilizes processing circuitry, such as processor 804, to perform one or more of its corresponding operations. In a further example, hybrid website interface rendering module 810 may be configured to perform one or more of the following actions: Some or all of the functionality of the interface rendering module 810 may be performed by the processor 804 in some embodiments. In this regard, some or all of the example hybrid website interface rendering processes and algorithms described herein may be performed by at least one processor 804 and / or the hybrid website interface rendering module 810. It should also be understood that in some embodiments, the hybrid website interface rendering module 810 may include a separate processor, a specially configured field programmable gate array (FPGA), or an application specific integrated circuit (ASIC) to perform its corresponding functionality.

[0217] Additionally or alternatively, in some embodiments, hybrid website interface rendering module 810 utilizes memory 802 to store collected information. For example, in some implementations, hybrid website interface rendering module 810 includes hardware, software, firmware, and / or combinations thereof that interact with hybrid website interface rendering repository 514 (shown in FIG. 5 ) and / or memory 802 to transmit, retrieve, update, and / or store data values ​​embodied by, associated with, configured to be associated with, and / or otherwise support the operation of hybrid website interface rendering module 810 and the remaining circuitry. Additionally or alternatively, in some embodiments, hybrid website interface rendering module 810 utilizes input / output module 806 to facilitate user output and / or receive user input (e.g., user clicks, user taps, keyboard interactions, user gestures, etc.). Additionally or alternatively, in some embodiments, the hybrid website interface rendering module 810 utilizes the communications module 808 to initiate transmissions to another computing device, receive transmissions from another computing device, communicate signals between various modules as shown, and the like.

[0218] In some embodiments, code splitting module 812 is included in server device 800 and is configured to, among other things, perform the functionality described herein related to trusted code splitting. In some embodiments, code splitting module 812 includes hardware, software, firmware, and / or a combination of such components configured to support various aspects of such code splitting-related functions, features, and / or services of code splitting module 812 described herein (e.g., applying a trusted code identification model, identifying trusted code sections, identifying untrusted code sections, extracting trusted code sections, generating intercommunication paths, etc.). As shown in FIG. 8 , code splitting module 812 may be included in server device 800; however, it is contemplated by the present disclosure that code splitting module 812 may be included in server device 800, one or more separate server devices 800, and / or a collection of servers (e.g., a cloud networking environment, a microservice, etc.).

[0219] 9 illustrates a block diagram of an exemplary client device that may be specially configured in accordance with exemplary embodiments of the present disclosure. In some embodiments, client devices 508A-508B are embodied by one or more computing systems, such as client device 900 shown and described in FIG. 9. Client device 900 includes memory 902, processor 904, input / output module 906, communication module 908, hybrid website interface rendering module 910, and / or code splitting module 912. That is, in some embodiments, hybrid website interface rendering module 910 and / or code splitting module 912 are optionally configured to operate on client device 900 (e.g., client device 508). The client device 900 may include, among other things, a hybrid website interface rendering module 910 and / or a code splitting module 912 and may be configured to perform some or all of the functionality described herein relating to the hybrid website interface rendering module 910 and / or the code splitting module 912. The client device 900 may be configured using one or more of the sets of circuits to perform the operations described herein. The modules 902-912 may function similarly or identically to the similarly named modules shown and described with respect to the server device 800. For the sake of brevity and length of disclosure, repeated disclosure of the functionality of such similarly named sets of circuits will be omitted herein.

[0220] definition The term "hybrid website interface rendering system" refers to a software platform and associated hardware configured to support, maintain, and manage the rendering of a hybrid website interface (e.g., web pages, graphical user interfaces, online documents, etc.) and all associated functionality, including, for example, providing a primary execution environment, providing one or more sandbox execution environments, providing one or more proxy translation components, and compiling trusted website code definition elements, untrusted website code components, and such proxy translation components. An exemplary hybrid website interface rendering system includes a supporting server, a repository, and client devices, and in some embodiments is further configured to interface with external resources and external applications. In some embodiments, the hybrid website interface rendering system is a standalone system. In other embodiments, the hybrid website interface rendering system is embedded within a larger editing system. In certain embodiments, the hybrid website interface rendering system is associated with a visual design system, and further, in some embodiments, the visual design system is one or more of a document building system, a website building system, or a software application building system.

[0221] The term "hybrid website interface rendering server" refers to a software platform and associated hardware configured to manage some or all of the various code structures, components, and associated hybrid website interface rendering functionality of a hybrid website interface rendering system. The hybrid website interface rendering server is accessible via one or more computing devices and configured to receive various data and access one or more data repositories, such as a hybrid website interface rendering repository. The functionality of the hybrid website interface rendering server may be provided via a single server or a collection of servers having common functionality, or the functionality of the hybrid website interface rendering server may be segmented among multiple servers, a collection of servers (e.g., a cloud networking environment, microservices, etc.), and / or multiple clients that perform a subset of the described functionality of the hybrid website interface rendering.

[0222] The term "hybrid website interface" refers to a graphical user interface that is rendered as a result of execution of source code in one or more primary execution environments and one or more sandbox execution environments. The hybrid user interface is rendered on a client device based on data and instructions provided by a hybrid website interface rendering system. In some embodiments, such data and instructions are executed on the client device. In other embodiments, such data and instructions are provided via a web browser running on the client device.

[0223] The term "primary execution environment" refers to an insecure (i.e., not isolated from other environments or systems) or trusted environment, such as a web window, in which code, such as JavaScript (JS), can be executed. The primary execution environment is configured to execute one or more trusted website code-defined elements, trusted code sections, and / or trusted computer-executable functions (e.g., based on trusted code sections).

[0224] The term "sandbox execution environment" refers to a secure environment (i.e., architecturally isolated from other environments or systems) in which code, such as JS, can be executed. A sandbox execution environment is an isolation mechanism or environment for securely executing potentially untrusted code. A sandbox execution environment is configured to execute one or more untrusted website code components, untrusted code sections, and / or untrusted computer-executable functions (e.g., based on untrusted code sections).

[0225] The term "trusted website code definition element" refers to an element or code construct that is considered inherently safe or trustworthy. In some embodiments, a trusted website code definition element utilizes a declarative programming language that is inherently secure and / or can be transformed / compiled into code that can be verified as secure via static analysis. A trusted website code definition element may not contain logic code or logic code subcomponents, but may contain sections that contain instructions that are later compiled into logic instructions. A trusted website code definition element defines state structures and functions that can accept data and, when called, create and / or update one or more structures within the DOM of the hybrid website interface (e.g., return an update function). JE

[31] is an example of a trusted website code definition element shown in FIG. 3B. In some embodiments, a trusted website code definition element is a trusted code section.

[0226] The term "trusted code section" refers to code or code constructs that are deemed inherently safe or secure such that they can be trusted to execute in a primary execution environment. In some embodiments, the trusted code section utilizes a declarative programming language that is inherently secure and / or that can be transformed / compiled into code that can be verified as secure via static analysis. In some embodiments, the trusted code section may conform to one or more rules and / or patterns used to identify trusted code sections. For example, trusted code sections may be identified based on known variable names, variable types, syntactic structures, API names, API types, security policies, access parameters, etc. Trusted code sections may be identified and / or extracted from within an untrusted candidate code corpus. Trusted code sections may be compiled for execution in a primary execution environment. For example, trusted code sections may be identified by applying a trusted code identification model to an untrusted candidate code corpus. The identified trusted code sections may be extracted from the untrusted candidate code corpus, or one or more trusted computer-executable functions may be generated based on the extracted trusted code sections.

[0227] The term "trusted computer-executable function" refers to one or more trusted code Trusted computer-executable functions refer to computer-executable functions that are generated and / or compiled based on sections. Trusted computer-executable functions may be generated in compliance with one or more predetermined rules. For example, trusted computer-executable functions may be generated so that they are unmodifiable by users, signed (including via hashing, cryptography, and / or blockchain), unseen by users, readable, generated using Typescript, less than a given number of characters or lines, condition-free, etc. Trusted computer-executable functions may be executed in a primary execution environment. Trusted computer-executable functions may be communicatively connected to one or more other computer-executable functions, such as untrusted computer-executable functions. For example, an output of a trusted computer-executable function may serve as input to another computer-executable function, such as an untrusted computer-executable function. In another example, a trusted computer-executable function may receive as input an output from another computer-executable function, such as an untrusted computer-executable function. In some embodiments, an intercommunication path is established between a trusted computer-executable function and an untrusted computer-executable function based on the underlying untrusted code section from which it was extracted.

[0228] The term "untrusted website code component" refers to a component or code structure that is considered potentially or inherently unsafe and may not be trusted to run in the primary execution environment. An untrusted website code component may be a third-party application or code (e.g., a code structure generated outside the system), or may be generated internally but insufficiently tested. An untrusted website code component uses a scripting programming language or other insecure code to create its associated trusted website code definition element to be rendered. An untrusted website code component may be a structure that, when triggered, communicates or sends new data to its associated trusted website definition element using an API. An untrusted website code component may define event handlers for its associated trusted website definition element. An untrusted website code component may use Refs as a way to access the DOM. That is, an untrusted website code component may set event listeners on the corresponding trusted website code definition element to retrieve events, provide updates, and then return the view state to the trusted website code definition element that updates the DOM. An untrusted website code component may retrieve props from its parent untrusted website code component and expose APIs and events. JC

[32] is an example of an untrusted website code component shown in Figure 3B.

[0229] The term "untrusted code section" refers to code or code constructs that are not considered inherently safe or secure and may not be trusted to run in a primary execution environment. In some embodiments, an untrusted code section utilizes a scripting programming language or other insecure code. In some embodiments, an untrusted code section may not conform to any one of one or more rules and / or patterns used to identify trusted code sections. An untrusted code section may, for example, contain unusual or unknown variable names, variable types, syntactic structures, API names, API types, or require access to restricted entities. An untrusted code section may be a code section that has not been identified as a trusted code section from within the untrusted candidate code corpus. An untrusted code section may be compiled for execution in a sandbox execution environment. For example, a trusted code section may be a code section that has not been identified as a trusted code section from within the untrusted candidate code corpus. The remaining code sections not identified as trusted code sections may be considered untrusted code sections by default. One or more untrusted computer-executable functions may be generated and / or compiled based on the untrusted code sections.

[0230] In some embodiments, untrusted code may fail to compile or execute properly. For example, the untrusted code may use APIs that are not available in the sandbox execution environment. However, because the untrusted code has not been identified as trusted code, untrusted computer-executable functions based on the untrusted code may remain in the sandbox environment where the required APIs are not available, and as a result, the untrusted code may fail to compile, function properly, execute at runtime, etc.

[0231] The term "untrusted computer-executable function" refers to a computer-executable function based on one or more untrusted code sections. One or more untrusted computer-executable functions may be generated, and each untrusted computer-executable function may be based on one or more untrusted code sections. The untrusted computer-executable function may be generated in accordance with one or more predetermined rules. For example, in some embodiments, the untrusted computer-executable function may be generated so that it is unmodifiable by a user, signed (including via hashing, cryptography, and / or blockchain), unseen by a user, readable, generated using Typescript, less than a given number of characters or lines, condition-free, etc. The untrusted computer-executable function may be executed in a sandbox execution environment. The untrusted computer-executable function may be communicatively connected to one or more other computer-executable functions, such as trusted computer-executable functions. For example, the output of the untrusted computer-executable function may serve as input to another computer-executable function, such as a trusted computer-executable function. In another example, the untrusted computer-executable function may receive as input an output from another computer-executable function, such as a trusted computer-executable function. In some embodiments, an intercommunication path is established between a trusted computer-executable function and an untrusted computer-executable function based on the underlying untrusted code section from which it was extracted.

[0232] The term "untrusted candidate code corpus" refers to a corpus of code that may include untrusted code sections, trusted code sections, or a combination thereof. In some embodiments, code received by the hybrid website interface server may be included or defined within the untrusted candidate code corpus by default. That is, in some embodiments, the code may be initially treated as untrusted code in the untrusted candidate code corpus by default, and static analysis may be applied to potentially identify one or more trusted code sections. When a compiler analyzes the untrusted candidate code corpus, one or more sections of code in the untrusted candidate code corpus may be identified as trusted code sections. In other words, some code sections in the untrusted candidate code corpus may be identified as trusted code sections by applying a trusted code identification model, while code sections that are not positively identified as trusted code sections are untrusted code sections. Additionally or alternatively, in some embodiments, one or more sections of code in the untrusted candidate code corpus may be positively identified as untrusted code sections. For example, a compiler applying a trusted code identification model may identify code in the untrusted candidate code corpus as untrusted code sections.

[0233] The term "proxy translation component" refers to a component configured to communicatively link untrusted website code components executing in a sandbox execution environment to trusted website code definition elements executing in a primary execution environment, where the proxy translation component represents or emulates trusted website code definition elements or untrusted website code components in the opposite execution environment. The proxy translation component is generated by a J compiler. Exemplary embodiments of the present disclosure illustrate the proxy translation component as one of two types: bridge type or stub type. A bridge type proxy translation component acts as a proxy to trusted website code definition elements or untrusted website code components that have both parent and child nodes. A stub type proxy translation component acts as a proxy to trusted website code definition elements or untrusted website code components that have parent nodes but no child nodes. It is contemplated by the present disclosure that the proxy translation component may be of other types, and the present disclosure is not limited to the specifically identified bridge type and stub type of proxy translation component.

[0234] A "primary execution environment proxy translation component" refers to a proxy translation component that runs in a primary execution environment and maintains the rendering order location of corresponding untrusted website code components running in a sandbox execution environment. The JC Bridge

[22] is an example of a primary execution environment proxy translation component, as shown in Figure 3B.

[0235] A "sandbox execution environment proxy translation component" refers to a proxy translation component that runs in a sandbox execution environment and maintains the rendering order location of the corresponding trusted website code definition elements running in the primary execution environment. JE Bridge

[12] and JE Stub 15 are two examples of sandbox execution environment proxy translation components shown in Figure 3B.

[0236] The term "trusted entity" refers to an entity in the code supply chain between a code synthesis entity and a code consuming entity that processes the code-based content. The trusted entity receives the code-based content from the code synthesis entity. In some embodiments, the code synthesis entity may or may not perform trusted code splitting on the code-based content before providing the code-based content to the trusted entity, such that trusted code is compiled to run in a primary execution environment and / or untrusted code is compiled to run in a sandbox execution environment. Additionally or alternatively, the trusted entity may perform trusted code splitting on the code-based content, such that one or more trusted code sections are compiled to run in a primary execution environment and / or one or more untrusted code sections are compiled to run in a sandbox execution environment. Additionally or alternatively, the trusted entity may generate an executable code package based on the trusted and / or untrusted code sections. In some embodiments, the trusted entity may send the executable code package to the code consuming entity. In some embodiments, the trusted entity may execute the executable code package and send data indicative of the results of the execution to the code consuming entity.

[0237] The trusted entity may validate the received code-based content. Validating the code-based content may include any procedure used by the trusted entity to validate the code-based content. For example, A trusted entity may block, reject, or approve code-based content entirely or by subsection, pending any verification based on any agreement, regulation, etc. A trusted entity may perform verification before and / or after applying trusted code-splitting operations to code-based content.

[0238] The term "code synthesis entity" refers to an entity that generates code-based content. For example, a code synthesis entity may be an individual or group that writes, generates, produces, sells, etc., code-based content. A code synthesis entity may provide code for consumption directly or indirectly. For example, a code synthesis entity may provide code-based content to a code-consuming entity directly and / or indirectly through a trusted entity.

[0239] The term "code consuming entity" refers to an entity that receives code-based content. For example, the code consuming entity may be an individual or group that downloads, purchases, receives, views, etc. the code-based content. The code consuming entity may consume code directly or indirectly from the code synthesis entity. For example, the code consuming entity may consume code-based content directly from the code synthesis entity and / or indirectly by a trusted entity. In some embodiments, the code consuming entity may receive code-based content from the synthesis entity and / or the trusted entity, enabling local execution of the code-based content by the code consuming entity. In some embodiments, the code consuming entity may receive data from the code synthesis entity and / or the trusted entity indicating the executed code-based content. For example, the code consuming entity may consume trusted code from the trusted entity and untrusted code from the code synthesis entity and / or a fourth party. In another example, the code consuming entity may consume trusted code and untrusted code from the trusted entity. In either case, the code consuming entity may receive the code-based content for local execution or data indicating execution of the code-based content by another entity.

[0240] The term "provider-defined trusted code" refers to a section of trusted code that is defined, at least in part, by a provider. In some embodiments, one or more entities are associated with a hybrid website interface rendering system. Providers may have different APIs, use cases, functionality, security policies, etc., that result in at least partially different definitions of what may be identified as trusted code. Such differences may be reflected by the provider-defined trusted code. For example, a provider of a hybrid website interface rendering system may provide one or more rules, code patterns, etc. that are applied, at least in part, by a compiler or trusted code identification model to identify trusted code.

[0241] The term "vendor-defined trusted code" refers to a section of trusted code that is defined, at least in part, by the vendor. In some embodiments, one or more entities are associated with a hybrid website interface rendering system. Vendors may have different APIs, use cases, features, security policies, etc. that result in at least partially different definitions of what may be identified as trusted code. Such differences may be reflected by the vendor-defined trusted code. For example, a vendor of a hybrid website interface rendering system may use a compiler or trusted code identifier to identify trusted code. Another model may provide one or more rules, code patterns, etc. that are at least partially enforced by the model.

[0242] The term "third-party-defined trusted code" refers to a section of trusted code that is defined, at least in part, by a third party. In some embodiments, one or more entities are associated with the hybrid website interface rendering system. The third parties may have different APIs, use cases, functionality, security policies, etc., that result in at least partially different definitions of what may be identified as trusted code. Such differences may be reflected by the third-party-defined trusted code. For example, a third party of the hybrid website interface rendering system may provide one or more rules, code patterns, etc. that are applied, at least in part, by a compiler or trusted code identification model to identify trusted code.

[0243] The term "rendering order" refers to the object invocation structure in which trusted and / or untrusted website code definition elements are invoked or rendered to implement the rendering of a hybrid website interface.

[0244] The term "trained machine learning model" refers to a machine learning task. Machine learning is a method used to devise complex models and algorithms useful for prediction. Machine learning models are computer-implemented algorithms that can learn from data with or without relying on rule-based programming. These models enable reliable, repeatable decisions and outcomes, as well as the discovery of hidden insights, through machine-based learning from past relationships and trends in data.

[0245] A machine learning model is first fitted or trained to a training dataset (e.g., a set of examples used to fit the model's parameters). The model can be trained on the training dataset using supervised or unsupervised learning. The model is run using the training dataset to generate results, which are then compared to a target for each input vector in the training dataset. In certain embodiments, the machine learning model is trained in real time (e.g., on-the-fly training). Based on the results of the comparison and the particular learning algorithm being used, the model's parameters are adjusted. Model fitting can include both variable selection and parameter estimation. The fitted model is then used to predict responses to observations in a second dataset, called a validation dataset. The validation dataset provides an unbiased evaluation of the model fitting to the training dataset while adjusting the model's hyperparameters (e.g., the number of hidden units in a neural network).

[0246] The term "trusted code identification model" refers to a data entity configured to analyze an untrusted candidate code corpus and automatically and selectively identify trusted code sections. The trusted code identification model may, for example, use one or more code analysis factors to make suggestions or predictions regarding trusted code sections. The trusted code identification model may apply one or more defined rules and / or match one or more defined code patterns to identify sections of code in the untrusted candidate code corpus as trusted code sections. Additionally or alternatively, the trusted code identification model may be a machine learning model trained using tracking data, historical data, etc. For example, in some embodiments, unsupervised learning structures, supervised learning structures, reinforcement learning structures, deep learning structures, clustering algorithms, etc., use various data and data sets to make suggestions or predictions regarding trusted code. In some further embodiments, the reliable code identification model may be an AI-based model or a non-AI-based model.

[0247] The term “compilation performance metrics” refers to data entities that describe the compilation and / or execution of code. Compilation performance metrics may include, for example, static and / or dynamic values, value ranges, percentages, speeds, etc. In some embodiments, compilation performance metrics may be used to report code that fails to compile, function properly, execute at runtime, etc. For example, untrusted code that requires APIs that are not available in the respective sandbox execution environment may fail to compile, function properly, execute at runtime, etc. One or more such instances may be recorded as compilation performance metrics. The compilation performance metrics may be provided to a user, for example, so that the user may be aware of one or more instances. In another example, the compilation performance metrics may be provided to an entity, such as Copilot, configured to assist with code-based activity. The compilation performance metrics may include or be associated with one or more indexes, variable names, variable types, functions, etc., so that the user may target the respective code.

[0248] The term "code-based content" refers to any code that can be configured to make some information available. For example, code-based content may be a web page, web page section, template, third-party application, plug-in, add-on, package, component, portion thereof, etc. that is used to render a website, application or portion thereof, perform data manipulation, automate tasks, develop software, etc. Code-based content may or may not be divided into trusted and untrusted code sections.

[0249] The term "executable code package" refers to consumable code-based content. In some embodiments, the executable code package is generated by a trusted entity and / or a code synthesis entity. The executable code package may be based on code-based content generated by and / or received from the code synthesis entity. The executable code package may include trusted and / or untrusted code sections identified and compiled based on the received code-based content. The trusted code sections in the executable code package may be configured to execute in a primary execution environment, and the untrusted code sections may be configured to execute in a sandbox execution environment. In some embodiments, the executable code package may be transmitted to a code consuming entity, thereby enabling the code consuming entity to execute the executable code package. Additionally or alternatively, in some embodiments, one or more portions of the executable code package are executed by the trusted entity and / or the code synthesis entity, and data indicative of the results of the execution is transmitted to the code consuming entity.

[0250] The term "candidate secure distribution" refers to code-based content from a code synthesis entity. For example, the code synthesis entity may apply a trusted code identification model to the code-based content to identify one or more trusted code sections and / or one or more untrusted code sections to generate a candidate secure distribution of the code-based content. The candidate secure distribution may include trusted code sections compiled to execute in a primary execution environment and / or untrusted code sections compiled to execute in a sandbox execution environment. In some embodiments, The code synthesis entity may provide a candidate secure distribution of the code-based content to the trusted entity. The code synthesis entity may provide a candidate secure distribution of the code-based content to the trusted entity for purposes of the code consuming entity, which will receive the code-based content after processing by the trusted entity. The term "website building block" refers to structural objects used to assemble a website in accordance with the website construction system described herein. By way of example, website building blocks may include pages, sub-pages, containers, components, atomic components, content elements, layout elements, templates, layouts, layout rules, add-on applications, third-party applications, procedural code, etc.

[0251] The term "compiler" refers to a computer program configured to create an executable computer program. In various embodiments, a compiler may be configured to translate computer code from one programming language to another, identify one or more sections of trusted code, make one or more code-based decisions, generate and / or manipulate one or more code sections, etc. In some embodiments, a compiler, as used herein, may be a preprocessor, a J-compiler, a JIT compiler, a static or dynamic code analyzer, an interpreter, a virtual machine (e.g., applying a trusted code identification model), or any other compilation, code processing, transformation, modification, or generation technique (including generative AI-based techniques).

[0252] The term "code analysis factors" refers to one or more cues or sources of information that a compiler (e.g., a trusted code identification model) uses to make a decision. For example, code analysis factors may include code context, variable names, variable types, function usage, syntactic structure, API names, API types, security policies, code pattern matching, code abstract syntax tree (AST) analysis, declarative code recognition, historical code identification data, domain-specific languages ​​(DSLs), rules, libraries, library types, library names, etc. A compiler may use one or more code analysis factors to, for example, identify sections of trusted code, sections of untrusted code, etc.

[0253] The term "identifier" or "identifiers" refers to unique identifiers, non-unique identifiers, and the like.

[0254] The terms "website editing history interaction," "editing history interaction," and "history editing interaction" refer to electronic interactions performed by a client device related to editing user identifiers while assembling a website in accordance with the website building system described herein. For example, such interactions may include editing content, logic, layout, attributes, etc.

[0255] The term "electronic interaction data" refers to electronic interactions conducted by a client device having an electronic interface (e.g., a hybrid website interface). Electronic interaction data can include interactions with a touch screen, mouse clicks, cursor position, cursor hovering, etc.

[0256] Terms such as "client device," "computing device," and "user device" may be used interchangeably to refer to computer hardware configured to access (physically or by executing software) one or more of the applications, services, or repositories made available by a server, and configured to send and receive data directly or indirectly, among various other functions. The client and server are typically remote from each other because the servers are often (but not always) on different computer systems, where a client device accesses the services through a communications network. The relationship between client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, the server sends information / data (e.g., HTML pages) to the client device (e.g., for the purpose of displaying the information / data to and receiving user input from a user interacting with the client device or an administrative user interacting with the administrative device). Information / data generated at the client device can be received from the client device by the server.

[0257] Exemplary client devices include, but are not limited to, smartphones, tablet computers, laptop computers, wearable devices (e.g., those integrated into wristwatches or smartwatches, eyewear, helmets, hats, clothing, earpieces with wireless connectivity, etc.), personal computers, desktop computers, enterprise computers, etc., and any other computing device known to those of skill in the art in light of this disclosure. In some embodiments, the client device is associated with a user. In some embodiments, the association is created by the client device sending authentication information associated with the user to a hybrid website interface rendering system (e.g., a hybrid website interface rendering server).

[0258] The terms “data,” “content,” “digital content,” “digital content object,” “signal,” “information,” and similar terms may be used interchangeably to refer to data that may be transmitted, received, and / or stored in accordance with embodiments of the present invention. Accordingly, the use of such terms should not be construed to limit the spirit and scope of embodiments of the present invention. Furthermore, when a computing device is described herein as receiving data from another computing device, it will be understood that the data may be received directly from the other computing device or indirectly via one or more intermediate computing devices, such as, for example, one or more servers, relays, routers, network access points, base stations, hosts, etc., which may be referred to herein as a “network.” Similarly, when a computing device is described herein as transmitting data to another computing device, it will be understood that the data may be transmitted directly to the other computing device or indirectly via one or more intermediate computing devices, such as, for example, one or more servers, relays, routers, network access points, base stations, hosts, etc.

[0259] The term "computer-readable storage medium" refers to a non-transitory physical or tangible storage medium (e.g., volatile or non-volatile memory) and may be distinguished from a "computer-readable transmission medium," which refers to an electromagnetic signal. Such media can take many forms, including, but not limited to, non-transitory computer-readable storage media (e.g., non-volatile media, volatile media) and transmission media. Transmission media include carrier waves that travel through space without wires or cables, such as coaxial cables, copper wire, fiber optic cables, and acoustic and electromagnetic waves, including radio, light, infrared, and the like. Signals include artificial or naturally occurring transient variations in amplitude, frequency, phase, polarization, or other physical characteristics that are transmitted over a transmission medium.

[0260] Examples of non-transitory computer-readable media include magnetic computer-readable media (e.g., floppy disks, hard disks, magnetic tapes, any other magnetic media), optical computer-readable media (e.g., compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), Blu-ray disks, etc.), random access memories (RAMs), ), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), FLASH-EPROM, or any other non-transitory medium that can be read by a computer. The term computer-readable storage medium is used herein to refer to any computer-readable medium excluding transmission media. However, when an embodiment is described as using a computer-readable storage medium, it will be understood that in alternative embodiments, other types of computer-readable media may be used in place of, or in addition to, the computer-readable storage medium.

[0261] The terms “application,” “software application,” “app,” “product,” “service,” or similar terms refer to a computer program or group of computer programs designed to perform a coordinated function, task, or activity for the benefit of a user or group of users. A software application may run on a server or group of servers (e.g., physical servers or virtual servers in a cloud-based computing environment). In particular embodiments, an application is designed for use by and interaction with one or more local, network, or remote computing devices, such as, but not limited to, client devices. Non-limiting examples of applications include website editing services, document editing services, word processors, spreadsheet applications, accounting applications, web browsers, email clients, media players, file viewers, collaborative document management services, video games, audio / video conferencing, and photo / video editors.

[0262] In some embodiments, the application is a cloud product. When associated with a client device, such as a mobile device, communication with hardware and software modules executing outside the application is typically provided through application programming interfaces (APIs) provided by the mobile device operating system.

[0263] The term "comprising" means, and should be interpreted as, including but not limited to in the manner commonly used in patent contexts. The use of broader terms such as "comprises," "includes," and "having" should be understood to provide support for narrower terms such as "consisting of," "consisting essentially of," and "comprised substantially of."

[0264] The words "illustrative," "example," "exemplary," and the like are used herein to mean "serving as an example, instance, or illustration" without denoting a qualitative rating or level of quality. Any implementation described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

[0265] Phrases such as "in one embodiment," "according to one embodiment," and the like generally mean that the particular feature, structure, or characteristic that follows the phrase may be included in at least one embodiment of the present disclosure, and may be included in more than one embodiment of the present disclosure (importantly, such phrases do not necessarily refer to the same embodiment).

[0266] The terms "about," "approximately," and the like, when used in conjunction with a number, may refer to that particular number or, alternatively, a range surrounding the particular number, as would be understood by one of ordinary skill in the art. stomach.

[0267] When the specification states that a component or feature "may," "can," "could," "should," "would," or "preferably," "possibly," "typically," "optionally," "for example," "often," "might" (or other such language) be included or have a characteristic, that particular component or feature need not be included or have the characteristic. Such a component or feature may be optionally included or excluded in some embodiments.

[0268] The term "plurality" refers to two or more items.

[0269] The term "set" refers to a collection of one or more items.

[0270] The term "or" is used herein in its alternative and conjunctive sense, unless otherwise indicated.

[0271] Additional implementation details Thus, particular embodiments of the subject matter have been described. While the specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that are specific to particular embodiments of a particular invention. Other embodiments are within the scope of the following claims. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while features may be described above as acting in a particular combination and initially claimed as such, one or more features from a claimed combination may, in some cases, be deleted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination. Similarly, the separation of various system components in the foregoing embodiments should not be understood to require such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged in multiple software products.

[0272] As described above and as will be understood based on this disclosure, embodiments of the present disclosure may be configured as a system, a method, an apparatus, a computing device, a personal computer, a server, a mobile device, a back-end network device, etc. Accordingly, embodiments may include various means, including entirely hardware or any combination of software and hardware. Furthermore, embodiments may take the form of a computer program product on at least one non-transitory computer-readable storage medium having computer-readable program instructions embodied therein (e.g., computer software stored on a hardware device). Any suitable computer-readable storage medium may be utilized, including a non-transitory hard disk, CD-ROM, flash memory, optical storage device, or magnetic storage device. Accordingly, the non-transitory computer-readable storage medium may be configured to store firmware, one or more application programs, and / or other software, including instructions and / or other computer-readable program code portions executable to control processors of components of server device 800 and / or client device 900 to implement various operations, including the examples illustrated herein. As will be understood, any such computer-readable storage medium may be configured to store firmware, one or more application programs, and / or other software, including instructions and / or other computer-readable program code portions executable to control processors of components of server device 800 and / or client device 900 to implement various operations, including the examples illustrated herein. The computer program instructions and / or other types of code can be loaded into the circuitry of a computer, processor, or other programmable apparatus to produce a machine, such that the computer, processor, or other programmable circuitry executing the code on the machine creates means for implementing various functions, including those described herein with respect to the components of the hybrid website interface rendering server 512 and / or the client device 508. It should also be noted that all or part of the information discussed herein can be based on data received, generated, and / or maintained by one or more components of the hybrid website interface rendering server 512 and / or the client device 508. In some embodiments, one or more external systems (e.g., remote cloud computing and / or data storage systems) may be leveraged to provide at least some of the functionality described herein.

[0273] The following exemplary embodiments are provided, the numbering of which should not be construed as designating a level of importance or relevance.

[0274] Embodiment 1 provides a website construction system configured to enable rendering of a hybrid website interface based on at least one trusted website code definition element and at least one untrusted website code component, the website construction system including at least one processor and at least one non-transitory memory including program code, wherein the at least one non-transitory memory and the program code are configured to cause the website construction system, using the at least one processor, to at least provide a primary execution environment configured to execute one or more trusted website code definition elements; provide one or more sandbox execution environments configured to execute one or more untrusted website code components; provide one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; and cause rendering of a hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components are executed via the one or more proxy translation components.

[0275] Embodiment 2 provides the website building system according to embodiment 1, in which the one or more proxy conversion components include at least one primary execution environment proxy conversion component and at least one sandbox execution environment proxy conversion component.

[0276] Embodiment 3 provides a website construction system described in any one of embodiments 1 to 2, wherein providing a primary execution environment and providing one or more sandbox execution environments includes mapping the rendering order of one or more trusted website code definition elements and one or more untrusted website code components across the execution environments.

[0277] Embodiment 4 provides a website construction system described in any one of embodiments 1 to 3, in which one or more primary execution environment proxy conversion components operate in the primary execution environment and are configured as placeholders for one or more corresponding untrusted website code definition elements in rendering order.

[0278] In embodiment 5, a first trusted website code executed in the primary execution environment Provided is a website building system as described in any one of embodiments 1 to 4, wherein the definition element is configured to receive a trigger event and send the trigger event downstream to a subsequent primary execution environment proxy translation component running in the primary execution environment, and the subsequent primary execution environment proxy translation component communicates a message to its corresponding untrusted website code component running in the first sandbox execution environment.

[0279] A sixth embodiment provides the website construction system according to any one of the first to fifth embodiments, in which the trigger event is a client event resulting from a user interaction with a browser running on a client device.

[0280] Embodiment 7 provides a website construction system described in any one of embodiments 1 to 6, wherein a first untrusted website code component is executed in a first sandbox execution environment, an output of the execution of the first untrusted website code component includes tracking data, and the tracking data is communicated to a corresponding primary execution environment proxy conversion component running in the primary execution environment.

[0281] An eighth embodiment provides a website building system according to any one of the first to seventh embodiments, wherein during execution, the first untrusted website code component performs a simulated rendering of itself.

[0282] Embodiment 9 provides a website construction system according to any one of embodiments 1 to 8, wherein during execution, the corresponding primary execution environment proxy conversion component provides the tracking data as input data to the subsequent trusted website code definition element in the rendering order.

[0283] Embodiment 10 provides a website construction system described in any one of embodiments 1 to 9, in which one or more sandbox execution environment proxy conversion components operate in a first sandbox execution environment and are configured as placeholders for one or more corresponding trusted website code components in the rendering order.

[0284] An eleventh embodiment provides the website building system according to any one of the first to tenth embodiments, wherein the second untrusted website code component is executed in a second separate sandbox execution environment.

[0285] Embodiment 12 provides a website construction system described in any one of embodiments 1 to 11, in which the rendering order includes at least a trusted root website code definition element of the primary execution environment and an untrusted root website code component of the first sandbox execution environment.

[0286] Embodiment 13 provides a website construction system described in any one of embodiments 1 to 12, wherein the program code is further configured to cause the website construction system, using at least one processor, to at least receive a code execution request, wherein the code execution request triggers an execution instruction to a trusted root website code definition element of the primary execution environment, and the trusted root website code definition element sends another execution instruction to an untrusted root website code component of the first sandbox execution environment.

[0287] Embodiment 14 is an implementation in which at least one of the one or more untrusted website code components includes a third-party application or third-party code. The website construction system according to any one of the first to thirteenth embodiments is provided.

[0288] Embodiment 15 provides a website construction system described in any one of embodiments 1 to 14, wherein at least one of the one or more untrusted website code components includes untested or insufficiently tested code.

[0289] Embodiment 16 provides the website construction system according to any one of Embodiments 1 to 15, wherein the first untrusted website code component includes a presentation code subcomponent and a logic code subcomponent.

[0290] Embodiment 17 provides a website construction system described in any one of embodiments 1 to 16, further including a J compiler, configured to extract a declarative programming language expression from a presentation code subcomponent of the first untrusted website code component, compile the extracted declarative programming language expression to form a secure code component that executes in the primary execution environment, and form one or more proxy translation components that execute in the primary execution environment from the presentation code subcomponent of the first untrusted website code component.

[0291] Embodiment 18 provides a website construction system described in any one of embodiments 1 to 17, wherein a first trusted website code definition element of the one or more trusted website code definition elements includes a declarative programming language expression.

[0292] Embodiment 19 provides the website construction system according to any one of embodiments 1 to 18, in which the first trusted website code definition element is configured to define a function that accepts tracking data.

[0293] Embodiment 20 provides a website construction system according to any one of embodiments 1 to 19, wherein the first trusted website code definition element includes instructions configured to be compiled into logic instructions.

[0294] A twenty-first embodiment provides a website construction system according to any one of the first to twentieth embodiments, in which the declarative programming language expression is verifiable through static analysis.

[0295] Embodiment 22 provides a website construction system described in any one of embodiments 1 to 21, wherein the program code is further configured to cause the website construction system, using at least one processor, to at least analyze a plurality of website code structures configured to render a hybrid website interface, parse the plurality of website code structures, and programmatically determine and classify at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0296] Embodiment 23 provides a website building system described in any one of embodiments 1 to 22, including one or more trained machine learning models for programmatically determining and classifying at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0297] In embodiment 24, the execution output of the primary execution environment is a hybrid website interface. The present invention provides a website construction system according to any one of the first to twenty-third embodiments, which creates or updates a structure in a document object model (DOM) of the website.

[0298] Embodiment 25 provides a website construction system described in any one of embodiments 1 to 24, wherein the DOM of the hybrid website interface is associated with at least one document data structure, and the at least one document data structure includes one or more of a tree structure data structure, a forest structure data structure, a federated architecture data structure, a graph data structure, a reference table, an object database, a flat data structure, a hash table, or a combination thereof.

[0299] A twenty-sixth embodiment provides the website construction system according to any one of the first to twenty-fifth embodiments, in which the rendering of the hybrid website interface is client-side rendering.

[0300] A twenty-seventh embodiment provides the website construction system according to any one of the first to twenty-sixth embodiments, in which the rendering of the hybrid website interface is server-side rendering.

[0301] Embodiment 28 provides a computer-implemented method for enabling rendering of a hybrid website interface based on at least one trusted website code definition element and at least one untrusted website code component, the computer-implemented method including the steps of: providing a primary execution environment configured to execute one or more trusted website code definition elements; providing one or more sandbox execution environments configured to execute one or more untrusted website code components; providing one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; and rendering the hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components have been executed via the one or more proxy translation components.

[0302] Embodiment 29 provides a computer-implemented method according to embodiment 28, wherein the one or more proxy translation components include at least one primary execution environment proxy translation component and at least one sandbox execution environment proxy translation component.

[0303] Embodiment 30 provides a computer-implemented method described in any one of embodiments 28 to 29, wherein the steps of providing a primary execution environment and providing one or more sandbox execution environments include mapping the rendering order of one or more trusted website code definition elements and one or more untrusted website code components across the execution environments.

[0304] Embodiment 31 provides a computer-implemented method described in any one of embodiments 28 to 30, in which one or more primary execution environment proxy conversion components operate in the primary execution environment and are configured as placeholders for one or more corresponding untrusted website code definition elements in rendering order.

[0305] In embodiment 32, a first trusted website code definition element executed in a primary execution environment receives a trigger event, and the trigger event is transmitted to the primary execution environment. The computer-implemented method of any one of embodiments 28 to 31 is provided, wherein the subsequent primary execution environment proxy translation component is configured to communicate the message downstream to a subsequent primary execution environment proxy translation component running in the first sandbox execution environment, and the subsequent primary execution environment proxy translation component is configured to communicate the message to its corresponding untrusted website code component running in the first sandbox execution environment.

[0306] Embodiment 33 provides a computer-implemented method according to any one of embodiments 28 to 32, in which the trigger event is a client event resulting from a user interaction with a browser running on a client device.

[0307] Embodiment 34 provides a computer-implemented method described in any one of embodiments 28 to 33, in which a first untrusted website code component is executed in a first sandbox execution environment, output of the execution of the first untrusted website code component includes tracking data, and the tracking data is communicated to a corresponding primary execution environment proxy translation component running in the primary execution environment.

[0308] Embodiment 35 provides a computer-implemented method according to any one of embodiments 28 to 34, wherein during execution, the first untrusted website code component performs a simulated rendering of itself.

[0309] Embodiment 36 provides a computer-implemented method according to any one of embodiments 28 to 35, wherein during execution, the corresponding primary execution environment proxy conversion component provides tracking data as input data to subsequent trusted website code definition elements in rendering order.

[0310] Embodiment 37 provides a computer-implemented method described in any one of embodiments 28 to 36, in which one or more sandbox execution environment proxy conversion components operate in a first sandbox execution environment and are configured as placeholders for one or more corresponding trusted website code components in the rendering order.

[0311] Embodiment 38 provides a computer-implemented method according to any one of embodiments 28 to 37, in which the second untrusted website code component is executed in a second separate sandbox execution environment.

[0312] Embodiment 39 provides a computer-implemented method described in any one of embodiments 28 to 38, in which the rendering order includes at least a trusted root website code definition element of the primary execution environment and an untrusted root website code component of the first sandbox execution environment.

[0313] Embodiment 40 provides a computer-implemented method described in any one of embodiments 28 to 39, further including a step of receiving a code execution request, wherein the code execution request triggers an execution instruction to a trusted root website code definition element of the primary execution environment, and the trusted root website code definition element sends another execution instruction to an untrusted root website code component of the first sandbox execution environment.

[0314] Embodiment 41 provides a computer-implemented method according to any one of embodiments 28 to 40, wherein at least one of the one or more untrusted website code components includes a third-party application or third-party code.

[0315] Embodiment 42 provides a computer-implemented method described in any one of embodiments 28 to 41, wherein at least one of the one or more untrusted website code components includes untested or insufficiently tested code.

[0316] Embodiment 43 provides a computer-implemented method according to any one of embodiments 28 to 42, wherein the first untrusted website code component includes a presentation code subcomponent and a logic code subcomponent.

[0317] Embodiment 44 provides a computer-implemented method described in any one of embodiments 28 to 43, further comprising the steps of providing a J compiler, extracting a declarative programming language expression from a presented code subcomponent of the first untrusted website code component via the J compiler, compiling the extracted declarative programming language expression via the J compiler to form a secure code component that executes in the primary execution environment, and forming one or more proxy translation components that execute in the primary execution environment from the presented code subcomponents of the first untrusted website code component via the J compiler.

[0318] Embodiment 45 provides a computer-implemented method described in any one of embodiments 28 to 44, wherein a first trusted website code definition element of the one or more trusted website code definition elements includes a declarative programming language expression.

[0319] Embodiment 46 provides a computer-implemented method according to any one of embodiments 28 to 45, in which the first trusted website code definition element is configured to define a function that accepts tracking data.

[0320] Embodiment 47 provides a computer-implemented method described in any one of embodiments 28 to 46, wherein the first trusted website code definition element includes instructions configured to be compiled into logic instructions.

[0321] Embodiment 48 provides a computer-implemented method according to any one of embodiments 28 to 47, in which the declarative programming language expression is verifiable via static analysis.

[0322] Embodiment 49 provides a computer-implemented method described in any one of embodiments 28 to 48, further comprising the steps of analyzing a plurality of website code structures configured to render a hybrid website interface, parsing the plurality of website code structures, and programmatically determining and classifying at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0323] Embodiment 50 provides a computer-implemented method described in any one of embodiments 28 to 49, in which one or more trained machine learning models perform the steps of programmatically determining and classifying at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0324] Embodiment 51 provides a computer-implemented method according to any one of embodiments 28 to 50, in which the execution output of the primary execution environment creates or updates a structure within the document object model (DOM) of the hybrid website interface.

[0325] Embodiment 52 provides a computer-implemented method described in any one of embodiments 28 to 51, wherein the DOM of the hybrid website interface is associated with at least one document data structure, and the at least one document data structure includes one or more of a tree structure data structure, a forest structure data structure, a federated architecture data structure, a graph data structure, a lookup table, an object database, a flat data structure, a hash table, or a combination thereof.

[0326] Embodiment 53 provides a computer-implemented method according to any one of embodiments 28 to 52, in which the rendering of the hybrid website interface is client-side rendering.

[0327] Embodiment 54 provides a computer-implemented method according to any one of embodiments 28 to 53, in which the rendering of the hybrid website interface is server-side rendering.

[0328] Embodiment 55 provides a computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code being configured, when executed using at least one processor, to provide a primary execution environment configured to execute one or more trusted website code definition elements, to provide one or more sandbox execution environments configured to execute one or more untrusted website code components, to provide one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements, and to cause rendering of a hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components are executed via the one or more proxy translation components.

[0329] Embodiment 56 provides a computer program product as described in embodiment 55, wherein the one or more proxy translation components include at least one primary execution environment proxy translation component and at least one sandbox execution environment proxy translation component.

[0330] Embodiment 57 provides a computer program product described in any one of embodiments 55 to 56, wherein providing a primary execution environment and providing one or more sandbox execution environments includes mapping the rendering order of one or more trusted website code definition elements and one or more untrusted website code components across the execution environments.

[0331] Embodiment 58 provides a computer program product described in any one of embodiments 55 to 57, in which one or more primary execution environment proxy conversion components operate in the primary execution environment and are configured as placeholders for one or more corresponding untrusted website code definition elements in rendering order.

[0332] Embodiment 59 is a first trusted website code definition element executed in a primary execution environment to receive a trigger event, and send the trigger event downstream to a subsequent primary execution environment proxy translation component executed in the primary execution environment, and the subsequent primary execution environment proxy translation component executes a first sandbox The computer program product of any one of embodiments 55 to 58 is provided, which is configured to communicate a message to its corresponding untrusted website code component running in the execution environment.

[0333] Embodiment 60 provides a computer program product according to any one of embodiments 55 to 59, wherein the trigger event is a client event resulting from a user interaction with a browser running on a client device.

[0334] Embodiment 61 provides a computer program product described in any one of embodiments 55 to 60, wherein a first untrusted website code component is executed in a first sandbox execution environment, output of the execution of the first untrusted website code component includes tracking data, and the tracking data is communicated to a corresponding primary execution environment proxy translation component executing in the primary execution environment.

[0335] Embodiment 62 provides a computer program product according to any one of embodiments 55 to 61, wherein during execution, the first untrusted website code component performs a simulated rendering of itself.

[0336] Embodiment 63 provides a computer program product described in any one of embodiments 55 to 62, wherein during execution, the corresponding primary execution environment proxy conversion component provides tracking data as input data to subsequent trusted website code definition elements in rendering order.

[0337] Embodiment 64 provides a computer program product described in any one of embodiments 55 to 63, wherein one or more sandbox execution environment proxy conversion components operate in a first sandbox execution environment and are configured as placeholders for one or more corresponding trusted website code components in the rendering order.

[0338] Embodiment 65 provides a computer program product according to any one of embodiments 55 to 64, wherein the second untrusted website code component is executed in a second separate sandbox execution environment.

[0339] Embodiment 66 provides a computer program product described in any one of embodiments 55 to 65, wherein the rendering order includes at least a trusted root website code definition element of the primary execution environment and an untrusted root website code component of the first sandbox execution environment.

[0340] Embodiment 67 provides a computer program product described in any one of embodiments 55 to 66, further configured to receive a code execution request, wherein the code execution request triggers an execution instruction to a trusted root website code definition element of the primary execution environment, and the trusted root website code definition element sends another execution instruction to an untrusted root website code component of the first sandbox execution environment.

[0341] Embodiment 68 provides a computer program product according to any one of embodiments 55 to 67, wherein at least one of the one or more untrusted website code components includes a third-party application or third-party code.

[0342] Embodiment 69 is the same as embodiment 5, wherein at least one of the one or more untrusted website code components includes untested or insufficiently tested code. The present invention provides a computer program product according to any one of claims 5 to 68.

[0343] Embodiment 70 provides a computer program product according to any one of embodiments 55 to 69, wherein the first untrusted website code component includes a presentation code subcomponent and a logic code subcomponent.

[0344] Embodiment 71 provides a computer program product described in any one of embodiments 55 to 70, further configured to extract a declarative programming language expression from a presentation code subcomponent of the first untrusted website code component, compile the extracted declarative programming language expression to form a secure code component that executes in the primary execution environment, and form one or more proxy translation components that execute in the primary execution environment from the presentation code subcomponent of the first untrusted website code component.

[0345] Embodiment 72 provides a computer program product described in any one of embodiments 55 to 71, wherein a first trusted website code definition element of the one or more trusted website code definition elements includes a declarative programming language expression.

[0346] Embodiment 73 provides a computer program product according to any one of embodiments 55 to 72, wherein the first trusted website code definition element is configured to define a function that accepts tracking data.

[0347] Embodiment 74 provides a computer program product according to any one of embodiments 55 to 73, wherein the first trusted website code definition element includes instructions configured to be compiled into logic instructions.

[0348] Embodiment 75 provides a computer program product according to any one of embodiments 55 to 74, wherein the declarative programming language expressions are verifiable through static analysis.

[0349] Embodiment 76 provides a computer program product according to any one of embodiments 55 to 75, further configured to analyze a plurality of website code structures configured to render a hybrid website interface, parse the plurality of website code structures, and programmatically determine and classify at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0350] Embodiment 77 provides a computer program product described in any one of embodiments 55 to 76, which executes one or more trained machine learning models to programmatically determine and classify at least one website code structure as a trusted website code definition element and at least one other website code structure as an untrusted website code component.

[0351] Embodiment 78 provides a computer program product according to any one of embodiments 55 to 77, wherein the execution output of the primary execution environment creates or updates a structure within the document object model (DOM) of the hybrid website interface.

[0352] Embodiment 79 is a method for implementing the hybrid website interface, wherein the DOM of the hybrid website interface is associated with at least one document data structure, and the at least one document data structure is a tree structure data structure, a forest structure data structure, a federated architecture data structure, or the like. 79. The computer program product of any one of embodiments 55 to 78, wherein the computer program product includes one or more of a matrix data structure, a graph data structure, a lookup table, an object database, a flat data structure, a hash table, or a combination thereof.

[0353] Embodiment 80 provides a computer program product according to any one of embodiments 55 to 79, in which the rendering of the hybrid website interface is client-side rendering.

[0354] Embodiment 81 provides a computer program product according to any one of embodiments 55 to 80, in which the rendering of the hybrid website interface is server-side rendering.

[0355] Embodiment 82 provides a website construction system configured to enable rendering of a hybrid website interface based on at least one trusted code structure and at least one untrusted code structure, the website construction system including at least one processor and at least one non-transitory memory including program code, wherein the at least one non-transitory memory and the program code are configured to cause the website construction system, using the at least one processor, to at least access a code repository to identify at least one untrusted website code structure and at least one trusted website code structure; convert the at least one untrusted website code structure into a primary execution environment proxy translation component, wherein the at least one untrusted website code structure continues to operate within a sandbox execution environment; generate a primary execution environment configured to execute the at least one trusted website code structure and the primary execution environment proxy translation component; and cause rendering of the hybrid website interface after the at least one trusted website code structure and the at least one untrusted website code structure have been executed via the primary execution environment proxy translation component.

[0356] Embodiment 83 provides a computer-implemented method for enabling rendering of a hybrid website interface based on at least one trusted website code definition element and at least one untrusted website code component, the computer-implemented method including the steps of accessing a code repository; identifying at least one untrusted website code structure and at least one trusted website code structure; converting the at least one untrusted website code structure into a primary execution environment proxy translation component, wherein the at least one untrusted website code structure continues to operate in a sandbox execution environment; generating a primary execution environment configured to execute the at least one trusted website code structure and the primary execution environment proxy translation component; executing the at least one trusted website code structure and the at least one untrusted website code structure through the primary execution environment proxy translation component; and rendering the hybrid website interface after the at least one trusted website code structure and the at least one untrusted website code structure have been executed through the primary execution environment proxy translation component.

[0357] Embodiment 84 is a computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code, when executed by at least one processor, performing at least one The computer program product is configured to: access a code repository to identify two untrusted website code structures and at least one trusted website code structure; translate the at least one untrusted website code structure into a primary execution environment proxy translation component; generate a primary execution environment configured to execute the at least one trusted website code structure and the primary execution environment proxy translation component such that the at least one untrusted website code structure continues to operate within a sandbox execution environment; and cause rendering of a hybrid website interface after the at least one trusted website code structure and the at least one untrusted website code structure have been executed via the primary execution environment proxy translation component.

[0358] Embodiment 85 provides a computer-implemented method for automatically performing trusted code splitting on an untrusted candidate code corpus, the computer-implemented method including the steps of applying a trusted code identification model to the untrusted candidate code corpus to automatically identify one or more trusted code sections, extracting one or more trusted code sections from the untrusted candidate code corpus, generating one or more trusted computer-executable functions based on the one or more trusted code sections, and generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus.

[0359] Embodiment 86 provides a computer-implemented method as described in embodiment 85, in which the steps of generating one or more trusted computer-executable functions and generating one or more untrusted computer-executable functions include the step of generating an intercommunication path between the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions, and the intercommunication path is configured to transmit one or more execution input parameters, one or more execution return values, or a combination thereof during execution of the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions.

[0360] Embodiment 87 provides a computer-implemented method described in any one of embodiments 85 to 86, in which the reliable code identification model is iteratively trained to identify one or more detectable code patterns in a reliable code section in a supervised training process.

[0361] Embodiment 88 provides a computer-implemented method described in any one of embodiments 85 to 87, in which the reliable code identification model is iteratively trained to identify one or more detectable code patterns in a reliable code section in an unsupervised training process.

[0362] Embodiment 89 provides a computer-implemented method described in any one of embodiments 85 to 88, in which the trusted code identification model is trained based on one or more of system provider-defined trusted code, vendor-defined trusted code, or third-party-defined trusted code.

[0363] Embodiment 90 is a method for automatically identifying one or more trusted code sections by applying one or more trusted code identification rules, the method comprising: determining a code context, a code syntax structure, a variable name, a variable type, an associated API, code pattern matching, a code abstract syntax tree (AST) analysis, a declarative code recognition method, and the like. The computer-implemented method according to any one of embodiments 85 to 89 is based on one or more of the following: identification, historical code identification data, or a domain-specific language (DSL).

[0364] Embodiment 91 provides a computer-implemented method described in any one of embodiments 85 to 90, further comprising a step of generating a function structure, wherein the step of generating the function structure comprises a step of communicatively connecting the first trusted computer-executable function to the second untrusted computer-executable function via a mutual communication path so that, during execution, the output of the first trusted computer-executable function serves as an input parameter of the second untrusted computer-executable function, or the output of the second untrusted computer-executable function serves as an input parameter of the first trusted computer-executable function.

[0365] Embodiment 92 provides a computer-implemented method according to any one of embodiments 85 to 91, in which the trusted code identification model is applied using a compiler.

[0366] Embodiment 93 provides a computer-implemented method described in any one of embodiments 85 to 92, further comprising a step of executing one or more trusted computer-executable functions in a primary execution environment and one or more untrusted computer-executable functions in a sandbox execution environment.

[0367] Embodiment 94 provides a computer-implemented method described in any one of embodiments 85 to 93, in which, at runtime, an untrusted code section that requests access to an API that is not connected to the sandbox execution environment fails to execute in the sandbox execution environment.

[0368] Embodiment 95 provides a website construction system configured to automatically perform trusted code splitting on an untrusted candidate code corpus, the website construction system including at least one processor and at least one non-transitory memory containing program code, wherein the at least one non-transitory memory and the program code are configured to cause the website construction system, using the at least one processor, to at least apply a trusted code identification model to the untrusted candidate code corpus to automatically identify one or more trusted code sections, extract one or more trusted code sections from the untrusted candidate code corpus, generate one or more trusted computer-executable functions based on the one or more trusted code sections, and generate one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus.

[0369] Embodiment 96 provides a website construction system as described in embodiment 95, wherein generating one or more trusted computer-executable functions and generating one or more untrusted computer-executable functions includes generating an intercommunication path between the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions, and the intercommunication path is configured to transmit one or more execution input parameters, one or more execution return values, or a combination thereof during execution of the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions.

[0370] Embodiment 97 provides a website building system described in any of embodiments 95 to 96, in which the reliable code identification model is iteratively trained to identify one or more detectable code patterns in reliable code sections in a supervised training process.

[0371] Embodiment 98 provides a website building system described in any of embodiments 95 to 97, in which the trusted code identification model is iteratively trained to identify one or more detectable code patterns in trusted code sections in an unsupervised training process.

[0372] Embodiment 99 provides a website building system described in any of embodiments 95 to 98, in which the trusted code identification model is trained based on one or more of system provider-defined trusted code, vendor-defined trusted code, or third-party-defined trusted code.

[0373] Embodiment 100 provides a website construction system described in any of embodiments 95 to 99, wherein the trusted code identification model applies one or more trusted code identification rules to automatically identify one or more trusted code sections, and the one or more trusted code identification rules are based on one or more of code context, code syntax structure, variable names, variable types, associated APIs, code pattern matching, code abstract syntax tree (AST) analysis, declarative code recognition, historical code identification data, or domain-specific languages ​​(DSLs).

[0374] Embodiment 101 provides a website construction system described in any of embodiments 95 to 100, wherein the program code is further configured to cause the website construction system to at least generate a function structure using at least one processor, and generating the function structure includes communicatively connecting the first trusted computer-executable function to the second untrusted computer-executable function via a mutual communication path so that, during execution, the output of the first trusted computer-executable function serves as an input parameter of the second untrusted computer-executable function, or the output of the second untrusted computer-executable function serves as an input parameter of the first trusted computer-executable function.

[0375] Embodiment 102 provides the website construction system according to any one of embodiments 95 to 101, in which the trusted code identification model is applied using a compiler.

[0376] Embodiment 103 provides a website construction system described in any of embodiments 95 to 102, wherein the program code is further configured to cause the website construction system, using at least one processor, to execute at least one trusted computer-executable function in a primary execution environment and one or more untrusted computer-executable function in a sandbox execution environment.

[0377] Embodiment 104 provides a website construction system described in any of embodiments 95 to 103, in which, at runtime, an untrusted code section that requests access to an API that is not connected to the sandbox execution environment fails to execute in the sandbox execution environment.

[0378]

[0033] Embodiment 105 is a computer program product including at least one non-transitory computer-readable storage medium having stored thereon computer program code, the computer program code, when executed by at least one processor, configured to apply a trusted code identification model to an untrusted candidate code corpus to automatically identify one or more trusted code sections, extract one or more trusted code sections from the untrusted candidate code corpus, generate one or more trusted computer-executable functions based on the one or more trusted code sections, and generate one or more trusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus. The present invention provides a computer program product configured to generate one or more untrusted computer-executable functions based on the algorithm.

[0379] Embodiment 106 provides a computer program product as described in embodiment 105, wherein generating one or more trusted computer-executable functions and generating one or more untrusted computer-executable functions includes generating an intercommunication path between the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions, and the intercommunication path is configured to transmit one or more execution input parameters, one or more execution return values, or a combination thereof during execution of the one or more trusted computer-executable functions and the one or more untrusted computer-executable functions.

[0380] Embodiment 107 provides a computer program product described in any one of embodiments 105 to 106, in which the reliable code identification model is iteratively trained to identify one or more detectable code patterns in a reliable code section in a supervised training process.

[0381] Embodiment 108 provides a computer program product described in any one of embodiments 105 to 107, in which the reliable code identification model is iteratively trained to identify one or more detectable code patterns in a reliable code section in an unsupervised training process.

[0382] Embodiment 109 provides a computer program product described in any one of embodiments 105 to 108, wherein the trusted code identification model is trained based on one or more of system provider-defined trusted code, vendor-defined trusted code, or third-party-defined trusted code.

[0383] Embodiment 110 provides a computer program product described in any one of embodiments 105 to 109, wherein the trusted code identification model applies one or more trusted code identification rules to automatically identify one or more trusted code sections, and the one or more trusted code identification rules are based on one or more of code context, code syntax structure, variable names, variable types, associated APIs, code pattern matching, code abstract syntax tree (AST) analysis, declarative code recognition, historical code identification data, or domain-specific languages ​​(DSLs).

[0384] Embodiment 111 provides a computer program product described in any one of embodiments 105 to 110, further configured to generate a function structure, wherein generating the function structure includes communicatively connecting the first trusted computer-executable function to the second untrusted computer-executable function via a mutual communication path so that, during execution, an output of the first trusted computer-executable function serves as an input parameter of the second untrusted computer-executable function, or an output of the second untrusted computer-executable function serves as an input parameter of the first trusted computer-executable function.

[0385] Embodiment 112 provides a computer program product according to any one of embodiments 105 to 111, in which the trusted code identification model is applied using a compiler.

[0386] Embodiment 113 is the method according to any one of embodiments 105 to 112, further configured to execute one or more trusted computer-executable functions in the primary execution environment and one or more untrusted computer-executable functions in the sandbox execution environment. A computer program product is provided.

[0387] Embodiment 114 provides a computer program product described in any one of embodiments 105 to 113, in which, at runtime, an untrusted code section that requests access to an API that is not connected to the sandbox execution environment fails to execute in the sandbox execution environment.

[0388] Embodiment 115 provides a computer-implemented method for enabling rendering of a hybrid website interface, the computer-implemented method including the steps of identifying one or more trusted code sections in an untrusted candidate code corpus; extracting one or more trusted code sections from the untrusted candidate code corpus; generating one or more trusted computer-executable functions based on the one or more trusted code sections; generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus; and rendering the hybrid website interface after executing the one or more trusted computer-executable functions in a primary execution environment and the one or more untrusted computer-executable functions in a sandbox execution environment.

[0389] Embodiment 116 provides a computer-implemented method according to embodiment 115, in which the compiler identifies one or more trusted code sections within the untrusted candidate code.

[0390] Embodiment 117 provides a computer-implemented method described in any one of embodiments 115 to 116, in which the step of identifying one or more trusted code sections includes the step of identifying one or more detectable code patterns.

[0391] Embodiment 118 provides a computer-implemented method described in any one of embodiments 115 to 117, wherein the step of identifying one or more detectable code patterns is based at least in part on matching sections of unreliable candidate code with predetermined patterns of code.

[0392] Embodiment 119 provides a computer-implemented method described in any one of embodiments 115 to 118, wherein the step of identifying one or more trusted code sections is based at least in part on one or more permitted APIs.

[0393] Embodiment 120 provides a computer-implemented method described in any one of embodiments 115 to 119, further including a step of generating a statistical report based on one or more compilation performance metrics and a step of providing the statistical report to a user.

[0394] Embodiment 121 is a website building system configured to enable rendering of a hybrid website interface, the system including at least one processor and at least one non-transitory memory including program code, wherein the at least one non-transitory memory and the program code are configured to provide, using the at least one processor, the website building system with at least the following steps: identifying one or more trusted code sections in an untrusted candidate code corpus; extracting one or more trusted code sections from the untrusted candidate code corpus; generating one or more trusted computer-executable functions based on the one or more trusted code sections; generating one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus; and A website building system is provided that is configured to cause rendering of a hybrid website interface after executing one or more trusted computer-executable functions in a mari execution environment and one or more untrusted computer-executable functions in a sandbox execution environment.

[0395] Embodiment 122 provides a website building system as described in embodiment 121, in which the compiler identifies one or more trusted code sections within the untrusted candidate code.

[0396] Embodiment 123 provides a website construction system described in any one of embodiments 121 to 122, wherein identifying one or more trusted code sections includes identifying one or more detectable code patterns.

[0397] Embodiment 124 provides a website building system described in any one of embodiments 121 to 123, wherein identifying one or more detectable code patterns is based at least in part on matching sections of unreliable candidate code with predetermined patterns of code.

[0398] Embodiment 125 provides a website building system according to any one of embodiments 121 to 124, wherein identifying one or more trusted code sections is based at least in part on one or more authorized APIs.

[0399] Embodiment 126 provides a website construction system described in any one of embodiments 121 to 125, wherein the program code is further configured to cause the website construction system, using at least one processor, to at least generate a statistical report based on one or more compilation performance metrics and provide the statistical report to a user.

[0400] Embodiment 127 provides a computer program product including at least one non-transitory computer-readable storage medium having computer program code stored thereon, the computer program code being configured, when executed using at least one processor, to identify one or more trusted code sections in an untrusted candidate code corpus, extract one or more trusted code sections from the untrusted candidate code corpus, generate one or more trusted computer-executable functions based on the one or more trusted code sections, generate one or more untrusted computer-executable functions based on one or more untrusted code sections remaining in the untrusted candidate code corpus, and render a hybrid website interface after executing the one or more trusted computer-executable functions in a primary execution environment and the one or more untrusted computer-executable functions in a sandbox execution environment.

[0401] Embodiment 128 provides a computer program product according to embodiment 127, in which the compiler identifies one or more trusted code sections within the untrusted candidate code.

[0402] Embodiment 129 provides a computer program product described in any one of embodiments 127 to 128, wherein identifying one or more trusted code sections includes identifying o...

Claims

1. 1. A website construction system configured to enable rendering of a hybrid website interface based on at least one trusted website code definition element and at least one untrusted website code component, the system comprising: at least one processor; and at least one non-transitory memory including program code, the at least one non-transitory memory and the program code being configured to provide the website construction system, using the at least one processor, with at least: providing a primary execution environment configured to execute one or more trusted website code-defined elements; providing one or more sandbox execution environments configured to execute one or more untrusted website code components; providing one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; and causing rendering of the hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components are executed through the one or more proxy translation components. A website building system configured to:

2. The website building system of claim 1 , wherein the one or more proxy translation components include at least one primary execution environment proxy translation component and at least one sandbox execution environment proxy translation component.

3. 3. The website building system of claim 2, wherein providing the primary execution environment and providing the one or more sandbox execution environments includes mapping a rendering order of the one or more trusted website code definition elements and the one or more untrusted website code components across the execution environments.

4. The website building system of claim 3 , wherein one or more primary execution environment proxy translation components operate in the primary execution environment and are configured as placeholders for the one or more corresponding untrusted website code definition elements in the rendering order.

5. a first trusted website code definition element executing in the primary execution environment, to receive a trigger event, and Send the trigger event downstream to a subsequent primary execution environment proxy translation component running in the primary execution environment, such that the subsequent primary execution environment proxy translation component communicates a message to its corresponding untrusted website code component running in a first sandbox execution environment.

5. The website building system according to claim 4,

6. The website building system of claim 5 , wherein the trigger event is a client event resulting from a user interaction with a browser running on a client device.

7. A first untrusted website code component is executed in a first sandbox execution environment, an output of the execution of the first untrusted website code component includes trace data, and the trace data is obtained by executing the first untrusted website code component in the primary execution environment. The website building system according to claim 3 , wherein the proxy conversion component is communicated to a corresponding primary execution environment proxy conversion component.

8. The website building system of claim 7 , wherein during execution, the first untrusted website code component performs a simulated rendering of itself.

9. The website building system of claim 7 , wherein during execution, the corresponding primary execution environment proxy conversion component provides the tracking data as input data to subsequent trusted website code definition elements in the rendering order.

10. 4. The website building system of claim 3, wherein one or more sandbox execution environment proxy conversion components operate in a first sandbox execution environment and are configured as placeholders for the one or more corresponding trusted website code components in the rendering order.

11. The website building system of claim 10 , wherein the second untrusted website code component executes in a second separate sandbox execution environment.

12. The website building system of claim 3 , wherein the rendering order includes at least a trusted root website code definition element of the primary execution environment and an untrusted root website code component of a first sandbox execution environment.

13. The program code, using the at least one processor, causes the website building system to at least: receiving a code execution request, the code execution request triggering an execution instruction to the trusted root website code definition element of the primary execution environment, and the trusted root website code definition element sending another execution instruction to the untrusted root website code component of the first sandbox execution environment; The website building system according to claim 3 , further configured to:

14. The website building system of claim 1 , wherein at least one of the one or more untrusted website code components comprises a third-party application or third-party code.

15. The website building system of claim 1 , wherein at least one of the one or more untrusted website code components comprises untested or insufficiently tested code.

16. The website building system of claim 1 , wherein the first untrusted website code component includes a presentation code subcomponent and a logic code subcomponent.

17. The method further includes a J compiler, wherein the J compiler comprises: extracting a declarative programming language expression from the presentation code subcomponent of the first untrusted website code component; compiling the extracted declarative programming language expressions to form secure code components that execute in the primary execution environment; and the presentation code subcomponent of the first untrusted website code component; to form the one or more proxy translation components that run in the primary execution environment from the 17. The website building system according to claim 16,

18. The website building system of claim 1 , wherein a first trusted website code definition element of the one or more trusted website code definition elements comprises a declarative programming language expression.

19. 20. The website building system of claim 18, wherein the first trusted website code definition element is configured to define a function that accepts tracking data.

20. 20. The website building system of claim 18, wherein the first trusted website code definition element comprises instructions configured to be compiled into logic instructions.

21. 20. The website building system of claim 18, wherein the declarative programming language expressions are verifiable via static analysis.

22. The program code causes the website building system to at least: analyzing a plurality of website code structures configured to render the hybrid website interface; parsing the plurality of website code structures; and programmatically determining and classifying at least one website code structure as a trusted website code component and at least one other website code structure as an untrusted website code component; The website building system of claim 1 , further configured to:

23. 23. The website building system of claim 22, comprising one or more trained machine learning models for programmatically determining and classifying the at least one website code structure as a trusted website code component and the at least one other website code structure as an untrusted website code component.

24. The website building system of claim 1 , wherein an execution output of the primary execution environment creates or updates a structure in a Document Object Model (DOM) of the hybrid website interface.

25. 25. The website building system of claim 24, wherein the DOM of the hybrid website interface is associated with at least one document data structure, and the at least one document data structure comprises one or more of a tree structure data structure, a forest structure data structure, a federated architecture data structure, a graph data structure, a lookup table, an object database, a flat data structure, a hash table, or combinations thereof.

26. The website building system of claim 1 , wherein the rendering of the hybrid website interface is client-side rendering.

27. The website building system according to claim 1 , wherein the rendering of the hybrid website interface is server-side rendering.

28. At least one trusted website code definition element and at least one trusted 1. A computer-implemented method for enabling rendering of a hybrid website interface based on inaccessible website code components, comprising: providing a primary execution environment configured to execute one or more trusted website code definition elements; providing one or more sandbox execution environments configured to execute one or more untrusted website code components; providing one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; rendering the hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components have been executed through the one or more proxy translation components; 11. A computer-implemented method comprising:

29. 1. A computer program product comprising at least one non-transitory computer-readable storage medium having computer program code stored thereon, said computer program code, when executed using at least one processor, providing a primary execution environment configured to execute one or more trusted website code-defined elements; providing one or more sandbox execution environments configured to execute one or more untrusted website code components; providing one or more proxy translation components configured to communicatively link the one or more untrusted website code components to at least one of the one or more trusted website code definition elements; and causing rendering of the hybrid website interface after the at least one trusted website code definition element and the one or more untrusted website code components are executed through the one or more proxy translation components. A computer program product comprising:

Images