Security Overview

Xogogy Security Overview

GForce Learning Corp · November 2026 · Checked against the Xogogy source of 5 November 2026 · xogogy.com/trust

Summary

Xogogy is a desktop app for Windows and macOS that builds e-learning courses, imports existing ones and publishes them as SCORM, xAPI, cmi5 or web packages. Courses are stored and edited on the customer's computer. The app has no cloud workspace, no user accounts, no telemetry and no AI model. It makes network calls only to GForce Learning's own services, and only when the user starts an action that needs one. Published courses contain no code from third parties and make no calls to GForce Learning.

Architecture

  • Desktop app. A Tauri 2 application: a native shell written in Rust, and an editor that runs in the operating system's web view (WebView2 on Windows, WebKit on macOS). The editor reaches the computer only through a fixed list of native commands available to the main window. Its content security policy allows connections only to the app itself, and loads scripts, images, media and fonts only from the app and the open project.
  • Projects. A course is a folder on the user's disk: one JSON course file in the open Common Course Format, its media, and its history. Every save is checked against the format's schema and a semantic validator.
  • Operations layer. One shared layer makes every change to a course, whether it comes from the editor, the command line or an AI assistant. Each batch of changes is validated before it is saved; an invalid batch is rejected and nothing changes.
  • Command line and MCP server. A xogogy command line and an MCP server let the customer's own AI assistant read and change courses. The MCP server runs on the customer's computer over standard input and output.
  • Player. The player that ships inside every published course is our own code, with zero runtime dependencies. It renders accessible HTML.
  • Our services. A licence service and a problem-report service, run as Supabase Edge Functions with a Postgres database and private file storage in the United States (US East). ReviewMyElearning, our course review service, is a separate GForce Learning product.

Data flow

Xogogy data flow The customer's computer holds the app, the project folders and the customer's AI assistant. The app sends user-started HTTPS requests to the licence service, ReviewMyElearning and the product website. Published packages go to the customer's LMS, which serves learners and receives tracking data. The AI assistant's own provider is outside our control. Customer's computer Xogogy app Editor in the system web view Native shell (Rust) Operations layer, validator Publisher: SCORM, xAPI, cmi5, web Keys in the OS credential store Project folders course file media history MCP server, command line stdio to the assistant user-only pipe or socket to the open app, session key Customer's AI assistant chosen and paid for by the customer No TCP or UDP listener. No telemetry. No AI inside the app. Licence and report service Supabase, US East activate, publish check, report ReviewMyElearning publish for review, comments xogogy.com beta check: one public file HTTPS, user-started only Customer's LMS or LRS package uploaded by the customer; learners play it, tracking returns here Assistant's provider customer's own agreement
Solid green arrows are the only requests the app makes. The dashed arrow to the LMS is a package the customer uploads. Traffic between the assistant and its provider is outside Xogogy.

Network calls

Every call is an HTTPS request from the native shell to an address compiled into the app, with the operating system's TLS and certificate store, no redirects, no cookies, a timeout and a cap on the reply size.

Nothing else: no start-up call unless the beta setting is on, no background call and no licence check-in. The MCP server makes no network request. The command line's one request is the publish-time licence check. Help links open in the user's own browser. On Windows computers without the WebView2 runtime, the installer downloads it from Microsoft.

Threat model in brief

  • Hostile course files. Imported files are parsed as data. Importing, editing, the command line and assistant tools never run a course's scripts or actions. Our lint rules forbid eval, new Function and raw HTML injection in the shared packages.
  • The scripts rule. A course's own JavaScript runs only where its learners see it: in the published course, in the learner's browser. In Preview it runs inside an isolated frame with no access to the app, the project files, storage, pop-ups or web requests; a script there can still open a WebRTC connection, a limit we accept and disclose. The author can switch scripts off in Preview, and a course can switch them off everywhere.
  • Other programs and users on the computer. The live assistant channel is a named pipe with an access list for the current user only, refusing remote clients (Windows), or a socket in a private folder (macOS). A connection must present a 32-byte random session key, compared in constant time and replaced at every start. There is no TCP or UDP listener.
  • Assistant mistakes. Assistants change courses only through the operations layer: each batch is validated, labelled with its author and undoable in one step. Tools read files only from the project folder and the image paths the user allows.
  • Secrets. The licence key and the ReviewMyElearning key live in Windows Credential Manager or the macOS Keychain. No command returns them to the editor.
  • Licence tampering. The licence file is signed with Ed25519 and checked offline against a public key built into the app; newer licence files are bound to one computer's hash. A file that fails the check is never installed.
  • Our services. Database tables are closed to public access and readable only by our service functions. Report files go straight to private storage buckets through single-use signed upload links. Attached course files are deleted after 30 days.

Supply chain

  • The player shipped in every course has zero runtime dependencies.
  • Rust dependencies of the native shell are pinned to exact versions and locked; JavaScript dependencies are locked, and builds install from the lockfile without changes.
  • HTTPS uses the operating system's TLS stack and trust store; no certificate bundle ships with the app.
  • An automated test fails the build if a private key or key file is committed. Signing keys are kept outside the source repository.
  • macOS builds are signed with our Developer ID and notarised by Apple; the build fails unless the signature, Gatekeeper assessment and stapled ticket all verify. Windows builds are not code-signed yet.
  • There is no automatic updater. Users download new builds from xogogy.com and install them.
  • Third-party software notices ship with the app.

Vulnerability handling

Report to security@xogogy.com, also listed in /.well-known/security.txt. We confirm every report within three business days, keep the reporter informed until the fix ships, and credit them if they wish. Good-faith research that follows the rules on our trust page is welcome.

Roadmap

These are plans, not current capabilities.

  • Windows code signing through Microsoft's Azure Artifact Signing, under our company name.
  • Signed in-app updates, with each update checked against our update-signing public key before it installs.
  • A software bill of materials (SBOM) published with each release.
  • An independent penetration test of the app and our services, with a summary available on request.
  • An accessibility conformance report (VPAT) for the editor and the published player.

Xogogy holds no SOC 2 report or other certification today. Questions: security@xogogy.com.