JASP uses R and several third-party R-packages from CRAN for its analyses, and it is impossible to check all of this code thoroughly. Although CRAN does a good job at keeping malicious packages out of their repositories there is a always a chance such infiltration may happen. The same possibility exists for R-packages developed by third parties as part of JASP modules. To try and avoid any compromised package from wreaking havoc on the user’s system, JASP has implemented a Windows sandbox around R. The Windows sandbox limits what can be accessed by any analysis or R-code running in JASP:
1. File system restrictions
The Windows sandbox uses an allow-list approach: the engine process can only interact with a small number of explicitly approved locations. In particular:
User workspace directory
Used for:
Reading user-selected data files.
Writing analysis results and exported models/outputs.
Confined to this dedicated path; no ambient access to arbitrary folders such as Documents, Desktop, network drives, or other application data.
Application data directory (engine infrastructure)
A dedicated folder under the application’s data area.
Used for:
Inter-process communication (IPC) between the GUI and the engine.
Logs and temporary engine files.
Not a general-purpose scratch space for user data.
All other file system locations are blocked for the sandboxed engine. This means that R code (including any code from R packages shipped with or used by JASP) cannot read or modify arbitrary files on the machine.
2. Network restrictions
By default, the sandboxed engine has no network access:
No outbound connections (e.g., cannot send data to external servers).
No inbound connections.
No implicit access to proxies, mapped endpoints, or internal services.
This design directly mitigates the classic “malicious package phones home” scenario: even if an R package or script attempted to exfiltrate data, the call would be blocked at the sandbox boundary.
3. Execution control
Key properties of the sandboxed engine:
It runs only the JASP-managed R environment and packages shipped or configured with JASP.
It is invoked and controlled solely by the trusted GUI application.
Communication between GUI and engine is limited to:
Structured messages (analysis requests, results) via controlled IPC.
Files in the dedicated application data directory.
The engine cannot spawn arbitrary unsandboxed helper processes with broader privileges (by design and by sandbox policy).
4. Main application trust boundary
The main JASP executable:
Contains only JASP’s own source code plus well-known libraries such as Qt.
Is built from an open-source codebase publicly available for review on GitHub.
Is distributed as a digitally signed binary so organizations can validate authenticity during deployment.
Because the GUI does not execute untrusted plugin binaries or interpret arbitrary R code outside the engine, the main application forms a relatively narrow and auditable trusted computing base.
