How we protect your ideas.

• 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 stay off until you accept them, text is masked, and invite links are stripped before any event leaves your device.
• Aseef is not end-to-end encrypted.

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.
• Link previews are drawn locally, so the domains inside a private space are never disclosed to anyone. Profile pictures are the exception: they load from Clerk, our sign-in provider, or from Google for a Google account photo.

Launch limits

During launch these limits apply to everyone. They cap what one account can use, so the service stays reliable for all. If you reach one, you see a clear message and lose nothing. The pricing page lists them, with the Free plan limits that take effect only when Pro launches, announced in advance.

• 250 active spaces you host, 100 members per space besides you.
• 300 ideas per space, 40 blocks per idea.
• 2 GB of stored files per account, and 50 MB per uploaded file.
• 1,500 collaborative writes per minute and 50,000 per day.

What we measure, and what we discard

Product analytics stay off until you accept them, and nothing is stored for them before that. Once you accept, captured text and element attributes are masked, and every URL in an event is rewritten to a route pattern before it leaves the device. Legal and status pages are never measured.

• Global Privacy Control and Do Not Track are honored as a refusal.
• 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 we test it

Tests check the security rules on every change. The header policy, the authorization rules, the redaction rules and the fair-use limits all have tests that fail the build if they change unexpectedly.

• 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 gaps we know about. We list them so you don't have to find them yourself.

• 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 program 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.