Security
The server stores math, not messages. Every conversation is end-to-end encrypted with AES-256-GCM. Keys are exchanged via X25519. Device identity is bound by TOFU fingerprinting. Every key change is recorded in a public, tamper-evident transparency log.
Threat model
R1 protects message content, candidate profiles, and decision reasoning from server-side access. The server cannot read encrypted DMs, portal chat messages, or candidate communications — it stores ciphertext only. Device keys are generated client-side and never transmitted in plaintext. Portal access is granted via signed capability tokens, not accounts.
What is protected: Signals DMs, portal chat, team DMs, candidate profile fields, decision reasoning. What is not protected: job board listings (public by design), aggregate job counts, sitemap data, blog content. Metadata such as message timestamps and participant counts are visible to the server.
These protections apply across all R1 products — Jobs, Signals, Portals, and Application Studio. For implementation details, see the sections below.
Every other network makes you leave. R1 doesn't.
The old signals
are gone.
Your data becomes training data.
CVs become PDFs. PDFs become training data. Once it's sent, it's gone — and AI has it forever.
Portals kill momentum.
Account. Dashboard. Training. By the time they're in, the candidate is gone.
Every profile looks the same.
AI can replicate any profile at scale. Nothing is verifiable. Nothing is device-bound. The same polished CV goes everywhere.
Files die the moment they're sent.
A PDF is frozen the moment it's downloaded. No updates, no context, no way back to the source.
Connect
Protocol
Alex Chen
Led the real-time sync engine rewrite at Linear, reducing p99 latency by 68%. Architected distributed event sourcing pipeline processing 2.4M events/day with zero data loss across 3 regions.
Experience
- Rewrote the sync engine from polling to CRDT-based real-time, cutting p99 from 1.2s to 380ms
- Designed event sourcing pipeline handling 2.4M events/day across US, EU, APAC regions
- Built the edge function runtime serving 14B requests/month with sub-50ms cold starts
Skills
R1 Connect
| Capability | R1 | PDF / email | ATS portal | LinkedIn profile |
|---|---|---|---|---|
Opens without an account | Varies | Varies | ||
Tailored to the role | Manual | Varies | — | |
Expiring shared access | — | Varies | — | |
Viewer limit for a shared link | — | Varies | — | |
Trust phrase for a new browser | — | — | — | |
Chat embedded on the candidate page | — | Varies | — | |
End-to-end encrypted embedded chat | — | Not typical | — | |
Key numbers highlighted automatically | Manual | Varies | — | |
PDF linking back to the live page | Manual | Varies | — | |
Platform cannot read message content | — | — | — | |
Offline copy | Varies | — | ||
Compare and rank candidates for a role | Manual | Varies | ||
Built-in candidate network | — | — | ||
Network size | Growing | — | — | 1B+ |
Message
Security
Recruiting platforms hold your most sensitive professional data. In 2025, incidents put 100M+ records at risk.
Sources: McHire researcher writeup, TalentHook / Cybernews, Foh&Boh / Cybernews, HireClick
Encrypted on your device. R1 stores ciphertext. Only the recipient's device can read it.
McHire
A hiring chatbot used by McDonald's franchisees exposed a path to applicant data through basic access-control failures, including default credentials and an IDOR vulnerability. Researchers reported that up to 64 million applicant records could have been accessed.
TalentHook
A misconfigured Azure Blob container exposed nearly 26 million files, mostly resumes and CVs, with personal and professional details.
Foh&Boh
A publicly exposed AWS bucket contained 5.4 million files, largely resumes and CVs submitted through a hiring platform used by hospitality and retail brands.
HireClick
A misconfigured cloud bucket reportedly exposed 5.7 million resume files containing names, addresses, emails, phone numbers, and employment history.
What protects the message itself.
| Protection | R1 protected chat | LinkedIn messages | Typical ATS messaging | WhatsApp personal chats |
|---|---|---|---|---|
Encrypted in transit with TLS | ||||
Messages encrypted end to end | — | — | ||
Service cannot read message content | — | — | ||
Keys unique to each device | — | — | ||
Thread keys wrapped for each recipient device | — | — | ||
Trusted key changes are detected | — | — | ||
Append-only audit log of every device key change | — | — | ||
Revoked devices stop receiving message keys | — | — | ||
Cross-device recovery without exposing plaintext to the service | — | — | ||
Unverified cross-party devices blocked before key delivery | — | — | — | |
Invalid encrypted envelopes rejected before storage | — | — | — | |
Realtime message alerts contain metadata only | — | — | — |
ATS refers to standard native messaging in Greenhouse, Lever, Bullhorn, iCIMS, and Workday. Third-party integrations are excluded.
Protections apply to message content. Metadata — who, when — is not message content. Every key change is logged and client-verifiable.
The engine
underneath.
One link. One key.
Every recruiter link is a one-time credential for one candidate and one role. When it dies, the access dies with it.
Single-use link with configurable expiryThe right device gets the phrase.
First viewer receives a device-bound connect phrase. New devices need it. Too many wrong tries lock the door.
15-word device-bound connect phraseYou control the circle.
Set a limit on how many people can hold the link at once. Once it's full, no one else gets in.
Viewer limit per shared linkIt expires when you say.
Configurable countdown. Clean 'not found' after expiry. No stale data, no ghost access, no surprises.
Time-bound link expiryThe PDF stays alive.
Every PDF download carries a one-time token back to the live, controlled page. The offline file never becomes a dead end.
One-time magic token in PDFReal talk.
Hiring managers chat right on the candidate page. No Slack. No email. No context lost.
Embedded E2EE chatEncrypted before it leaves.
Your message is locked on your device. The server only ever handles noise.
Client-side AES-256-GCM + HKDFSources: R1, NIST GCM, RFC 5869 HKDF
One key per device.
No shared master key. No single breach that unlocks everything. Each device gets its own sealed copy.
X25519 key agreement per deviceSources: R1, RFC 7748 (X25519)
Realtime only knows activity.
It sees that something happened. Never what was said. Never the body.
Metadata-only realtime eventsEvery device has its own identity.
Private keys stay local. The server only knows public keys. Revoke one device without signing out everywhere.
Device-scoped identity keysSources: R1, RFC 7748, RFC 8032
Keys go to verified devices only.
Device, thread, trust status — all checked before any key is stored or delivered. No exceptions.
Verified-recipient enforcementFirst trust, forever.
We pin the first fingerprint of every device. If the key changes, messaging stops until you verify.
TOFU fingerprinting with SHA-256AI broke hiring. R1 rebuilds it on trust.
Message content is encrypted on your device. The server stores math. It cannot read it, mine it, or train on it. Your offers, your counteroffers, your rejections — yours.
- One device, one key.
- Encrypted before it leaves.
- Verified before it's delivered.
- Pinned on first trust.
- Revoked in one click.
Messages reach the recruiter and no one in between. Not even us. Not a privacy policy. Math. See the transparency log →