Security and privacy boundaries
Current native protections
Section titled “Current native protections”The qualified BrowserWindow uses sandbox enabled, context isolation enabled, Node integration disabled and web security enabled. Renderer globals such as require, process and module are unavailable. IPC accepts calls only from the owned main frame and validates supported input fields.
The production renderer’s Content Security Policy restricts scripts/fonts to local resources, disallows direct connections with connect-src 'none', blocks object/frame content and prevents form submissions. Host-brokered inference remains possible because the main process is a separate privilege boundary.
Runtime and files
Section titled “Runtime and files”The application owns a private loopback Lemonade instance. Credentials stay in the host/runtime boundary. Process cleanup applies only to owned children; another local service is not a disposable recovery target. Loopback binding alone is not an authorization policy for a future public server.
GGUF inspection is bounded and structural. Model output is displayed as text rather than executed HTML. Existing model files are read in place and are not rewritten to fix labels, quantization or fit. These design choices reduce exposure; they are not a complete security audit or a guarantee against every malformed-input issue.
Local data is not encrypted
Section titled “Local data is not encrypted”Settings and conversations are local JSON under the user profile. The app does not provide at-rest encryption, account synchronization or a remote backup service. Protect the Windows account, disk and backup policy. Diagnostic exports can reveal hardware, paths, model metadata and runtime excerpts; review before sharing.
Bearer-like strings are redacted in the app’s log path, but upstream errors can contain other sensitive context. Do not treat a diagnostic ZIP or JSON as automatically public. These docs do not include private QA conversation databases, service keys or machine account credentials.
Future tools need stronger boundaries
Section titled “Future tools need stronger boundaries”MCP connectivity, tool execution, repository writes and browser access require explicit scopes, cancellation, audit events and recovery. Imported configuration must be inert until reviewed. Model text, retrieved documents and tool responses cannot change permissions.
The planned platform must distinguish read access, local writes, command execution, network operations and publication. A decorative “sandboxed” label is insufficient without an actual constrained environment. See agents and MCP/skills for the proposed gates.