A modern IDE lives and dies by its plugin ecosystem. But allowing third-party developers to execute code inside your IDE is a massive security risk. Traditionally, web apps used <iframe sandbox="..."> to isolate plugins. However, iframes can still communicate with their embedding parent via postMessage, URL parameters, or side-channel attacks, creating vectors for malicious plugins to exfiltrate proprietary source code.
NitroIDE abandons iframes for executing untrusted UI extensions. We implement the newly standardized Fenced Frames API, providing a mathematically guaranteed, cryptographically opaque sandbox.
A <fencedframe> operates under a strict "Privacy Preserving" mandate. Unlike an iframe, a fenced frame cannot read the parent's URL, it cannot send postMessage to the parent, and it cannot access local storage partitions that could be used for cross-site tracking. The boundary is absolute.
Shared Storage Worklets: How does the plugin interact with the IDE if communication is blocked? NitroIDE uses the Shared Storage API. The plugin can write output data (like linter warnings) to a secure shared storage node, which the IDE can read, but the plugin can never read data out of the IDE's storage, ensuring a strictly one-way flow of information.
With Fenced Frames, enterprise teams can safely install community themes, visualizers, and tools without undergoing months of security audits. The browser's native C++ engine mathematically guarantees that the plugin cannot steal your intellectual property.
Browse our extension marketplace, knowing every plugin runs in absolute isolation.
Open Workspace