Skip to content
MobilityOS
Start freeStart free

What MobilityOS stores, and what it does not

Privacy and non-storage of personal data: how the application guarantees that a customer's details are never saved anywhere.

Version 2026 Author Guilhem Normand Public document

Summary

This note answers one question: “How does the application guarantee that customer details are never saved anywhere?”

The answer is structural: the application acts as a digital mirror. What the customer types is reflected in real time on the advisor's screen. It passes through no server or database. Only the label shown in the queue passes through the coordinator, for the length of the wait. As soon as the session closes, the data disappears.

Mirror architecture

The transmission uses WebRTC (Web Real-Time Communication), a direct peer-to-peer connection standardised by the W3C.

Visitor's phone enters their details WebRTC channel, end-to-end encrypted DTLS · browser to browser server never on the form's path Advisor's screen displays in real time
The coordinator connects the two devices and holds the queue. The form itself never passes through it.

No intermediary server touches the content of the form. The branch coordinator knows only the queue: order of arrival, label shown, which desk takes the customer.

What's stored, and what never is

The ledger, line by line. Everything a customer enters is on the left; everything a branch licence requires is on the right.

Never stored
  • Customer's address, postcode, townnever recorded by us; the autocomplete queries Photon by Komoot from the phone
  • Phone and emailpeer-to-peer; sent to our delivery provider if the advisor triggers a verification, never recorded
  • Temporary address (hotel, Airbnb)same peer-to-peer channel
  • Customer's booking numberpeer-to-peer only, in the terminal's memory, cleared when the tab closes
Stored
  • Branch name (licence)in KV (not personal data)
  • Licence expiry datein KV (not personal data)
  • Date and version of Terms acceptancein KV, on the company account (legal record)
  • Front-desk console telemetryin KV, per site: device fingerprint, city and rounded location, 30 days; then undated totals

A company's account records its sites, staff, usage measurements and logs. The detail and retention periods are in the privacy policy.

Technical guarantees

4.1 No customer database

No function writes what a visitor types into the welcome form. A company's account records its sites, front-desk staff and usage measurements. This content is listed, with retention periods, in the privacy policy.

4.2 End-to-end encryption

WebRTC encrypts the data with DTLS. No intermediary node can read its content.

4.3 Ephemeral by design

What a visitor types lives only in the console's memory and disappears when the tab closes. None of it is written to the desk. On their own phone, only a draft of their entry stays in the tab, so a refresh does not wipe it. The queue is held by the branch coordinator: order of arrival and label shown, until the row is removed.

4.4 No log of the content

What a visitor types appears in no log: the form does not cross our servers. HTTP headers block caching of the welcome and console pages (Cache-Control: no-store). The usage measurements kept count gestures, under a fingerprint that changes every day. They are described in the privacy policy.

4.5 Email / SMS verification (optional)

To check a contact, the application can send the customer a confirmation email or an SMS with a link. The sending goes through a provider. The address or number is used only for that message: it is never written to a database. A temporary token (30 minutes) links the customer's click back to the session, then expires and disappears. On the advisor's side, the verification history stays in memory and clears when the tab closes.

The life cycle of a piece of data

An email address, from the first keystroke to the closing of the tab.

  1. The customer types their email.
  2. The script packages the data in memory.
  3. The object travels over the encrypted WebRTC channel, straight to the advisor.
  4. The advisor receives and displays the data.
  5. The form block leaves by no HTTP request: it only leaves the phone through the encrypted channel.
  6. When the tab closes, the advisor's screen is cleared: no copy of it exists. On the phone, the draft disappears with the tab.

Conclusion

  • Respects the GDPR minimisation principle (Art. 5.1.c).
  • No customer database: the form never touches a server.
  • Peer-to-peer channel, end-to-end encrypted.
  • Nothing a visitor types is written to storage. What the company account records there is listed in the privacy policy.

Code references

The files to read to verify this note, and what each one does.

  • functions/api/check-license.jsLicence check and form settings. Receives and writes nothing a visitor types.
  • functions/api/admin-agencies.jsLicence management. Writes only KV metadata.
  • functions/api/billing/terms.jsRecords the date and version of Terms acceptance
  • functions/api/turn-credentials.jsGenerates ephemeral TURN credentials
  • src/retailer/Advisor console. Legal notice displayed.

Guilhem Normand · 2026 · Public document

Back to home