Security Overview
Xogogy Security Overview
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
xogogycommand 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
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.
| Host | Trigger | Data sent |
|---|---|---|
hymgrwerqxhvsergivrq.supabase.co | Activate or Deactivate this computer | Licence key, salted SHA-256 computer hash, operating system, app version |
| Same | Start of each publish or export; Check installed licence; xogogy publish | Licence id, computer hash. Offline or no answer: the publish continues on the offline check |
| Same | Send in Report a problem | Note, the context shown before sending, licence id, computer hash; screenshot and course file only if included |
reviewmyelearning.com | Publish to ReviewMyElearning; open or answer review comments; status polling while the Publish dialog waits (up to 10 minutes) | Package, title, course id and file name, comment replies, the user's API key |
xogogy.com | Help › Check for new beta; or at start-up, at most once a day, if the user turned that setting on (off by default) | A request for /beta/latest.json with only the Host, User-Agent and Accept headers; no course data, licence, version, computer identifier or cookie |
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 Functionand 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.