Source-linked AI summary
The Web-CLI: Verifiable Privacy for Tools, Models, and Inference Engines in the Browser
Tejaswi Gowda
TL;DR
Web-based tools often require sending sensitive user data to remote servers, while existing powerful command-line capabilities remain difficult for non-technical users to access. The paper defines Web-CLI, implements it across four computational domains, and reports a locally executed architecture whose zero-egress behavior is independently verifiable. It concludes that this pattern can preserve capability and improve access, although browser memory and performance limits constrain some workloads.
Problem
Powerful command-line tools are difficult for most users to install and operate, while cloud browser tools can expose sensitive data to third parties.
Method
The paper defines Web-CLI as a browser architecture combining full-capability local engines, progressive disclosure, offline-first operation, and zero egress.
Results
Four reference implementations span deterministic media processing, speech recognition, language-model inference, and geometry processing with a physical output, with early anecdotal signs of independent reuse.
Takeaways & Limitations
Web-CLI makes privacy independently verifiable through client-side execution while preserving access to powerful computational capabilities through accessible interfaces.
Takeaways & Limitations
Browser memory and single-threaded encoding constrain large or computationally intensive workloads, and independent adoption evidence remains anecdotal.
Abstract
from arXiv · showhide
We introduce the Web-CLI, a novel application architecture deploying powerful computational capabilities (command-line tools compiled to WebAssembly, models run through client-side inference runtimes, and GPU-accelerated engines) as zero-install, offline-capable browser applications that preserve full underlying capability. Unlike web-based alternatives that require server-side processing and expose user data to third parties, Web-CLI applications execute entirely on the client, providing a verifiable privacy guarantee by architecture rather than policy. We define the pattern and its four properties: fidelity, progressive disclosure, offline-first, and zero egress. We present four reference implementations across distinct domains: ffmpeg-webCLI, a browser-based video editor built on FFmpeg; whisper-webCLI, speech transcription via Transformers.js; chat-webCLI, WebLLM-based language model inference; and 3mf-webCLI, a deterministic tool segmenting 3D models into multi-material files for physical 3D printing. Together they demonstrate that the pattern generalizes across deterministic media processing, neural speech recognition, LLM inference, and geometry processing with a physical output, and we outline how it extends to AI-native interfaces in which a local language model becomes the command surface itself. We further report early, anecdotal signs of independent reuse by third-party tools, suggesting the pattern generalizes beyond its reference implementations. We evaluate the primary implementation against native FFmpeg on performance and feature parity, and argue that progressive disclosure lowers the barrier for non-technical users. We argue that for applications processing sensitive user data (medical, legal, journalistic, or personal), the Web-CLI should be the default architecture, as it makes data locality an independently verifiable technical property rather than a policy promise.
1 Introduction
The paper introduces Web-CLI as a zero-install browser architecture that preserves powerful local computation while making privacy independently verifiable. It defines the pattern, demonstrates it across four implementations, and argues that progressive disclosure broadens access without sacrificing capability.
- Motivation: Cloud-based browser tools expose sensitive files to third-party servers, whereas Web-CLI processes them locally without making privacy depend on policy.The motivation includes medical, legal, journalistic, personal, and intimate media.
- Architecture: Web-CLI combines fidelity, progressive disclosure, offline-first operation, and zero egress in a browser-based architecture.The underlying capability remains available through graphical and raw control surfaces, while user data stays on-device.
- Reference implementation: ffmpeg-webCLI exposes more than 30 video operations alongside raw FFmpeg command mode, with no installation, account, or network access after initial asset caching.The browser application runs across modern operating systems and preserves access to arbitrary valid FFmpeg arguments.
- Generality: Four reference implementations span deterministic media processing, speech recognition, language-model inference, and geometry processing for physical 3D printing.The paper also reports local multi-stage pipelines, early anecdotal third-party reuse, and an AI-native direction.
- Evaluation and implication: The paper evaluates FFmpeg against native implementations and argues that progressive disclosure lowers the barrier for non-technical users.Its broader claim is that sensitive-data applications should consider Web-CLI because privacy becomes a technical guarantee rather than a policy promise.
2 Related Work
Related work establishes that browser deployment of substantial systems is feasible, but identifies a gap in full-capability, privacy-preserving client-side interfaces for CLI tools. Web-CLI extends local-first and end-user interface traditions by combining on-device execution with zero installation.
- WebAssembly and browser systems: WebAssembly enables C, C++, and Rust systems software to run in browsers, with Emscripten supporting ports such as SQLite and FFmpeg.Prior work reports viable production deployments and analyzes WASM performance relative to native code.
- Browser-based processing: Cloud video editors process files on remote servers, introducing upload latency, infrastructure dependence, and privacy risks for sensitive content.The cited academic web-media literature has largely focused on delivery and streaming rather than privacy-preserving client-side processing.
- Prior FFmpeg work: ffmpeg.wasm demonstrated browser execution of FFmpeg but did not provide the user-interface layer or articulate a broader architectural pattern.The paper positions Web-CLI as an abstraction and full reference implementation built on that foundation.
- Privacy-preserving computation: Cryptographic privacy techniques provide powerful protections but impose computational overhead that is ill-suited to media-processing workloads.The paper distinguishes these approaches from client-side computation as a practical privacy mechanism.
- Local-first software: Web-CLI instantiates the local-first principle specifically for deploying existing CLI tools through WASM while preserving their capability.This connects local data residence with browser-based tool deployment.
- End-user interfaces: GUI wrappers have broadened access to powerful tools, and Web-CLI extends that tradition by removing the installation barrier entirely.The interface tradition motivates combining accessibility with full underlying power.
3 The Web-CLI Architecture
The Web-CLI architecture deploys full-capability computation locally through layered interfaces, cached assets, and in-memory execution. Its privacy guarantee is architectural and inspectable, while suitability remains constrained by browser memory, binary size, and computational performance.
- 3.1 Definition: A Web-CLI deploys a powerful computational capability on-device while satisfying fidelity, progressive disclosure, offline-first, and zero-egress properties.The pattern applies to WASM tools, client-side model runtimes, and GPU-accelerated engines.
- 3.1 Definition: Fidelity preserves the underlying engine’s full capability through arbitrary tool arguments or direct model inference parameters.The raw control surface coexists with graphical controls rather than replacing them.
- 3.1 Definition: After initial loading and asset caching, offline-first applications require no server round-trip; large model assets may instead satisfy zero-egress-after-load.The distinction accounts for assets that are impractical to pre-bundle.
- 3.1 Definition: The architecture is substrate-agnostic, spanning WASM binaries, JavaScript/ONNX inference, WebGPU runtimes, and deterministic JavaScript geometry pipelines.What unifies these systems is local capability, layered control from presets to raw parameters, and enforced zero egress.
- 3.2 Architecture Overview: The GUI maps common controls to engine arguments or inference settings, while raw interfaces and example templates preserve direct control and teach complex invocations.A Web Worker separates computation from the main UI thread, and an in-memory virtual filesystem handles inputs and outputs.
- 3.3 Suitability Criteria: Browser memory typically limits WASM applications to 2–4 GB, making whole-input processing and memory-hungry operations less suitable.Streaming tools such as FFmpeg handle this constraint more gracefully than tools requiring the entire input in memory.
- 3.3 Suitability Criteria: Binaries under ∼50 MB are practical, while larger binaries require lazy loading, streaming compilation, and clear communication about initial load time.The binary must be downloaded before the application can function.
- 3.3 Suitability Criteria: WASM’s performance gap can reach 25–33× versus multithreaded software x264 and 72–90× versus hardware-accelerated native encoding for single-threaded H.264 re-encoding.The paper reports smaller 1.3–1.4× gaps for operations that are single-threaded natively, so suitability depends on operation type and clip length.
4 Reference Implementation: ffmpeg-webCLI
ffmpeg-webCLI brings FFmpeg’s broad capabilities into a zero-install browser application while preserving raw command access and supporting progressive disclosure. Its client-side, offline-capable design strengthens privacy, though current WASM memory and single-threaded performance impose important limits.
- Feature Set: ffmpeg-webCLI exposes 30+ FFmpeg video operations through graphical controls while preserving raw command access and 13 example recipes.The application also provides media inspection utilities and live previews of exact commands.
- Progressive Disclosure: Its three-level interface progresses from constrained preset controls to curated command templates and arbitrary FFmpeg arguments.This design lets users perform common operations without syntax knowledge while retaining the underlying tool’s control surface.
- Architecture: Client-side execution uses a static application, Web Worker isolation, and an FFmpeg WebAssembly core, with a multi-threaded build available as a drop-in upgrade.The deployed core is single-threaded with SIMD enabled; cross-origin isolation headers support the multi-threaded alternative.
- Composition: The application composes trimming, multi-input processing, browser APIs, and local Whisper transcription into multi-stage video workflows without network transfer.For auto-captioning, FFmpeg extracts audio, Whisper transcribes it, and FFmpeg muxes edited subtitles back into the video.
- Offline and Privacy: Installed PWA operation provides active offline-first behavior and removes ambient network connectivity during processing.This is presented as a stronger privacy condition than an online browser tab whose application itself makes no requests.
- Limitations: Hard subtitle burning lacks native libass support, so Canvas-rendered caption images provide a workaround without advanced karaoke effects or complex positioning.The limitation applies to the standard ffmpeg.wasm build.
- Limitations: Processing remains bounded by approximately 2 GB of practical WASM memory, while H.264 re-encoding is 25–33× slower than multithreaded x264 and 72–90× slower than hardware-native encoding.Short re-encodes remain practical, but large or memory-intensive jobs can fail and long re-encodes are currently impractical without faster execution paths.
5 Case Studies
The case studies apply Web-CLI principles to speech recognition, local language-model inference, and geometry processing. Together they show reuse across components and substrates, while AI-native extensions introduce a fidelity challenge for locally generated commands.
- Whisper: Speech Recognition: whisper-webCLI provides local Whisper transcription with model, language, decoding, translation, and output-format controls under the Web-CLI pattern.It supports approximately 99 languages and exposes both simple transcription and advanced inference parameters.
- Whisper: Speech Recognition: The same self-contained Whisper module powers standalone transcription and ffmpeg-webCLI auto-captioning, demonstrating component-level reuse.This reuse spans distinct applications rather than only whole reference implementations.
- Local LLM Inference: chat-webCLI runs language-model inference entirely client-side through WebLLM and WebGPU, achieving inference speeds that approach dedicated local LLM runtimes.Its zero-egress-after-load variant accommodates model weights ranging from approximately 1 GB to 8 GB+.
- Local LLM Inference: Local LLM inference keeps prompts and their potentially revealing cognitive content on the device by construction.The paper contrasts this exposure with remote processing of files or spoken words.
- 3D Geometry Processing: 3mf-webCLI extends Web-CLI from media and inference to deterministic geometry processing that produces multi-material packages for physical 3D printing.It converts GLB models into 3MF packages with printer-appropriate material palettes.
- Toward AI-Native Web-CLIs: AI-native Web-CLIs replace hand-written intent-to-argument mappings with local language-model generation of commands or code.The proposed direction preserves zero egress but raises fidelity concerns because small local models may invent invalid calls or arguments.
- Toward AI-Native Web-CLIs: The proposed response to unreliable command generation is a bounded generate, validate, execute, observe, fix loop grounded in locally indexed APIs and application state.Static validation rejects hallucinated calls before execution, while local retrieval and runtime grounding constrain generation.
- Comparative Analysis: Across the implementations, the pattern spans WebAssembly binaries, JavaScript/ONNX inference, WebGPU runtimes, and JavaScript geometry pipelines.The comparison is framed around substrate-agnostic properties rather than a literal command-line implementation.
6 Evaluation
The evaluation compares ffmpeg-webCLI with native FFmpeg on performance, total time-to-result, feature parity, usability claims, independent uptake, and zero-egress behavior. Results show strong parity for many operations and verifiable local processing, while re-encoding performance and usability evidence remain bounded.
- Performance Evaluation: The benchmark compares ffmpeg-webCLI with native FFmpeg across 60-, 150-, and 600-second 1080p H.264 clips under software and hardware-native conditions.Each cell reports medians from repeated runs, with identical FFmpeg arguments and controlled execution conditions.
- Performance Evaluation: 0.5–1.0× WASM-to-native ratios occur for stream-copy operations, while single-threaded operations are 1.3–1.6× slower.The results attribute near-parity stream-copy performance to in-memory virtual-filesystem behavior and modest overhead for single-threaded work.
- Performance Evaluation: H.264 re-encoding is 25–33× slower than software x264 and 72–90× slower than VideoToolbox hardware encoding.The dominant factor is that the deployed WASM core is single-threaded while native x264 uses all ten cores.
- Total Time-to-Result: Local processing eliminates upload, queue, and download stages, making stream-copy and short-clip operations competitive while long re-encodes remain slower but predictable.A 60-second compress takes about 5.4 minutes locally, whereas a 10-minute compress takes about 45 minutes and will often lose end-to-end to a fast cloud pipeline.
- Feature Parity: Every tested preset and command recipe produced output equivalent to native FFmpeg, except for documented subtitle and memory-bound cases.Stream-copy outputs were identical; re-encoding outputs were perceptually equivalent, while hard subtitle burning used a Canvas workaround and some 1080p operations exhausted memory.
- Accessibility and Progressive Disclosure: The paper makes a design argument for accessibility rather than claiming an empirical usability result, using progressive disclosure to serve novices and experts.A graphical layer supports common tasks while the raw command surface preserves full capability; controlled task-completion studies remain future work.
- Independent Adoption: Early third-party reuse is reported as anecdotal evidence that the pattern is reproducible, while rigorous adoption measurement remains future work.Some adopters retain client-side execution and no upload or account but relax the stricter zero-egress discipline.
- Zero-Egress Verification: Zero outbound requests were observed during processing; network access occurred only during initial loading of the WASM binary and JavaScript.The complete operation set was monitored with Chrome DevTools Network.
7 Discussion
The discussion presents Web-CLI as a web-native, cross-platform architecture whose capabilities expand with browser APIs, while retaining local execution across diverse tools and domains. It supports a strong default-architecture claim for sensitive data, but performance, memory, trust, licensing, and deployment constraints remain.
- Web-Native Capabilities: Web-CLI applications inherit browser capabilities for GPU compute, hardware access, file handling, background computation, and real-time processing without installation or platform-specific code.Relevant APIs include WebGPU, Web Serial, Web Bluetooth, WebRTC, WebSockets, File System Access, Web Workers, IndexedDB, and Web Audio.
- Web-Native Capabilities: WebGPU enables on-device neural inference on desktop and mobile browsers, including 56-minute Whisper transcription in 5 minutes on an M1 laptop and 13 minutes on Android.The Android run used roughly 1% battery and remained entirely on-device.
- Reach and Distribution: A single Web-CLI codebase can provide GPU acceleration and standalone installation across desktop, Android, and iOS, including iOS delivery without the App Store.These benefits arise from the Progressive Web App and web-platform standards rather than platform-specific installers.
- Generalizability: The four case studies span CPU/WASM and GPU/WebGPU substrates, deterministic and neural computation, on-screen and physical outputs, and multiple privacy threat models.The authors report early anecdotal independent reuse as further evidence that the pattern extends beyond their implementations.
- Privacy and Deployment: The authors argue that Web-CLI should be the default for applications where third-party disclosure would meaningfully violate privacy.The burden of justification is placed on server-side processing, while client-side processing provides a technical guarantee within the stated architecture.
- Privacy and Deployment: Client-side processing has little or no performance cost for stream-copy edits, audio extraction, light transcoding, and short clips, while heavy re-encoding remains the exception.The discussion contrasts this scope with the higher costs of heavier workloads.
- Privacy and Deployment: Static hosting, cached heavy assets, and client-side computation make marginal user cost effectively zero, although hosting and CDN quotas prevent literal zero cost.The model is presented as scaling independently of per-user processing demand within those operational limits.
- Limitations: The main boundaries are a 31 MB initial load, a practical 2 GB WASM memory ceiling, supply-chain trust in the deployed binary, and FFmpeg codec licensing complexity.These limitations affect usability, large-file workflows, adversarial privacy models, and commercial deployment respectively.
8 Future Work
Future work targets broader applicability, lower porting effort, stronger performance, and more formal privacy guarantees. The paper also identifies GUI-native applications as an unresolved extension of the pattern.
- GUI-Native Extensions: Whether Web-CLI extends to fundamentally GUI-native tools remains open because such tools require interface replacement or emulation, plugin support, and scripting-runtime porting.GIMP is proposed as the most compelling test case.
- GUI-Native Extensions: A GIMP Web-CLI could either compile the full GTK interface to WASM or replace it with a web-native interface exposing batch processing and Script-Fu.The two approaches correspond to full fidelity and progressive replacement.
- Performance: WebGPU acceleration and a desktop wrapper using native hardware encoders are proposed paths for narrowing the performance gap with native execution.The current browser-based media-processing path is described as CPU-bound.
- Tooling: A reusable toolkit covering Emscripten builds, JavaScript APIs, UI components, and fidelity testing could lower the currently high and undocumented porting effort.The authors intend to develop such a toolkit.
- Privacy Verification: Formal privacy work should model supply-chain attacks on WASM binaries, malicious CDN delivery, and browser-extension interference.The current zero-egress guarantee is characterized as informal for adversarial settings.
- Evaluation and Roadmapping: A systematic survey of widely used CLI tools could assess Web-CLI suitability and identify engineering barriers to porting.The proposed survey would provide a roadmap for future implementations.
9 Conclusion
The Web-CLI deploys powerful computational capabilities as zero-install, offline-capable browser applications and defines privacy through client-side execution. Across four implementations, it demonstrates broad applicability while preserving capability and exposing important FFmpeg performance and memory boundaries.
- Architecture: The Web-CLI deploys command-line tools, client-side models, and GPU-accelerated engines as zero-install, offline-capable browser applications.Its defining properties include fidelity, progressive disclosure, offline-first operation, and zero egress.
- Generality: Four reference implementations span deterministic media processing, neural speech recognition, large language model inference, and geometry processing with a physical output.Early anecdotal signs of independent reuse further suggest that the pattern generalizes beyond the reference implementations.
- Evaluation: ffmpeg-webCLI exposes 30+ FFmpeg operations while preserving full command-line access and output parity with native FFmpeg for the evaluated operation set.The disclosed exceptions are hard subtitle burning and two memory-bound 1080p cases: VP9 encoding at any length and GIF conversion of a 10-minute clip.
- Evaluation: Performance ranges from native parity on stream-copy and audio operations to 25–33× slower than multithreaded software execution.The comparison concerns the primary ffmpeg-webCLI implementation against native FFmpeg.
- Privacy: Client-side execution makes privacy an independently verifiable and architecturally enforced technical property rather than a policy commitment.The conclusion presents this guarantee as especially significant for applications processing sensitive personal data.
- Conclusion: The browser is presented as a universal runtime that the Web-CLI makes privacy-preserving.