Loadout · Privacy

The short version

Loadout runs in the dispatcher's own browser. Driver names, emails and photos stay on that computer. What reaches this server is who our customer is — the DSP owner's contact details and the company's — a credential for each computer, and — if backup is on — an already-pseudonymised copy of the dispatcher's own working notes.

What this server stores

• Licence. The DSP company name, the plan, the expiry date, and how many computers are allowed. The licence is the owner's account: there is no shared licence key.
• The owner's account. The DSP owner's name, email and mobile number — the owner signs in with one code sent to that email and another texted to that mobile, and has no password — and the company's legal name, DSP code, station, business address and time zone. That is our customer, not their drivers: no driver is ever part of it. Sign-in codes are stored only as a keyed hash (HMAC) that a copy of the database alone cannot reverse, work once and expire after 10 minutes. Everything travels over HTTPS only; plain HTTP is refused, and no response is cached.
• Computers. A random UUID generated by the browser, the name the owner gives it ("Dispatch desk"), how it was added, the extension version and when it was last seen, plus the SHA-256 of its own credential. It is not a hardware identifier and it does not follow anyone between products. The owner sees this list and can remove any computer from it.
• Usage counts. How many times the extension checked its licence, saved a backup or asked the assistant a question. Counts only — never what was asked or what came back.
• Backup, if enabled. The dispatcher's own working notes, with every person reduced to a one-way hash of their work email before anything leaves the browser. Names, phone numbers, Transporter and provider IDs, photos and private notes are deleted at that boundary, not masked — a masked name is still a name. All of it, and nothing else:
  • Attendance marks, and the rules used to score them.
  • The Amazon scorecard rows the dispatcher imported, and how weeks are blended together.
  • The write-up record: who is at which step, for which week, and the counted reasons behind it. Never the letter that was sent, and never the dispatcher's private note — those stay on the computer.
  • Fleet records. Vans, not people.
  • The payroll import, with legal names, phone numbers and licence details taken out at the source.
  • The pad board — sides, groups, letters and two times. The only one with no people in it at all.

What this server never receives

• Driver names, emails, phone numbers or Transporter IDs. They are replaced at the source. The server cannot tell who a given identifier belongs to; only the dispatcher's browser can.
• Any Amazon credential. Loadout reads Amazon inside the dispatcher's own logged-in session. It never stores, proxies or transmits a password or a session cookie.
• Damage photos. They stay on the computer that took them.
• The conversation with the assistant. It is kept in the browser. This server passes each question through and keeps no copy of it. The assistant itself keeps a thread — see below.

The assistant

Questions are relayed to a language model to be answered. Because the context is pseudonymised before it leaves the browser, the model sees P07, not a person. Answers come back with the same identifiers and the extension puts the names back on screen, locally.

So it can follow a conversation from one question to the next, the assistant keeps a thread, held under an identifier derived from the licence — never from a person. That thread is the one thing tied to a DSP that lives outside the database described above, which also means that deleting the database does not remove it. It is removed separately, on the same request. We would rather write that here than leave it for someone to find.

Other services, and what leaves the browser for them

• Email and text messages for signing in. The owner's two sign-in codes are sent from Loadout's own accounts: email through Cloudflare, text messages through Twilio. They carry a six-digit code and nothing else.
• Sling. Loadout uses the DSP's own Sling account through Sling's official API, with a token the DSP pastes into Settings. The token is stored encrypted and is never shown back — not even to the DSP, who can only be told whether one is set. Loadout reads the roster, and writes a shift only after the dispatcher confirms that exact shift.
• Google or Twilio, for write-ups. When a write-up is sent to a driver it goes out through the DSP's own Gmail or Twilio account, straight from the browser. It deliberately does not pass through this server: the letter carries the driver's name, email or phone, and this server is built not to see those. One click, one confirmation, one message — nothing is sent in bulk and nothing is sent on its own.

Amazon

Loadout reads and writes only inside the DSP's own authenticated session, with the DSP's consent, and every write is confirmed by the dispatcher first — nothing is sent to Amazon automatically. The extension does not attempt to disguise itself or evade detection of any kind.

Keeping and deleting

Usage counts are kept for 12 months. The backup is kept while the licence is active.

A DSP can ask for everything tied to its licence to be deleted — the backup, the usage counts, the list of computers, the owner's account, the stored settings and the licence record itself — and it is removed. The procedure is written down, step by step, so that the request is answered the same day instead of improvised, and so that anyone can check it was done. The assistant's thread, described above, is removed in the same pass.

Loadout · Last updated 2026-09-29