Security

Our security principles

Five principles run through everything below. If you read nothing else, read these:

• Encrypt sensitive content before transmission. Project content is encrypted in your browser, before it reaches our infrastructure. Protection shouldn't begin on our servers — by then it's too late to matter.
• Minimise what we collect. Information we never collect can't leak, can't be subpoenaed, and can't be misused. The cheapest data to secure is the data that doesn't exist.
• Separate content from operational metadata. What your work says and the fact that work exists are different categories of information, and we treat them differently by design.
• Prefer simple, auditable systems. Every component is one more thing that can fail. A small, understandable system protects you better than a sprawling impressive one.
• Assume infrastructure can fail. We build so that a compromised server yields ciphertext, not client work. Trust in a system shouldn't require believing nothing will ever go wrong.

Security at a glance

Security philosophy

Most services ask you to trust them: trust that access is controlled, that employees behave, that databases are configured correctly. That trust is usually justified — but it's still the load-bearing element, and you have no way to inspect it.

We designed Plus± so that trust in us is not the only thing protecting your work. Sensitive content is encrypted before it reaches our infrastructure, which means the protection holds even in scenarios where trust breaks down: a compromised server, a misconfigured database, a subpoenaed hosting provider. In those scenarios, what exists on our infrastructure is ciphertext.

To be precise about the model from the very start: sensitive project content is encrypted before it reaches our infrastructure. Infrastructure providers store ciphertext only. When work needs to be performed, decryption is limited to authorised members of the Plus± team assigned to your project. That's the whole model in three sentences — Access controls explains how it's enforced.

The same philosophy drives what we don't do. We collect the minimum needed to run the service, we store as little as possible in readable form, and we separate responsibilities so no single component — and no single failure — exposes everything.

One thing we won't claim: perfection. Security is not a state a system reaches; it's a process of reducing risk, questioning assumptions, and fixing what you find. This page describes where that process currently stands, and the Security roadmap describes where it goes next.

Architecture overview

The platform splits information into two categories, and the split is the single most important design decision on this page.

Encrypted project data is what your work actually says: briefs, project names, task descriptions, messages, uploaded files, and deliverables. Everything in this category is encrypted in your browser before storage. Our infrastructure stores it, moves it, and backs it up as ciphertext — decryption happens only under the access model described in Access controls.

Operational metadata is the skeleton the service needs to function: account identifiers, task statuses, due dates, subscription tier, and billing state. This remains readable, deliberately — it's how requests get scheduled, queues stay ordered, deadlines trigger notifications, and invoices get generated. None of it contains the substance of your work. It records that task #4821 is in progress and due Thursday — not what task #4821 is.

Browser        project content encrypted here, on your device
    │
    ▼
Edge           transport — TLS, DDoS protection, bot mitigation
    │
    ▼
Application    operational metadata     (readable — runs the service)
               encrypted project data   (ciphertext)
    │
    ▼
Storage        ciphertext + metadata, encrypted again at rest

Why draw the line here? Because a subscription studio genuinely needs operational metadata to deliver the service — pretending otherwise would be theatre. What it doesn't need is standing, readable access to the substance of your work. The architecture encodes that distinction instead of leaving it to policy.

Encryption

Encryption at Plus± happens in three places, and the order matters:

In your browser, first. Content is encrypted client-side, before transmission, using keys generated on your device. This is the layer that distinguishes the platform: a compromise of stored application data or database infrastructure exposes ciphertext rather than readable project content.

In transit. All traffic between your browser and our infrastructure travels over TLS. This is table stakes — we mention it for completeness, not as an achievement.

At rest. Stored data is encrypted at the infrastructure level as well. For content, this means ciphertext encrypted again — the outer layer protects the metadata; the inner layer is the one that matters.

A few architectural details worth knowing:

• Keys are generated on your device, during onboarding, and content keys are scoped per project. Compartmentalisation means one exposed key would affect one project — not your whole account, and never other clients.
• We use established, publicly audited cryptography rather than inventing our own. Identity is a Curve25519 keypair per person; content is encrypted with XSalsa20-Poly1305 under per-project keys; both come from the NaCl family of constructions via the TweetNaCl library. Passwords are stretched with Argon2id — see Authentication for why that detail matters. Writing novel cryptography is how systems fail confidently.
• What we deliberately don't detail here: internal key formats and operational specifics that could aid an attacker without informing a reader. Where we're vague, it's on mechanics — never on the trust model.

