Security

1.Why this page exists

A recording of your voice, or a video of a classroom, is not the same as a shopping history. It is personal in a way that does not wash off, and it can contain other people who never signed up to anything.

So rather than a line saying we take security seriously, this page describes what is actually in place and what is not. The section on known weaknesses is the one that makes the rest of it worth reading.

2.Accounts and sign in

Passwords are never stored readably

A password is stored only as a modern one way hash. Nobody at VoxSign can read your password, recover it, or tell it to you, and a database disclosure would not reveal it.

Email verification is required

A new account cannot sign in until the address is verified with a one time code sent to it. That code expires. An unverified account is inert.

Sessions live in a protected cookie

The cookie that keeps you signed in is set by this site, marked HttpOnly so page scripts cannot read it, and is not sent to other sites. It is never passed to the processing service, which has no session store and no user table at all.

One person, one account

Signing in with Google and signing in with a password on the same verified address resolve to a single account. A provider is only ever linked when the email address on it matches and the provider has verified that address, which is what stops anyone attaching their own Google account to somebody else's VoxSign account.

Signing in with Google means we never handle that password

If you use Google, the password exchange happens with Google and we receive only the account identifier and the verified email address. We never see, hold or transmit your Google password.

3.Your recordings and sessions

Everything is encrypted in transit

All traffic between your browser, our services and our providers runs over HTTPS. Stored data is encrypted at rest by our database and object storage providers.

A session identifier alone gives you nothing

Requests for your account data and your learning sessions are authenticated by verifying a signed token against a published key set, and the account identity is taken from that token rather than from anything the request claims about itself. Every read and write of a session is then filtered by that identity, so knowing a session's identifier does not let anyone reach a session that is not theirs.

Uploads are validated on the server

The file type is confirmed by inspecting the file's own contents rather than trusting its name or the browser, and the size and duration limits are enforced server side. Client side checks exist only so the page can respond quickly; they are never what actually decides.

Deletion is ordered so nothing is orphaned

When a session is cleaned up, the stored video file is deleted first and its database record second, because that record is the only handle we have on the file. If the file deletion fails, the record is kept and the cleanup retried, so a recording can never survive in storage with nothing pointing at it.

Recordings expire automatically

Retention is a scheduled deletion in the software, not a policy someone has to remember to apply. The exact windows are in the privacy policy.

Errors do not leak internals

When something fails you are shown a written explanation, while the underlying technical detail goes only to our own logs. A failure message never contains a provider error, a file path or a stack trace.

Full detail on what is stored, who processes it and how long it lasts is in the privacy policy.

4.Weaknesses we know about

Published because a security page without this section is marketing.

• The API access token is readable by scripts on the page. The session cookie is protected from page scripts; the short lived token derived from it, which the app uses to call the processing API, is kept in ordinary browser storage and is not. A malicious script running on this site could use it until it expired. The short lifetime bounds that, and it is not the same as an open ended session. Set out in full in the cookie policy.
• No independent penetration test has been carried out. Our review is internal. We are a small team, and we are not going to imply otherwise.
• Your data is processed outside Uganda. Our hosting, storage, speech recognition and email providers are all abroad, so your data crosses borders and sits under other jurisdictions. Each one is named in the privacy policy so you can judge that rather than take a blanket assurance.
• A verification code in an inbox is a way into an account. That is true of every service that sends codes by email, ours included. Protect the email account itself, because it is the key to this one.
• We have no two factor authentication yet. Sign in is a password, or Google. If your Google account has two factor authentication enabled, signing in with Google inherits it, which today is the strongest option we offer.

5.Reporting a vulnerability

If you find a security flaw in VoxSign, please tell us before you tell anyone else, and we will not pursue you for having looked. We do not run a paid bounty programme; we will credit you if you would like to be credited.

How to report

• Email info@voxsign.co.ug with "security" in the subject line. Tell us what you found, how to reproduce it, and what an attacker could do with it.
• Please give us a reasonable period to fix it before publishing.
• Please do not access, modify or delete data belonging to anyone else, degrade the service for other users, or run automated scanning that amounts to a load test. Use your own account to demonstrate the issue.

We aim to acknowledge a report within two working days and to tell you plainly what we are doing about it, including if the answer is that we have decided to accept the risk for now and why.

6.What you can do

• Use a password you have not used anywhere else, and protect the email account it recovers through.
• Never share a verification code. We will never ask you for one, by email, by phone or in person.
• Sign out on a shared or public computer. That clears the session and the access token from that browser.
• Remember that anything you upload can contain other people. Get their agreement before you upload a recording of them.
• If you think your account has been accessed by someone else, email us and we will end every active session on it.