Trust
Security at Winglark
How Winglark protects a guest list — at sign-in, inside a workspace, in the mail it sends and at the door — and what is deliberately not in place yet.
Signing in
You sign in with a password or with Google. Passwords are hashed with Argon2id and a per-account salt. They are never stored, logged or recoverable — a reset issues a new one rather than revealing the old.
Links that sign somebody in or open an account — a password reset, an email confirmation, an invitation to activate a workspace — can be used once, belong to one purpose and one person, and expire.
Access is scoped, not checked
Every lookup for an event is made against the organisation that owns it. An identifier belonging to somebody else is indistinguishable from one that does not exist — ownership is part of the query rather than a check performed afterwards on a record already in hand.
Roles and permissions
Every member of a workspace has a role, and each role carries only the permissions it needs. Door staff see the door screen and nothing else. Guests’ email addresses and phone numbers are masked for anybody who is not allowed to see them.
Clients kept apart
An agency’s clients are separated inside its workspace: records carry the client they belong to, and lists, designs and events are filtered by it on the server rather than in the interface. A member’s access to a client can only narrow what their role already allows.
The mail Winglark sends
Invitations leave from a sender you have confirmed. Delivery reports are accepted only when the provider has signed them, and they are counted once. An address that bounced permanently or complained is kept out of future sends, and a complaint can never be released.
At the door
A QR code carries a high-entropy random token that is not derived from anything about the guest. The database stores only a keyed digest of it, so a copy of the database cannot be turned into a working code, and rotating the server key invalidates every outstanding one.
Verification is a constant-time comparison, so a wrong code cannot be narrowed down by timing. A device at the door can be revoked centrally; the guest list it holds for use without signal carries no contact details, and every admission it records offline is checked again by the server when it reconnects.
Import safety
Uploaded spreadsheets are parsed rather than executed, and any cell beginning with a formula character is neutralised before it is stored — so a guest list cannot carry an attack into whoever opens the export next.
Exports and the record of changes
Exports mask contact details unless the person exporting may see them, are limited in size, and are recorded — with a reason required when they contain personal data. Administrative changes to an account are written to an audit log.
What is not in place yet
Winglark is in early access. The following are honest gaps rather than omissions from this page:
Not decidedNo penetration test has been commissioned yet. There is no bug bounty and no dedicated security address yet. No certification (SOC 2, ISO 27001) is held or claimed. Backups are continuous, with point-in-time recovery over the last 24 hours; a written backup and disaster-recovery procedure is still to be produced.
Reporting something
If you find a vulnerability, use the contact page and mark it as support. Until a dedicated security address exists, that reaches the people who can act on it, and it is read quickly.
Questions about any of this go to the contact page.
See it on your own event.
Winglark is in early access. Request access, a person reviews it, and an invitation to your workspace follows.