Authentication and accounts

Sign-in protects the account; encryption protects the content. They're related but distinct, and both matter.

Passwords never reach us. Your password is stretched on your device with Argon2id and split in two: one half stays in your browser and protects your private key; only the other half is sent to us as a login credential, and we store that credential bcrypt-hashed. The password itself never leaves your device — so our servers hold nothing that can unwrap a private key, even at the moment you log in.

Sessions are cryptographically signed and expire after seven days. The session cookie is locked to the browser (HttpOnly, Secure, SameSite), and signing out clears it.

Account recovery is the deliberately hard part, and we owe you the plain version: because our servers hold nothing that can unwrap a private key, we cannot recover one for you — there is no "reset password" email that brings your keys back. If you lose your credentials, contact us: access is re-established by creating a fresh keypair on your device and having your project keys re-encrypted to it by the people who already hold them. That restores your projects — but it is a deliberate, person-to-person step, not an automated reset, because an automated path to your keys would be an automated path for an attacker too.

Today, authentication is password-based, with the protections above. Multi-factor authentication and passkeys appear on the roadmap, not here — we list them where they belong so nobody skims this page and assumes they already exist.

Access controls

This is the section where we owe you the most precision, so here it is without varnish.

Plus± is a design and development studio, not a storage locker. For us to design your dashboard, someone has to read the brief. Delivering the service inherently requires that the people doing your work can decrypt the project content relevant to that work. Anyone who tells you they can deliver design work on content they can never read is describing a different service — or not being straight with you.

So the honest claims are these:

• Our infrastructure providers do not receive the keys required to decrypt your project content. They store and move ciphertext.
• Access on our side follows least privilege, enforced by keys. A project's content key is individually encrypted to each person who needs it — being on the team, or even running the infrastructure, grants nothing by itself. No wrapped key, no access.
• Administrative and operational duties are separated. Managing infrastructure does not confer the ability to read content — that separation is enforced by the encryption architecture, not by policy alone.
• Workspace actions leave an activity trail — who did what, on which project, when. Fuller security-grade audit logging of key grants and administrative actions is on the roadmap, and we'd rather tell you that than round up.
• Access ends with the work. When an engagement ends, the key grants that served it are removed.

The distinction that matters: with most services, everyone operating the platform could read your data and policy says they won't. Here, the people who can access decrypted content are limited to those holding a key to your project. Access is granted deliberately and removed when it is no longer needed — and the architecture, not the handbook, is what keeps it that way.

Infrastructure

We run on a deliberately small stack, chosen for the same reason as everything else on this page: fewer moving parts, fewer failure modes.

• Edge and hosting — the platform is served through Cloudflare's global network, which also provides DDoS protection, bot mitigation, and TLS termination at the edge.
• Compute — application logic runs on serverless infrastructure, meaning no long-lived servers of ours to patch, harden, and inevitably forget about.
• Database — managed, replicated database infrastructure stores the two categories described above: readable operational metadata, and project data as ciphertext.
• Backups — automated and encrypted, with content remaining ciphertext inside the backups themselves. A restored backup restores our ability to serve your data — not an ability to read it.

We'd rather be honest than mysterious about the general shape: our providers are named in the Privacy Statement. What we don't publish is configuration detail — network topology and internal service boundaries don't belong on a public page.

Data residency. Our infrastructure operates globally to maximise availability and performance. Where personal information crosses borders, appropriate safeguards are applied as described in our Privacy Statement — and encrypted project data crosses those borders as ciphertext.

Supply chain security

Modern attacks increasingly arrive through the software a platform is built on, not the platform itself. Our defence here follows the same principle as everywhere else: keep the surface small, and check what joins it.

• Few dependencies, deliberately. Every package we depend on is attack surface we've chosen. The list is short and reviewed before anything joins it.
• Secrets are never committed to source control — credentials are injected at deployment, scoped to what each component needs.
• Least privilege for deployment. The site build runs with no secrets at all, and the deployment pipeline can deploy — it cannot read production data. A compromised build system should be a bad day, not a breach.
• Updates are applied promptly, with dependency changes reviewed before they reach production.

Automated dependency and secret scanning are on the roadmap below — we list them there rather than here because this section describes what runs today, not what we intend.

Monitoring and incident response

