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.
Independent Verification
Our production environment is publicly audited. We maintain a top-tier rating for network protocol resilience and data-injection mitigation. In production, every response includes HSTS, strict CSP, X-Frame-Options, X-Content-Type-Options, and CORP/COOP/COEP isolation.
HSTS Enforced
All browsers must interact with R1 over encrypted HTTPS. Downgrade attacks and cookie-hijacking are blocked at the protocol level.
max-age=31536000; includeSubDomains; preloadStrict CSP Active
Content-Security-Policy restricts script execution to trusted sources only. Cross-Site Scripting (XSS) and unauthorized data injection vectors are eliminated.
script-src 'self' + nonce-basedFrame-Ancestors Locked
R1 cannot be embedded in iframes by anyone. Clickjacking and UI redressing attacks are blocked via both CSP frame-ancestors and X-Frame-Options headers.
frame-ancestors 'none'Worker-Source Restricted
Service workers and Web Workers can only originate from R1's own domain. Third-party code execution in worker contexts is blocked.
worker-src 'self'Don't take our word for it. Run our domain through the independent Security Headers framework and see the full report.
Run Independent AuditThreat 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.
Each row is written in plain English: what it means for you, not what it means for a cryptographer.
| Protection | R1 protected chat | LinkedIn messages | Typical ATS messaging | WhatsApp personal chats |
|---|---|---|---|---|
Encrypted in transit with TLS Your messages are scrambled while traveling across the internet. | ||||
Messages encrypted end to end Only you and your recipient can read the message — not even R1. | — | — | ||
Service cannot read message content We can't see your conversations, even if subpoenaed. | — | — | ||
Keys unique to each device Each phone or laptop gets its own lock — one compromised device doesn't expose the rest. | — | — | ||
Thread keys wrapped for each recipient device Adding a new phone doesn't expose old messages to it. | — | — | ||
Trusted key changes are detected You're alerted if someone's device keys change unexpectedly — a sign of tampering. | — | — | ||
Append-only audit log of every device key change Every key change is recorded permanently — you can verify the full history yourself. | — | — | ||
Revoked devices stop receiving message keys Lost a phone? Remove it and it instantly loses access to new messages. | — | — | ||
Cross-device recovery without exposing plaintext to the service Add a new device without us ever seeing your message content. | — | — | ||
Unverified cross-party devices blocked before key delivery Unknown devices from other parties are blocked before they can receive your keys. | — | — | — | |
Invalid encrypted envelopes rejected before storage Tampered or malformed messages are rejected before they're ever stored. | — | — | — | |
Realtime message alerts contain metadata only Push notifications say 'New message' — never the actual content. | — | — | — |
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 →