Security
We built PIToolkit so we can't read your case files.
Your cases, evidence and messages are encrypted in your browser with keys we don't hold. This page lists what reaches our servers, what doesn't, what our staff can't do, and where the limits of this design are.
On this page
How it works
Encryption happens on your device, not on ours.
Most case-management software encrypts your data with keys the vendor holds, so the vendor's systems can open it when they need to. PIToolkit is built the other way round.
Your browser
Your keys
Case content in plain text
Your key is made in your browser
Your browser turns your password into two separate things: a sign-in credential, and your encryption key. The key stays in your browser. Our servers keep only a scrambled form of the sign-in credential, and hold neither your password nor your key.
Case content is encrypted before upload
Names, notes, contacts, reports, messages, evidence files and their capture details are encrypted in your browser before anything is sent.
PIToolkit servers
Ciphertext we can't open
+ the operational details listed below
Our servers store ciphertext
What we hold is encrypted data we can't open, plus the operational details listed below, which the product needs to run your account.
People you share with
Decrypt it on their own device
Only the people you share with can open it
Clients you invite get their own keys. What you release to a client is encrypted to their key, and reports and messages are signed by the sender so each side can check who sent them.
What we can see
What our servers can read
How this list is kept honest. Today it's maintained by hand from the product's own field-by-field disclosure. A build test that fails whenever a new server-readable field appears without a line on the list is being built In development. When it lands, the disclosure is generated from it.
- Your account basics.
- The email you sign in with, when you accepted our terms and which version, when you confirmed your licence, and your plan.
- Your firm branding and workspace defaults.
- Your logo, colours and business name, which the product prints on portal pages, reports and emails, plus your default billing rate, default case type and time zone.
- Details about records, not their content.
- Which account a record belongs to and when it was created or changed. For a case: its type (surveillance, background check and so on), phase, case reference and dates. For a contact: their role (client, subject, witness and so on). For an evidence file: its type and size. For a message: who sent it and when.
- Time entries' dates, durations and billing rates, and when a timer started and stopped.
- This is the main exception to encryption today; the description of the work is encrypted. Moving these into encrypted fields is Planned.
- Client email addresses.
- The address you send a portal invitation to, so we can deliver it, until the client accepts. After that, it's the address your client signs in with. Client names are not sent to us.
- Sign-in and security records.
- For each signed-in session, the IP address and a description of the browser; a keyed fingerprint of account, browser and network, so we can warn you about a sign-in from a new device; and your security log: that an action happened, what kind, on what kind of record, and when. It carries no case content.
- Product usage.
- Which parts of the product were used, such as pages, features and reaching a plan limit. Individual events are kept for about 90 days, then combined into daily totals per workspace. No analytics company, tracking script or advertising network anywhere in the product.
- Support requests.
- Anything you write in a support request; our support staff can read it. Don't put case details in one.
- What every web service sees.
- The IP address you connect from, and the size and timing of what you upload and download.
What we can't see
Because it never reaches us unencrypted
- The names of your clients, subjects and contacts
- Case names, descriptions and notes
- Evidence files, their filenames, and their fingerprints
- Where, when and on what device a piece of evidence was captured
- The text of your reports
- Your messages with clients
- Your password, your recovery key, your account key, or any case key
We can't turn the ciphertext we hold back into any of this. Nothing we hold lets anyone work out your keys short of guessing your password, which is why the product checks new passwords against known breaches, in your browser.
If we're served with a demand
We can only produce what we hold.
That's ciphertext, and the details listed under "What we can see". We don't hold your keys or your password, so we can't be made to hand them over.
What our staff can't do
Even with full access to our own servers, our staff can't:
- Read your case content, evidence or messages
- Get you back into your data by resetting your password. A reset without your recovery key opens nothing.
- Recover your data if you lose both your password and your recovery key
We'll never ask for your password or recovery key, by email, phone or support ticket. Anyone who does isn't us.
The limits
What this design costs, and what it can't protect against.
Every security design has edges. These are ours, stated plainly, because you should know them before you trust us with a case.
- Lose your password and recovery key, and the data is gone
- That's the price of us not being able to read it. Your recovery kit, which you're asked to prove you've saved at sign-up, is how you get back in, with your authenticator app or a backup code as well if two-factor sign-in is on. PIToolkit alone can't recover your account. An opt-in assisted recovery with a trusted contact is Planned.
- It relies on the code your browser loads
- Encryption in a web app runs in code we serve. Someone who could change that code, by compromising how we build or deliver it, could capture a password as it's typed. No browser-based design can rule this out on its own. We narrow it with a strict, nonce-based content-security policy Built and supply-chain controls. No independent review or penetration test has been done yet.
- Malware on your own device is out of reach
- Anything that can read your screen or keystrokes can read what you can. Encryption protects data on our side of the connection, not on a compromised computer.
- First contact is trusted once
- When you and a client first connect, each side trusts the other's key the first time it sees it. A later change of key needs your confirmation, and safety codes let you compare keys with your client directly if you want to be certain.
- An older copy isn't always caught
Caught
For edited records (case names and descriptions, notes, report sections, evidence descriptions), each of your devices remembers the latest version it has seen, so an older copy served to it later is caught.
Not covered yet
- The evidence chain's head (see evidence integrity).
- Time entries and contact details, which can be put back to an earlier saved version unnoticed; catching those is Planned.
- Deleted or reordered messages, and an older version of a published report, aren't caught either.
- A device seeing your account for the first time has nothing to compare against.
In every case the attacker still can't read anything.
- Metadata is not nothing
- The operational details above, such as how many cases you have and how large your files are, are visible to us. We list them so you can judge that for yourself.
Evidence integrity
Every file fingerprinted the moment you upload it.
On every plan, including Free. We describe the mechanism and leave the conclusions to you and your attorney.
- A SHA-256 fingerprint of each file is computed in your browser when you upload it, and stored encrypted.
- A tamper-evident chain per case, with one limit. Each item is linked to the one before it, and you sign the head of the chain, so someone with write access to our database can't alter or insert an item, or remove one, without the verification showing it.
The one limit. Someone who kept an older chain head you really signed could put it back and cut off the items added after it, and verification would still report the shorter chain as intact. Catching that on devices that have seen the newer head is Planned; a device opening the case for the first time would still have nothing to compare against.
- Signed removals. Removing an item leaves a signed marker, not a gap, so the rest of the case stays verifiable.
- An evidence package. Export a case's files with a verification report of each file against the chain, the capture details and your signatures.
- Trusted third-party timestamping (RFC 3161) Planned. Today's timestamps come from PIToolkit and your device, not from an independent time authority.
Account security
The same on every plan. Security is never an upgrade.
- Two-factor authentication with an authenticator app
- A recovery key you save and confirm at signup; until you do, every sign-in starts at that step
- Session controls: sessions expire after 24 hours idle or 7 days, you can see how many devices are signed in, and changing your password signs out every other device
- Your security log, readable by you at any time
- A full export of your account, built and decrypted in your browser. The ZIP you download is not encrypted, so store it somewhere that is.
- Security keys and more two-factor methods Planned
What we don't claim
No badges we haven't earned.
- PIToolkit holds no third-party security certification or audit report today. We won't display one until one exists.
- No independent cryptography review or penetration test has been done. We won't suggest otherwise until one has.
- PIToolkit is in development and not yet hosted for customers. This page describes the development build and will change as the product does.
Report a vulnerability
Found a problem? Tell us first.
Email security@pitoolkit.com with what you found and how to reproduce it. We'll acknowledge it, keep you updated, and credit you if you'd like. Our security.txt has the same details. Please don't access data that isn't yours while testing.
Related guides
Questions about the design?
Ask. We'd rather walk a sceptical investigator through the architecture than have them take our word for it.