How we protect the record of who is a member, right now.

Threat model

The Service exists because employers, contractors, and government agencies sometimes need to know — quickly and accurately — whether a person is a member of a particular union. The threats we worry about, in priority order, are:

1. Wrong answers. Telling a verifier that a current member is inactive, or that a former member is active, can cost someone a shift or worse. Integrity of the status field is our top concern.
2. Unauthorized status changes. An attacker who flips a member from active to suspended commits real harm even if no data is exfiltrated.
3. Bulk member enumeration. A list of who is in a union is itself sensitive — politically in some jurisdictions, commercially in others.
4. Loss of audit trail. A platform that quietly forgets what it did is worse than one that says nothing.
5. Bulk data exfiltration. Standard but lower in priority than the above because the dataset per record is small and well-bounded.

Our controls are sized to those threats, not to a generic SaaS checklist.

In transit

Every request to theunionhub.com, the card, the verifier, and the Supabase API is served over TLS 1.2 or higher with HSTS preloaded. We do not accept plain HTTP on production hostnames.

The verifier never includes a member's UUID in the page chrome (browser title, referrer header). Outbound links from the verify screen are rel="noopener noreferrer".

At rest

The members table and the audit log are stored in Supabase Postgres with disk-level encryption managed by the underlying cloud provider. Application-layer encryption of specific sensitive fields is on the roadmap; today, the design relies on row-level security and minimal field set.

Daily backups are encrypted and retained for thirty (30) days. We test restore from backup at least once a quarter.

Access & identity

The Operator is currently a single person. Administrative access to Supabase, the hosting account, and the domain registrar uses:

• Unique, randomly generated passwords stored in a hardware-backed password manager;
• Multi-factor authentication on every console, with hardware security keys (FIDO2) where the provider supports them;
• No shared accounts, ever;
• Session re-auth at least every twenty-four hours.

Customer administrators sign in to the Service via passwordless email magic link. Sessions last twelve hours and are bound to a single browser. There is no "remember me" past that window.

Members do not have passwords. The card and verifier work over an unguessable per-member URL backed by row-level security; possession of the URL does not, by itself, prove identity.

Row-level security

The publishable anon key shipped in the front-end is, by design, public. The defence is that Supabase row-level security only allows the anon key to read a single row by exact id match. There is no SELECT * path, no WHERE name LIKE, no enumeration. Every other operation — insert, update, delete, list — requires the service-role key, which lives only on the server side.

The RLS policies are versioned in source control and reviewed before each release.

Audit log

Every read of a member's record — whether through the card or the verifier — and every administrative action writes a row to an append-only audit_log table. The full feature description, including what gets logged and how unions can use it, is on the audit log page.

Audit log entries cannot be edited or deleted by the Operator without breaking the chain. The chain is checkpointed daily into write-once storage so that any tampering is detectable.

Abuse & rate limits

The verifier is rate-limited at the edge per IP and per member ID. Anomalous patterns — bursts of consecutive lookups, sequential UUID probing, distributed enumeration — trigger a captcha challenge and an alert to the Operator. Persistent abuse results in a temporary block and a written notice to the affected union.

Supply chain

The site is intentionally austere. Production pages depend on three external resources only: Google Fonts (typefaces), Supabase (data API), and the page itself. There is no analytics SDK, no tag manager, no chat widget, no marketing pixel. Adding a new dependency requires a written change in the project repo.

For server-side build tooling, we pin direct dependencies and review transitive updates monthly.

Backups & continuity

Database: encrypted daily backups, 30-day retention, quarterly restore drill.

Static site: source of truth in version control; the running site can be redeployed from a clean repo in under thirty minutes.

Domain: registered with a registrar that supports registry-level transfer locks; the lock is on by default.

Incident response

If an incident is confirmed, the response sequence is:

1. Contain — stop the bleeding (rotate credentials, take an affected component offline, restore from a known-good backup).
2. Notify the Customer — within seventy-two (72) hours of confirmation, with the information required by the DPA.
3. Notify members and regulators — assist the Customer in fulfilling its statutory obligations under PIPEDA and any provincial law.
4. Investigate — root-cause analysis with a written post-mortem.
5. Remediate — close the gap, document the change, tell the Customer what changed.

We publish a redacted summary of any material incident at /status.html.

Responsible disclosure

We do not, today, offer a paid bug bounty. We do offer public credit on this page for anyone who reports a valid finding.

Roadmap

Things we know we want to add, in priority order:

• Application-layer field encryption for the optional photo and member name;
• A SOC 2 Type II audit once the Operator is incorporated and has the second pair of hands needed for proper segregation of duties;
• Customer-managed encryption keys for unions that want them;
• Automated quarterly third-party penetration testing.

If you are evaluating us and one of these matters today, tell us and we will give you a real timeline.