Offline Does Not Mean Unprotected

FlyingMouse Format’s local-first design removes the need to upload a user’s files, but it does not remove the security problem. This chapter maps the project’s threat surface from the Electron renderer through the loopback API, download registry, temporary files, and conversion engines. The practical judgment is to distinguish defense in depth from certification: the controls reduce particular risks, while untrusted files, third-party components, unsigned packages, and legacy runtimes still require care.

What offline processing removes—and what it leaves behind

Local conversion removes a major external dependency. A document does not need to be sent to a remote service for FFmpeg, LibreOffice, OCR, PDF rendering, or structural extraction to process it. The project’s privacy policy says there is no account system and that file contents, settings, and logs are not uploaded to a cloud conversion service. The user chooses the final save location, while source and temporary conversion material remain on the machine.

That changes the threat model, but it does not make the input harmless. The application still accepts PDFs, Office documents, images, archives, audio, and other files from a user’s filesystem. Those files cross parsers and external engines that are necessarily more complicated than the visible mouse-themed interface. A malformed file can exercise a parser even when no network connection exists. A bundled engine can be missing, damaged, or old. A local API can expose the wrong path if its download and asset rules are too loose.

The right question is therefore not “Is it offline?” but “Which local boundary contains each capability, and what is allowed to cross it?” FlyingMouse Format’s security controls are arranged around that question. The renderer is not given general operating-system access. Navigation is restricted to the current loopback application. State-changing requests are checked for local origin. Downloads resolve through registered results. Asset names and paths are constrained. External links have a narrower rule than local result URLs.

Those controls do not prove that every parser or dependency is secure. They make the application’s own decisions more difficult to misuse and reduce the consequences of a mistaken assumption at one boundary.

The local threat surface has several layers

The application’s architecture can be read as a set of cooperating security boundaries:

classDiagram class Renderer class PreloadIPC class LoopbackAPI class DownloadRegistry class ExternalEngines class UserFilesystem Renderer --> PreloadIPC : narrow save request Renderer --> LoopbackAPI : same local origin LoopbackAPI --> DownloadRegistry : registers results LoopbackAPI --> ExternalEngines : dispatches conversion DownloadRegistry --> UserFilesystem : controlled save ExternalEngines --> UserFilesystem : temporary input/output

The Electron renderer is the first boundary. The window uses context isolation, disables Node.js integration, and enables sandboxing. This means the page’s JavaScript is not supposed to inherit unrestricted access to the host process. A preload layer exposes the limited interface needed for saving rather than making the entire Electron API available to the page.

Navigation is another boundary.