Data and Privacy¶

What leaves the machine, where it goes, and who decides.

This page exists because RevLearning's entire job is reporting what a learner did to a system that records it. That makes "what data moves" a design question rather than a footnote, and in learning and development it is usually the first question procurement asks.

Short version. RevLearning sends nothing anywhere on its own. It transmits only what your content tells it to, only to endpoints you configure, and it has no telemetry, no analytics and no connection to RevGaming of any kind.

RevLearning does not phone home¶

There is no usage reporting, no licence check, no crash reporting, no analytics and no update ping. The package contains no RevGaming endpoint, and no endpoint belonging to anyone else.

The only external URLs anywhere in the runtime are XML namespace identifiers in the SCORM manifest builder — adlnet.org and imsproject.org schema names. They are identifiers written into a file, not addresses that get fetched. A build with no network access produces an identical package.

This is checkable rather than promised: search the package for http and those three namespace strings are what you will find.

SCORM: data goes to the LMS that launched the course, and nowhere else¶

SCORM has no network layer. The runtime talks to the JavaScript API object the LMS puts in the parent window, and the LMS does whatever it does with the values. RevLearning never opens a socket.

What your content can send, if it asks to: completion status, success status, score (raw, min, max and scaled), lesson location, suspend data, objectives, interactions, and session time.

What RevLearning reads back, because the standard provides it and courses need it: the learner id and name the LMS reports, entry state, credit, mode, mastery score and any suspended state from a previous session.

Interactions are the one to think about. cmi.interactions records a learner's individual answers — what they picked, whether it was right, how long they took. That is assessment data about a person, it is the most sensitive thing the SCORM data model carries, and nothing records it unless your content calls the API that records it. If you do not want per-question answers in the LMS, do not write interactions.

The destination is entirely determined by where the course is hosted. You are not introducing a new data processor by using RevLearning; you are reporting to the LMS you already chose.

xAPI: data goes to the endpoint you configure¶

xAPI does use the network. UnityWebRequestXApiTransport POSTs statements to the LRS endpoint set in XApiEndpointConfig or supplied at runtime. That endpoint is yours. RevLearning ships with https://example.com/xAPI/statements as a placeholder, which fails loudly rather than sending anywhere real.

Statements can carry learner identity. An xAPI actor is commonly an email address (mbox) or an account identifier, and XApiActor.FromLmsLearner builds one from the learner the LMS reported — which is the right behaviour, because the alternative is reporting progress against an identity you invented. It also means a name and an email address are going over the wire to your LRS.

If you need pseudonymous reporting, construct the actor yourself with an opaque account identifier instead of calling FromLmsLearner. Nothing in the package requires a real identity; it just will not fabricate a fake one on your behalf.

Your LRS is a data processor and RevLearning is not. Whatever agreement governs that LRS is the agreement that governs this data. We never see it.

Undelivered xAPI statements are stored on the device¶

This is the part worth knowing before a privacy review, because it is not obvious from the feature list.

xAPI delivery is queued, so a statement survives a flaky connection and a closed tab. Surviving a closed tab means it is written to local storage: PlayerPrefs, which is the registry on Windows, a plist on macOS, and IndexedDB on WebGL.

It is base64-encoded and not encrypted. Base64 is a transport encoding, not a protection measure, and anyone with access to that storage can read the pending statements — actor identity included. Treat the device as able to see anything the queue is holding, because it can.

Two consequences:

• Flush at natural pauses. FlushPendingAsync exists partly for this. PendingStatementCount tells you whether anything is waiting, and ClearPendingStatements discards it. A short queue is a smaller exposure and also avoids WebGL's roughly 1 MB shared storage budget.
• On a shared machine, the queue is scoped per learner. The storage key carries a hash of the actor, so one learner's undelivered statements are not restored into the next learner's session and sent under their identity. This was a real defect before 1.0 and the fix is specifically about the kiosk and shared-classroom case. Statements queued before the identity is known are adopted into the learner's scope once it is; statements belonging to a previous learner are deliberately left behind rather than inherited.

Credentials¶

XApiEndpointConfig has username and password fields for HTTP Basic Auth, because that is what most LRS sandboxes accept.

Anything typed into those fields in the Inspector is serialized into the build in clear text and is readable by anyone who downloads it. This is a property of Unity serialization, not a RevLearning choice, and it is why those fields exist for development rather than for production.

For production, leave them blank and call SetRuntimeCredentials at launch — from an LMS launch parameter, a fetched short-lived token, or a backend proxy that holds the real credential and never ships it. A WebGL build is a public download; treat anything inside it as public.

The generated runtime config¶

RevLearning_RuntimeConfig is written from Project Settings so the runtime can read settings that are otherwise editor-only. It holds course and SCO titles, behaviour flags, and the xAPI endpoint and default actor name and email.

Those actor defaults are sample values for development. They ship as Unity Learner and learner@example.com, and a real person's details typed there would be baked into the build like any other asset. Supply real identity at runtime, from the LMS, rather than storing it in the project.

What this page is not¶

It is not legal advice, and it is not a DPIA. It describes what the software does so that whoever is responsible for your learners' data can make a decision with accurate information. The questions it cannot answer — what your LMS retains, where your LRS is hosted, what your lawful basis is, how long records live — are properties of your deployment, and RevLearning has no visibility into any of them.

If something here is unclear or looks wrong against the code, the code is the authority and we would rather hear about it.