Aseef

Security

What actually protects your ideas.

This page describes the protections that exist in the shipped product today, in plain terms. Where something is not in place yet, it is listed as missing rather than left for you to assume.

Last reviewed — Aug 29, 2026

  • Sign-in runs through Clerk. Aseef never receives or stores a password.
  • Traffic is encrypted in transit, and stored data is encrypted at rest by our infrastructure providers.
  • Every read and write is authorization-checked on the server, never in the browser alone.
  • Analytics are optional, text is masked, and invite links are stripped before any event leaves your device.
  • Aseef is not end-to-end encrypted, and we will never imply that it is.

Not end-to-end encrypted

Aseef does not offer end-to-end encryption, and this was a deliberate decision rather than an omission. Blocks are computed and authorized on the server, which is what makes the permission rules on this page enforceable at all; end-to-end encryption would move that trust into the client and weaken it. In practice this means Aseef's infrastructure can technically access space content, and staff access is limited by policy and access control rather than by mathematics. We would rather say that plainly than let a padlock icon imply otherwise.

Signing in without a password

Identity is handled by Clerk. You sign in with Google or with Apple, so there is no Aseef password to leak, reuse, or reset. Sessions are verified as signed tokens on every backend call, and on phones the session lives in the operating system's secure storage rather than ordinary app storage.

  • No password field exists anywhere in the product.
  • Account changes arrive as signature-verified webhooks, not open endpoints.
  • An account with deletion in progress is treated as signed out everywhere at once.

Where your spaces live

Spaces, ideas, blocks, and uploaded files are stored in Convex, which also serves the real-time connection the collaborative editing runs on. Connections use encrypted transport, and data at rest is encrypted by the infrastructure provider.

  • Backend requests are limited to a fixed list of allowed origins.
  • Outbound fetches refuse private, loopback, and cloud-metadata addresses.
  • Uploads are bounded by type and size before a file is accepted.

Authorization decided on the server

Who may do what is decided in the backend and only mirrored by the interface, so hiding a button is never the security control. Reading a space requires an accepted membership; editing additionally requires a role above viewer; and each block type carries its own authority rule.

  • Decisions and focus timers are host-only, by design.
  • Comments, polls, and resources are author-or-host.
  • Removing a block is never easier than editing it.
  • A host cannot rewrite what someone else wrote — only remove it.
  • Invite codes are generated from a cryptographic random source and hidden from viewers.

The browser side

Every page ships a Content Security Policy. The signed-in app receives a per-request policy built around a fresh random nonce; the public pages receive a static policy. Both block plugins and framing outright, and neither permits code evaluation in production.

  • Framing is denied, content-type sniffing is off, and referrers are trimmed cross-origin.
  • Camera, microphone, and location are denied at the browser level.
  • No third-party image loading — link previews are drawn locally, so the domains inside a private space are never disclosed to anyone.

Fair-use ceilings

A fully free product still has to survive a bad day. Server-side ceilings bound what one account can consume, and they exist for reliability rather than to sell an upgrade. Reaching one produces a clear message, never silent data loss.

  • 250 active spaces per account, 100 collaborators per space.
  • 300 ideas per space, 40 blocks per idea.
  • 2 GiB of stored files per account; 50 MiB per uploaded file.
  • 1,500 collaborative writes per minute and 50,000 per day.

What we measure, and what we discard

Product analytics are optional and disabled entirely when no key is configured. When they are on, captured text and element attributes are masked by default, and every URL in an event is rewritten to a route pattern before it leaves the device.

  • An invite link is a working credential, so it is redacted rather than reported.
  • Redaction is applied by value, so a new analytics field cannot leak one by accident.
  • No cross-site tracking and no advertising identifiers.

How the code is kept honest

Security work is verified by tests that run on every change, not by memory. The header policy, the authorization rules, the redaction rules, and the fair-use ceilings all have suites that fail the build when they drift.

  • Dependency advisories are gated in the build; a reviewed exception is bound to a fingerprint of the lockfile it was reviewed against, so it cannot silently outlive it.
  • Account deletion runs as a durable, resumable job across every table before the external identity is removed.
  • The desktop app ships its own restrictive policy, smoke-tested on each build.

What we have not done yet

These are real gaps. They are listed here so nobody has to discover them during a security review.

  • No third-party penetration test has been performed.
  • No formal certification, such as SOC 2 or ISO 27001, is held.
  • There is no paid bug-bounty programme yet.
  • There is no end-to-end encryption, as described above.

Reporting a vulnerability

Until the security mailbox is live, send us a direct message on x.com/AseefApp and we will open a private channel with you. Please give us a reasonable window to fix the issue before disclosing it publicly, and do not access, modify, or retain anyone else's data while testing.

Machine-readable contact details are published at /.well-known/security.txt following RFC 9116.