Recruiting runs on networks that can read your messages. R1 can't. The offer, the counteroffer, the part you'd normally take to Signal — it stays here, end-to-end encrypted.
Every other network makes you leave. R1 doesn't.
News, market analyses and product updates from the R1 team.
Recruiters reformat CVs into Word docs and email them. Files get forwarded infinitely. Zero access control. The candidate's PII lives on random laptops, inboxes, and Slack channels forever. Once sent, it's gone.
Greenhouse, Bullhorn, Vincere — they all require the hiring manager to create an account, navigate a dashboard, learn a UI. By the time they're onboarded, the candidate accepted somewhere else.
LinkedIn profiles are generic billboards. ATS portals show parsed resume data in card layouts. Nothing is tailored to the role. Nothing tells a story. The same CV goes to every company for every position.
A PDF is a static document the moment it's downloaded. No updates, no context, no way back to the source. The hiring manager prints it, scribbles notes in the margin, and throws it away after the meeting.
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.
| 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 | — | |
Offline copy | Varies | — | ||
Compare and rank candidates for a role | Manual | Varies | ||
Built-in candidate network | — | — | ||
Network size | Growing | — | — | 1.3B+ |
Recruiting platforms now hold some of the most sensitive professional data people share: resumes, work history, contact details, salary context, and conversations they expect to remain confidential. In 2025, reported recruiting-platform incidents put 100M+ applicant records and files 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.
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.
A misconfigured Azure Blob container exposed nearly 26 million files, mostly resumes and CVs, with personal and professional details.
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.
A misconfigured cloud bucket reportedly exposed 5.7 million resume files containing names, addresses, emails, phone numbers, and employment history.
| 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. As with all end-to-end encryption, conversation metadata (participants and timestamps) is not message content. R1 uses per-thread keys wrapped to each verified device, fail-closed on key changes, with an append-only key-change log.
Every recruiter link is a one-time credential that belongs to a specific candidate and application. It expires on its own. No cookies, no sessions, no mystery tokens.
When the link dies, the access dies with it.First viewer gets a server-generated 15-word connect phrase bound to their device. Subsequent access from new devices requires the phrase.
Too many wrong tries and the link locks them out.You set a limit on how many unique people can hold the link at once. Once you hit that limit, no one else can join. The candidate controls the circle of trust.
The candidate controls the circle of trust.Links expire after a configurable duration. The countdown is visible to the holder. Expired links show a clean 'not found' state. No zombie data.
No stale data, no ghost access, no surprises.PDF downloads mint a one-time magic token embedded as a URL in the document. The offline artifact always points back to the live, controlled, interactive page.
The document never becomes a dead, uncontrolled file.Hiring managers can chat live on the recruiter page without jumping to Slack, email, or another tool. The conversation stays with the candidate, in context, where decisions happen.
E2E encrypted, no plaintext storageClient-side AES-GCM keeps message content encrypted before it reaches the server. Supported chat stores add server-side AES-256-GCM at-rest encryption with per-thread HKDF-derived keys, so stored data remains ciphertext.
The server stores ciphertext, not message plaintext.Sources: R1, NIST GCM, RFC 5869 HKDF
Every recipient device gets its own wrapped copy of the thread sender key, derived through X25519 key agreement and sealed with AES-256-GCM, without exposing message plaintext to the server. It sits in the same broad design family as modern secure messengers like Signal and WhatsApp.
One device, one wrap, one trust decision.Sources: R1, RFC 7748 (X25519)
Realtime events carry redacted metadata only, never message plaintext. Payloads identify the event, channel/scope, timestamps, and routing metadata so clients can re-fetch the encrypted message state from storage.
A compromised realtime listener may see that activity occurred and some routing metadata, but not the message body.Each device gets its own cryptographic identity. Private keys stay local in IndexedDB, while the server only knows the public keys and who they belong to.
If a device is revoked, it is removed from future key access without signing the user out everywhere.Sources: R1, RFC 7748, RFC 8032
R1 checks device ownership, thread membership, and trust status before any wrapped sender key is stored or delivered.
Only verified devices get the keys.R1 remembers the first trusted fingerprint for each device using SHA-256. If that device's key changes later, the client blocks secure messaging instead of silently accepting the new key. This catches unexpected key changes after trust is established.
R1 pins device fingerprints on first trust.Most recruiting platforms were not built for end-to-end encrypted conversations. LinkedIn's own messaging docs describe server-side smart features, and 2025 showed how fragile recruiting data can be: one recruiting software exposure alone leaked nearly 26 million resumes through a misconfigured cloud container.
R1 is built around end-to-end encryption. Message content is encrypted on your device before it reaches our servers and stored only as ciphertext. Because R1 cannot read it, it cannot be mined, profiled, or used to train AI models — a property of the architecture, not a promise.
Messages reach the recruiter and no one in between. Not even us. It's not a privacy policy — it's math.
Whether you are an agency team scaling client operations or a candidate protecting your profile, R1 is built to serve your autonomy.
Create roles, generate custom shares, live-chat with hiring managers, and capture every decision. No client login required, protected by Connect Protocol.
Present your timeline in an interactive, controlled environment. Bind unique device fingerprints, limit the number of viewers, and prevent AI scraping.