Platform
Security
BANANA-GOAT is built so people can view your 3D model on the web without receiving the original geometry. This page is written for product users and for security reviewers evaluating the service.
What we protect
The main asset we protect is your source 3D / CAD geometry and the IP inside it — the raw file you uploaded and the engineering information that would let someone reuse or remanufacture from it.
We also protect access to the delivered viewer: artifacts are not left on naked public URLs. Share and embed access is token-controlled, and revoke cuts that access off.
Account credentials and session cookies are part of normal product security, but the distinctive claim of BANANA-GOAT is geometry protection in web delivery — not a full enterprise GRC suite by itself.
Threat model (plain language)
A threat model is simply: who might try to take your model, how, and how hard we make that.
Today the product is aimed at:
- Casual “save / download the model” — strong: there is no source-file handoff in the product UI
- Scrapers and embed rippers — better than a public GLB: artifact bytes need an owner session or a live share/embed token
- Competitor reverse-engineering from the viewer — hard, not impossible (see reconstruction below)
- Nation-state / classified / forensic-grade attackers — out of scope; we do not claim that class of protection
Impossible vs hard
Impossible through this flow: getting the original geometry / raw upload back from what viewers receive.
Hard: recovering some basic related shape from the secured 3D artifact. It is economically inefficient. Someone can reconstruct a basic geometry outline of the original — similar to having photos taken every few degrees around a physical object — but that is not your original CAD, and it is not production-ready engineering source.
What viewers get
Viewers get an interactive secure 3D web artifact in the browser (share link, embed, or your own library view). They do not get the original upload.
There is no Download button in the product share, embed, or library viewers.
What happens to the original upload
Product policy: after processing, the original upload is deleted. The library keeps the secure artifact used for viewing.
* Confirm and document automatic source + intermediate deletion on the production path (local/dev may still keep files for debugging). Also confirm whether deletion timing is guaranteed or best-effort.
Compared with normal GLB / Drive sharing
Hosting a normal GLB or sending CAD over Drive/Dropbox usually means the recipient (or anyone with the link) can obtain reusable geometry or the real file.
BANANA-GOAT processes the upload into a structurally different secure web visualisation, gates artifact access with sessions/tokens, and is designed so the original is not the thing that travels with the link.
Who can see a model
Models are not public by default. Owners see them in the signed-in library. Other people only see a model if you create a share or embed and they have that live link/token.
You can revoke a share/embed later; revoked tokens stop artifact access.
* Share expiry, passwords, IP allowlists, and embed domain allowlists are not shipped as product controls yet — decide and document.
* Restricted share (invite allowlist + email confirmation) is stubbed in UI; backend not complete — document status for enterprise buyers.
Share and embed tokens
Share/embed links use opaque tokens. The public share API resolves a live token; artifact requests must include a valid token (or an authorized owner/guest session). Revoke sets the share inactive so further artifact loads fail.
* Document token generation (entropy), storage (hashed vs plaintext at rest), rotation policy, and length/format for security questionnaires.
Tenant separation
Artifact and model access are checked against the owning account/session or a share token bound to that model. Direct public “open any jobId” model APIs are disabled.
* Publish a short tenancy / isolation statement for enterprise review (how job IDs, storage paths, and auth checks prevent cross-customer access).
Accounts and authentication
Self-serve accounts use email/password (password hashing with PBKDF2-SHA256 in the current auth implementation). Sessions use HTTP cookies.
Deleting a model removes it from the library. Deleting an account removes the account and associated jobs in the current app flow.
* Enterprise SSO / SAML / OIDC — not in the current product; mark as roadmap or contact-sales.
* Employee offboarding playbook (org seats, API keys, shared tokens) — * document for enterprise.
Encryption and hosting
Traffic is expected over HTTPS in production.
Privacy Policy: BANANA-GOAT is Netherlands-based, with a Europe-first hosting direction (Azure planned for production). Transfers outside the EEA/UK/Switzerland use appropriate safeguards where required (e.g. SCCs).
* Encryption at rest for artifacts and originals (algorithms, KMS, who holds keys) — * research and document; do not claim zero-knowledge operator blindness unless it is actually implemented.
* Customer-selectable data residency (EU / UK / US / AU pin) — * confirm Azure region plan and contractual options.
* TLS version / cipher policy for production — * document when go-live infrastructure is fixed.
Pipeline files and operator access
Processing creates intermediate files on the way to the secure artifact. Production policy is to delete intermediates after processing; local/dev may retain them for debugging.
* Who in BANANA-GOAT (if anyone) can access customer artifacts in production, under what break-glass process, and how that is logged — * research and document.
* Whether customer models are ever used for ML training or product improvement — Privacy Policy framing is service operation; * confirm an explicit “no training on customer models” (or exceptions) statement.
Compliance and legal pointers
Published legal pages: Privacy Policy, Terms of Service, Cookie Policy, and DPA under Company in these docs. Company entity: Wallnah (trading as BANANA-GOAT), Netherlands. Privacy contact: info@banana-goat.com.
Privacy Policy names categories of subprocessors such as Microsoft Azure (hosting) and Stripe (payments), plus auth/comms/monitoring providers as used.
* Maintain a current public subprocessors list with locations and purposes.
* SOC 2 / ISO 27001 / penetration-test reports availability — * not evidenced in-repo; decide what you can share under NDA.
* Customer audit rights — DPA draft mentions reasonable audit; * align signed enterprise DPA with what you can actually support.
* GDPR / UK GDPR / Australian Privacy Act mapping one-pager for security questionnaires.
Incidents, vulns, and abuse controls
DPA draft: notify customers without undue delay after becoming aware of a personal data breach affecting their data.
* Formal incident-response SLA (hours), security contact, and vulnerability disclosure / bug-bounty process — * publish.
* Backup encryption, retention, and DR RPO/RTO — * document for production Azure.
* Rate limiting and abuse protection on upload, share resolve, and artifact download — partial product limits exist by plan; * document API/edge rate limits for enterprise.
Honest limits
This is not perfect DRM. A determined person may capture the runtime artifact from the browser. Original geometry extraction through our flow is not possible; reconstructing a basic shape is hard and economically inefficient, not impossible.
Classified / nation-state protection is out of scope.
Related pages
Marketing security overview: /security. Legal: Privacy, Terms, Cookies, DPA. Product access controls in practice: Sharing and Embedding.