No system is perfectly secure. Ours isn't either. The difference between a mature security posture and a naive one isn't the absence of incidents — it's whether you'd notice, and what you'd do next.

Monitoring. We monitor infrastructure health, error rates, and anomalous patterns — failed authentication attempts, unusual access patterns, unexpected traffic — through our edge and hosting providers, and treat anomalies as signals to investigate, not entries to file.

Logging. Operational logs cover system events and access, but are deliberately designed not to contain decrypted project content, credentials, encryption keys, or other sensitive material — private keys never leave your browser in the first place.

If an incident happens, the process is: contain it, assess what was actually affected, fix the cause, and tell you. Affected clients are notified promptly and plainly — what happened, what it means for you specifically, and what we've changed. We will never announce an incident with a paragraph engineered to be technically true and practically uninformative.

Backups and recovery. Recovery comes from our database's continuous point-in-time recovery window and encrypted infrastructure-level backups — and the content inside them is ciphertext, so restoring our service never means exposing your work.

Responsible disclosure

If you find a vulnerability in Plus±, we want to hear about it — directly, and before anyone else does.

Report to: [email protected]

What we ask: give us reasonable time to fix the issue before public disclosure, don't access or modify other clients' data while demonstrating an issue, and don't run disruptive testing against production.

What we commit to: we'll acknowledge your report within 3 business days, keep you informed as we investigate, tell you when it's fixed, and credit you if you'd like credit. We appreciate responsible disclosure, and we will not pursue legal action against researchers acting in good faith within these guidelines.

We don't currently run a paid bug bounty programme. If that changes, this section changes.

What security doesn't mean

This is the section most security pages skip, which is exactly why it's here.

The architecture described above protects your content from our infrastructure, our providers, and attacks on our systems. It cannot protect you from things that happen on your side of the keyboard:

• Weak or reused passwords. Encryption doesn't help if the front door key is hunter2 and it's also your key to four other services.
• A compromised device. Content is encrypted in your browser — so malware in your browser, or on your machine, sits on the wrong side of the encryption. Your device is part of the system.
• Phishing and social engineering. An attacker who convinces you to hand over credentials hasn't broken the cryptography; they've bypassed it. We will never ask for your password or recovery credentials — anyone who does is not us.
• Shared credentials. Access shared with a colleague is access shared with everyone who ever compromises that colleague.

One limitation sits on our side of the keyboard, and honesty requires listing it here too:

• Compromised application delivery. Browser-side encryption protects data after encryption. If an attacker were able to alter the application code delivered to your browser, they could potentially attack data before encryption. Protecting the software supply chain and deployment path — Supply chain security — is therefore part of the security model, not separate from it.

This is shared responsibility, stated plainly: we've built the system so that its security doesn't depend on trusting us. It does, unavoidably, depend on the security of your own devices, credentials, and judgement. We'll always be honest about where our responsibility ends and yours begins — a security page that implies otherwise is marketing.

Security roadmap

Security work is never finished. In the spirit of separating what exists from what's planned:

Implemented

• ✓ Browser-side encryption of project content, with per-project keys
• ✓ TLS on all traffic
• ✓ Encryption at rest, including backups
• ✓ Least-privilege key grants, scoped per project and per person
• ✓ Workspace activity logging

Planned

• ◷ Multi-factor authentication
• ◷ Passkey support
• ◷ Automated dependency and secret scanning
• ◷ Security-grade audit logging of key grants and administrative actions
• ◷ Independent security review / penetration testing
• ◷ Published security whitepaper covering the cryptographic design in full

When items ship, they move from Planned to Implemented and into the sections above, and the document version at the top of this page changes. This page is versioned precisely so you can hold us to it.

Related

Need more detail?

• Privacy Statement — What information we collect, why, and what we do with it.
• Cookie Declaration — Every cookie we use, what it does, and how long it lasts.
• Terms of Service — The legal agreement covering your use of the service.

Security isn't a destination or a badge we earn once. It's a continuous engineering process — reducing risk, questioning assumptions, and improving the system over time. If you have questions about anything on this page, we'd rather explain how something works than ask you to simply trust us.

Contact Information

If you have any questions or comments about this policy, or your choices and rights regarding it, please do not hesitate to contact us at:

Email:

[email protected]

Address:

Boom Pow Limited, The L. Plaza, 367 - 375 Queen's Road, Central, Sheung Wan, Hong Kong.