Security
BitProof asks people to trust evidence, so this page states how the product is built and where its limits are. It describes the current implementation, not an aspiration.
Architecture
The site is static: HTML, CSS and ES modules served by Firebase Hosting, with no server of our own and no bundler. Authentication is Firebase Authentication. Data lives in Cloud Firestore and Cloud Storage. There is no BitProof backend that could hold a session, a key or a copy of your prompts.
Authorization
- Access is decided by server-side security rules, not by the browser. A client that calls the database directly is subject to exactly the same rules as the console.
- Workspace data is authorized against the workspace document's member list. Sub-collections never trust a field on the child document.
- Only the workspace owner can change who is a member. Members can read and write the workspace's systems, runs and packs, but cannot grant access to anyone else.
- A completed assessment run is write-once: it can be sealed exactly once, never edited afterwards, and only the workspace owner can delete one. A pack's version number must be the next one in sequence, so a version cannot be reused.
- A share document can only ever be changed to revoke it. Its evidence snapshot is immutable once handed over.
- Every rule has an automated test with a positive and a negative case, run against the Firebase emulators in CI.
Share links
A link carries 256 bits of entropy from the browser's CSPRNG, base64url-encoded. It is
readable without an account only while it is neither revoked nor expired; a revoked, expired or
unknown token is refused identically, so an outsider cannot distinguish them. The reader sees
the pack snapshot and nothing else in the workspace. Share pages are served
noindex, nofollow.
Secrets
BitProof stores no customer API keys, tokens or model weights, and has no field to put them in. Endpoint URLs are stored in the clear and shown to relying parties, so the console refuses a URL carrying credentials in its userinfo or in a query parameter that looks like a secret. In the in-VPC and on-prem deployment tiers only signed evidence artifacts leave your network.
Verification
The computational-integrity attestation is Ed25519 over canonical JSON. Verification runs in the reader's own browser, in WebAssembly, against the public key carried inside the receipt — the reader is not trusting BitProof and is not trusting the applicant. The relying-party workspace runs that check automatically when the page loads, labels each engine field according to whether the signature covers it, and shows an explicit mismatch state when a value stored on the pack disagrees with the signed receipt. A pack can also be downloaded as JSON, including the receipt, and verified with your own tooling.
Transport and browser hardening
- HTTPS only, with HSTS.
X-Content-Type-Options: nosniff,X-Frame-Options: DENY,Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy denying geolocation, microphone and camera.- Uploads are capped at 20 MB per file and restricted to an allowlist of content types (pdf, txt, md, json, png, docx).
Known limits, stated plainly
- No Content-Security-Policy header yet. The pages carry inline theme bootstraps that a strict policy would need hashes for; adding one without being able to test the resulting policy against live Firestore traffic risks breaking the product, so it is a tracked item rather than a claim.
- No SOC 2 or ISO 27001 report. We are early access and we will not imply otherwise.
- No formal penetration test has been commissioned. The adversarial work to date is our own, on the verification engine, and it proves the referee catches the attacks we thought of. That is evidence, not a security proof.
- Nobody has formally relied on a BitProof pack yet.
Reporting a vulnerability
Email platform@vbounds.com with the words "security report" in the subject. Tell us what you found, how to reproduce it, and what you think the impact is. We will acknowledge within 2 working days and tell you what we intend to do. We will not pursue anyone who reports a genuine issue in good faith, who avoids privacy violations and service degradation, and who gives us reasonable time to fix it before going public. There is no paid bounty programme today; we will say so rather than imply one.