On this page — 20 sections
- 1Who we are, and what this covers
- 2What we collect
- 3Where the data comes from
- 4Special-category data: race, ethnicity, gender, veteran status, disability
- 5Your résumé, tailoring, and AI
- 6The hand-off: what leaves Crossing and enters an employer's system
- 7What we never do
- 8Third parties
- 9Cookies, local storage and shareable links
- 10Legal bases (GDPR / UK GDPR)
- 11How long we keep things — including what survives deletion
- 12Your rights and how to use them
- 13California residents (CCPA / CPRA)
- 14Crossing is not a consumer reporting agency
- 15Security
- 16Other people's data — recruiters, hiring managers, interviewers
- 17International transfers
- 18Children
- 19Changes to this policy
- 20Contact
In plain language
- Crossing never submits an application for you. It reads the employer's published questions, fills in what it can justify from your own answers, and then opens the employer's own form in your browser. You press Send. There is no code in Crossing that can submit on your behalf.
- We hold a lot about you, because that is what the product is: your résumé (the text and the original PDF or DOCX file), your contact details, your work-authorisation answers, the questions employers asked you and the answers you gave, the jobs you looked at, and a record of every application you handed off.
- Race, ethnicity, gender, veteran status and disability are optional, and off by default. The default setting is "ask me each time", which means we leave those questions blank and you answer them on the employer's page or not at all. We never infer them from your résumé — the code that reads those fields has no access to your résumé at all. We only store them if you type them into your own settings.
- We do not sell or share your personal information, in any sense — including the specific meanings California law gives "sell" and "share". No advertising, no data brokers, no analytics scripts, no tracking pixels.
- Where AI is involved, it rewrites your own bullet points and drafts cover letters. It is never shown your email, phone, address, work-authorisation answers or any demographic answer. Today no AI provider is configured at all and every one of those features runs locally on our own server.
- Once you open the employer's form, you are on the employer's page. What you send from there is governed by that employer's privacy policy and their applicant-tracking system's, not by ours.
- You can download everything at
/api/export/data.jsonand delete your account from Settings. Deletion is immediate and permanent — no grace period, no archive copy. Two caveats are described honestly in §11; we are not going to pretend they aren't there. - Crossing is not a background-check company. We do not make, and do not help anyone else make, hiring decisions about you.
The rest of this document is the detail. It is long because the honest version is long.
1Who we are, and what this covers
Crossing is a remote-job search product: it aggregates public job postings, scores them against your résumé, tailors that résumé for a posting, and walks you through applying one job at a time.
The controller of your personal data (the entity that decides why and how it is processed) is Unresolved: REVIEW: legal entity name, registered address, and registration number.
Contact for anything in this policy: Unresolved: REVIEW: contact email address — a real, monitored inbox Unresolved: REVIEW: postal address for formal requests.
This policy covers the Crossing web application and its API. It does not cover employers' websites, applicant-tracking systems, job boards, or anything else you reach by following a link out of Crossing.
2What we collect
Everything in this table is stored in a single application database. Nothing here is guessed at — each row corresponds to data that actually exists in the running system.
Account
| What | Detail |
|---|---|
| Email address | Required. Used to sign you in and to address any mail we generate. |
| Password | Stored only as a hash — a one-way transformation. We cannot read your password and cannot recover it for you. |
| Password reset links | If you ask for one, we hold a one-way hash of a single-use token for 60 minutes and delete it the moment the link is used. The plain token exists only inside the link. |
| Name | As you type it at signup, editable later. |
| Time zone | Used to schedule reminders and render dates. |
| Plan and role | Which plan you are on and whether you are an admin. |
| Sign-in timestamps | The time of your last sign-in. |
Sessions and technical data
| What | Detail |
|---|---|
| Session record | A random token id, your account id, an expiry, the IP address and the browser user-agent string captured when the session was created. |
| Retention | 30 days from creation. This is the only place an IP address is stored anywhere in Crossing, and there is no other server-side request log in the application. |
Job-search profile
Your headline, summary, current title, seniority, years of experience, skills, desired job titles, target salary range and currency, employment types, preferred regions, country, UTC offset, work-authorisation categories, keywords and companies you want excluded from results, your links (GitHub, LinkedIn, website, portfolio, X/Twitter), and whether you are open to work.
Résumés — text *and* the original file
| What | Detail |
|---|---|
| The original file | We store the original bytes of every résumé you upload — the actual PDF, DOCX, RTF or TXT — in the application database. Files are capped at 10 MB. The filename is reduced to a bare basename before storage. |
| The extracted text | The full plain text of the résumé. |
| The structured parse | Name, email address, phone number, location, links, headline, summary, skills, job titles, employers, education (school, degree, year), years of experience, and each role with its title, employer, dates and bullet points. |
| Versions | Résumés are versioned; a tailored copy keeps a link to the résumé it came from. |
Parsing happens on our own server. PDF and DOCX text extraction are local libraries — the file is not uploaded anywhere else to be read.
The apply profile — what gets typed into employers' forms
This is a separate record from your search profile, because it is the one that reaches employers' question sets:
First name, last name, email, phone, city, state or region, country, postal code, your links, your work-authorisation answers (US / UK / EU / Canada, and whether you need sponsorship), pronouns, the four demographic fields covered in §4, your demographic mode, your review preference, and which résumé is your default.
How it gets filled in the first time: on first use we seed it from your account name and email, your search profile, and your default résumé's parsed contact block. Until you open the form and save it yourself, we mark the address as "from your résumé" rather than treating it as confirmed fact. The four demographic fields are never seeded — see §4.
Remembered answers to employer questions
When you hand off an application, Crossing remembers the answers you gave, keyed by a normalised version of the question's wording, so that the next employer who asks "How did you hear about us?" gets your answer already filled in. For multiple-choice questions we store the label you picked, not the board's internal option id, because option ids differ between employers.
Some answers are never remembered, by design: every demographic question, and every work-authorisation and sponsorship question. See §4.
Application records
| What | Detail |
|---|---|
| Applications | Job title, company, URL, location, salary, status, priority, source, which résumé you used, how excited you were, the match score, the date applied, your next action, and whether you archived it. |
| Timeline | Every status change and any note you write on an application. |
| Contacts | Recruiters, hiring managers and referrers you add: name, title, email, phone, LinkedIn, relationship and your free-text notes. These are people who are not Crossing users — see §16. |
| Interviews | Round, date and time, duration, location, the names of your interviewers, your prep notes, the outcome and any feedback. |
| Documents | Cover letters, tailored résumés, outreach messages and notes, in full. |
| Tasks | Title, due date, completion date. |
| Apply receipts | For every hand-off: the employer, the ATS vendor, the apply URL, which résumé was attached, a fingerprint of that résumé, the full set of questions the employer asked and the values that were filled in for them, whether you skipped review, and the timestamps at which the plan was prepared, opened and confirmed. |
| Apply runs | Each queue session and, per job in it, the outcome: opened, skipped, saved for later, needs a click, or failed. There is no "submitted" outcome, because there is no submission. |
| Tailored bullets | For each (résumé, job) pair: your original bullet, the rewritten version, and a one-line reason for the change. |
Browsing signals
| What | Detail |
|---|---|
| Jobs viewed | One row per job you open, with the time. This is a per-user browsing history of the board. It drives the "viewed" badge and your weekly activity chart. |
| Jobs saved / hidden | Which jobs, plus your note, folder or reason. |
| Match scores | Your score for a job, the breakdown that produced it, and the keywords you were missing. |
| Saved searches | The search name and its filters — which can encode your target salary, regions and titles — plus whether you want alerts and how often. |
Messages we generate
Every welcome email, saved-search alert, weekly digest and reminder is stored in full — recipient address, subject, and the complete HTML and text bodies, which include job titles and tracker contents. Today there is no email transport configured, so this store is the mail system: messages are written and rendered locally, and nothing is delivered. Unresolved: REVIEW: the moment an email provider is connected, that provider becomes a processor and must be named in §8, and this paragraph must be rewritten.
Billing
Plan, status, provider, and the provider's customer and subscription identifiers. No card details exist anywhere in Crossing — there is no card field in the product and no card column in the database. See §8.4.
API keys
If you create an API key: its name, the first six characters (shown so you can tell keys apart), a one-way hash of the secret, when it was last used, how many requests it has made, and whether it is revoked. The secret itself is shown to you once and is not recoverable afterwards.
What we do **not** have
There is no analytics product, no advertising pixel and no third-party script loaded anywhere in the application — we checked, and there are none. There is a table in our database designed to hold an audit trail of user actions with IP addresses; nothing writes to it and it is empty. We are naming it here rather than claiming an audit trail we do not keep.
3Where the data comes from
- You type it — account, profile, tracker, contacts, interviews, notes, apply-profile fields.
- We extract it from a résumé you uploaded — the parsed contact block, skills, employers, dates.
- We compute it — match scores, missing keywords, seed values for the apply profile.
- We observe it from your requests — the session IP and user-agent, sign-in times, which jobs you opened.
- We fetch it from public sources — the job postings themselves. Job data contains no personal data about you.
4Special-category data: race, ethnicity, gender, veteran status, disability
US employers routinely attach voluntary EEO questions to their application forms. Crossing has to have a position on them, and this is it.
The default is that we hold nothing
Your apply profile is created with the demographic setting "ask me", and the four fields — gender, race/ethnicity, veteran status, disability status — are created empty. They are not seeded from anything. In "ask me" mode Crossing leaves those questions blank on every prepared form; you answer them on the employer's own page, or you do not answer them at all.
We never infer them
This is not a promise about intent, it is a property of the code. The only function in Crossing that reads those four fields takes no résumé and no profile text as an argument — there is literally nothing for it to infer from. Demographic questions are routed away from every other answer-filling path before any of them can run, and a question counts as demographic based on the employer's own field name or printed label, so an unusually-worded question still lands in the demographic path.
The three settings, and exactly what each one does
| Setting | What Crossing does |
|---|---|
| Ask me (the default) | Leaves the question blank. Nothing is stored, nothing is filled in. |
| Decline | Selects the employer's own "I don't wish to answer" option, matched against the labels that employer publishes. If that employer offers no such option, the field is left blank. We do not invent a refusal or type free text into a form. |
| Use my saved answers | Fills in what you saved — but only if your saved wording matches one of this employer's published options. If it does not match, the field is left blank rather than being nudged onto a nearby option. |
They are only ever written from your own settings
There is exactly one code path that can write those four fields, and it is reachable only from your own settings screen. Nothing else in the product — not the résumé parser, not the seeding logic, not the AI — can put a value there.
They are never learned and never carried to the next employer
Two independent guards stop a demographic answer from entering the remembered-answers store, so an answer you gave one employer is never replayed to the next one. Work-authorisation and sponsorship answers are protected the same way, so a stale remembered "Yes" can never override what your profile currently says.
They never block you
If an employer marks a demographic question as required, Crossing still lets you proceed. Declining or skipping costs you nothing.
They are never sent to an AI provider
No prompt anywhere in the product reads those fields. See §5.
Where they can end up
If you choose "Use my saved answers" or "Decline", the resulting value is written into that application's receipt (so you have a record of what was prepared) and shown to you on the review screen. It reaches the employer only if you carry it there yourself, on the employer's page.
Legal basis and withdrawal
Where GDPR applies, we process these four fields on the basis of your explicit consent under Art. 9(2)(a). Consent is given by you switching the setting away from "ask me" and typing a value; there is no other route in.
To withdraw: set the mode back to "ask me" and clear the fields in Settings → Apply profile, or delete your account. Withdrawing is immediate and has no effect on anything else in the product. Withdrawal does not undo processing that already happened — most importantly, it does not retract an answer you already sent to an employer from the employer's page.
Two things that are *not* handled this way, and you should know it
- Pronouns are treated as ordinary profile data, not as a demographic field. If you fill them in, they can be filled into employer forms and are remembered across employers like any other identity answer. Some people reasonably consider pronouns sensitive; our code does not gate them behind the demographic setting. If that matters to you, leave the field empty. Unresolved: REVIEW: a product decision, not a legal one — consider moving pronouns behind the same opt-in gate as the demographic fields.
- Work authorisation and sponsorship are stored as a three-state answer: yes, no, or not asked yet. They are ordinary personal data, not special category. There is one safeguard worth naming: when an employer splits "Yes, I need sponsorship" into several specific visa categories, Crossing chooses none of them and leaves the field blank — because picking one would put a specific immigration claim on your application that you never made.
5Your résumé, tailoring, and AI
What tailoring actually does
Tailoring reorders and rephrases your own bullet points against a job posting. The model is given a set of your bullets and returns a patch keyed to those bullets' ids — employers, job titles, dates and degrees are structurally not part of what it can write, because they are not in its output vocabulary. Every rewrite is shown to you as original → improved → why, and rewrites that fail our checks are rejected before you see them.
No AI provider is configured today
As the product stands, no model provider is configured, nothing is sent anywhere, and every AI feature runs a local, deterministic code path on our own server. That is the shipped default, not an error state.
If a provider is configured, this is exactly what would be sent
| Feature | What goes to the model |
|---|---|
| Résumé parsing | The résumé text itself, plus the name, email, headline, skills, titles and employers our local parser already extracted. This is the largest disclosure in the product. |
| Tailoring | Up to ten of your own résumé bullet points, plus facts about the job posting and the keywords it wants. |
| Cover letters | Your name, current title, years of experience, up to 24 skills, your headline and summary, up to three roles with employer, title, dates and three bullets each, plus any notes you write and the job posting. |
| Outreach drafts | The contact's name, your title, your headline and the skills you have in common. No résumé body. |
| Job briefs, company briefs, interview prep | The employer's own posting text only. No data about you. |
Never sent to a model provider, under any feature: your email address, your phone number, your postal address, your links, your work-authorisation answers, and any demographic answer. No prompt in the product reads those fields.
Model responses are cached so the same request is not paid for twice. Read §11 before assuming that cache goes away when you do.
Which providers could be used
If a provider is configured, it would be one of:
- Anthropic — the Claude API.
- Any OpenAI-compatible endpoint the operator chooses — Groq, Cerebras, DeepInfra, OpenRouter, or a self-hosted server are the documented examples. The host is entirely the operator's choice.
- A local model running on the same machine as Crossing, in which case nothing leaves that machine.
This list can change. If it does, we will update §8 before the change takes effect, and the change will be visible in this document's "last updated" date.
6The hand-off: what leaves Crossing and enters an employer's system
This is the boundary that matters most, so here it is without hedging.
- Crossing reads the employer's published application form through the applicant-tracking system's public interface. This is a read. Nothing about you is sent during it — the request carries a board name and a posting id, nothing more.
- Crossing builds a plan: each question the employer asks, and the value it proposes to fill in, with where that value came from and how confident it is. You review it. You can change anything.
- Crossing writes a receipt of that plan to your own account.
- Crossing opens the employer's own application page in your own browser.
- From that moment you are on the employer's site. The employer and their applicant-tracking system see your IP address, your browser, and everything you enter. What happens to your application from there is governed by that employer's privacy policy and their ATS's — not by this one. We have no visibility into it, no copy of what you finally submitted, and no ability to retract it.
- If you tell Crossing you pressed Send, we mark the application as submitted in your tracker. That is our record of what you told us. It is not confirmation from the employer.
Applicant-tracking systems whose forms Crossing can read include Greenhouse, Lever, Ashby, Workable, Rippling and Personio. Reading their public postings does not send them anything about you.
Note on résumé attachments: Crossing does not upload your résumé file to an employer or to an ATS. The file stays in your account; you attach it on the employer's own page, like anyone else.
7What we never do
- We never submit an application. There is no submit path in the product, no network call in the apply engine, and no "submitted" state in the code that records what happened to a job. Every outcome we can record is opened, skipped, saved for later, needs a click, or failed.
- We never sell your personal information, and we never share it for cross-context behavioural advertising. There is no advertising in the product and no data-broker relationship of any kind.
- We never post, message or apply as you. Crossing does not have your credentials for any job board, ATS, or social network, and never asks for them.
- We never contact employers, recruiters or your current employer on your behalf. Crossing sends no email to anyone but you.
- We never infer your race, ethnicity, gender, veteran status or disability from your résumé or anything else. See §4.
- We do not run background checks or verify anything you tell us. See §14.
8Third parties
8.1 Job sources (no data about you)
To build the job board we fetch public listings from job aggregators and public ATS boards. These are unauthenticated requests for public pages. Nothing about you is sent — the only identifying thing in the request is our own software's user-agent string, which contains an operator contact address, not yours.
Sources currently include RemoteOK, Remotive, We Work Remotely, Himalayas, Jobicy, Arbeitnow and Hacker News, plus public ATS boards on Greenhouse, Lever, Ashby, Workable, Recruitee, SmartRecruiters, Rippling and Personio. The list changes as sources come and go.
8.2 Reading employers' application forms (no data about you)
Covered in §6. Restricted by a hard allowlist of hosts checked before any connection is opened; HTTPS only; every call is a read.
8.3 AI providers
None today. Covered in §5.
8.4 Payments
If paid plans are enabled with Stripe, one request goes to Stripe when you start a checkout, carrying your email address, your internal account id, and the plan you selected. Nothing else. Card details are entered on Stripe's own hosted page and never pass through Crossing.
8.5 Email delivery
None today — messages are generated and stored, not sent. See §2.
8.6 Adding a job by URL
If you paste a job URL for Crossing to import, our server fetches that URL, which discloses our server's address to that site. Nothing about you is sent. The fetcher is hardened against being pointed at internal addresses.
8.7 Company logos load from third-party servers — a real disclosure
Company logos on the board are loaded directly by your browser from third-party hosts we do not control. Those hosts therefore see your IP address, your browser's user-agent and the page you were on. This is not a transfer we make on our servers; it is a disclosure your browser makes on our pages, and we would rather name it than let you discover it in a network tab.
Subprocessor list
| Party | Purpose | Personal data it receives |
|---|---|---|
| Unresolved: REVIEW: hosting provider | Running the application and storing the database | All of it, as the host |
| Stripe | Payments, if enabled | Email address, account id, plan |
| Unresolved: REVIEW: AI provider, if any | Résumé parsing, tailoring, cover letters | See §5 |
| Unresolved: REVIEW: email provider, if any | Delivering alerts and digests | Email address, message contents |
We will keep this list current. If we add a subprocessor that receives your personal data, we will update this table and the "last updated" date above.
9Cookies, local storage and shareable links
Cookies. Crossing sets one cookie: your session cookie. It is signed, HTTP-only (unreadable by JavaScript), same-site, marked secure in production, and expires after 30 days. It is strictly necessary to keep you signed in. There are no analytics, advertising or tracking cookies, and no third-party scripts.
Your browser's local storage. We keep a few interface preferences in your own browser — light or dark theme, whether the sidebar is collapsed, whether you have seen the first-run tip, and your recent searches in the command palette. This never leaves your device and clearing your browser data removes it.
Shareable links you can create. Two features issue an unguessable link that works without signing in, because the tools that consume them (calendar apps, feed readers) cannot carry a login:
| Link | What it exposes | Controls |
|---|---|---|
| Interview calendar feed | Your scheduled interviews — job title, company, time, location, interviewers' names and your prep notes | Anyone with the link can read it. One click in Settings → Data issues a new link and kills the old one instantly. |
| Saved-search feed (RSS/JSON) | The results of that one saved search | Reveals nothing else: it cannot read your tracker, cannot write anything, and cannot be traded for a session. |
Treat both like a password. If you paste one somewhere public, rotate it.
10Legal bases (GDPR / UK GDPR)
| What we do | Basis |
|---|---|
| Create your account, sign you in, keep a session | Contract (Art. 6(1)(b)) |
| Store your profile and résumés, score jobs, tailor résumés, prepare application forms | Contract (Art. 6(1)(b)) — this is the service |
| Keep receipts of applications you handed off | Contract, and our legitimate interest in you having a reliable record of what you sent to whom (Art. 6(1)(f)) |
| Record which jobs you viewed | Legitimate interest (Art. 6(1)(f)) — it powers the "viewed" badge and your activity chart. You can object; see §12. |
| Send you alerts and digests you asked for | Contract, and your settings |
| Security, abuse prevention, rate limiting, keeping session IPs for 30 days | Legitimate interest (Art. 6(1)(f)) |
| Payments | Contract, and legal obligation for tax records |
| Race, ethnicity, gender, veteran status, disability | Explicit consent (Art. 9(2)(a)) — see §4 |
| Sending your résumé bullets or text to an AI provider, if one is configured | Contract — it is the feature you invoked. Unresolved: REVIEW: consider making AI features an explicit opt-in toggle rather than relying on contract necessity; it is a stronger position and a better product. |
| Keeping short excerpts of rejected AI rewrites for quality control | Legitimate interest (Art. 6(1)(f)) — see §11 |
11How long we keep things — including what survives deletion
Deleting your account
Settings → Account → Delete. You must type your own email address to confirm. Your session is destroyed and your account row is deleted immediately. There is no soft delete, no grace period and no anonymised tombstone. We cannot restore an account after deletion.
Deleting your account removes, in the same operation: your sessions, profile, every résumé including the original uploaded files, tailored bullets, saved and hidden jobs, your job-view history, match scores, saved searches, notifications, generated messages, applications and their timelines, contacts, interviews, documents, tasks, subscription record, usage counters, API keys, your apply profile including every demographic value, remembered answers, every application receipt, and every apply-run record.
What survives deletion — stated plainly
We would rather tell you than let you assume otherwise.
- Cached AI output. When an AI feature runs, its response is cached under a one-way fingerprint of the request. Those cache rows have no link to your account, so deleting your account does not delete them, and there is no expiry on them today. For résumé parsing, a cached row is your structured résumé — name, email, phone, location, headline, employers. Nobody can look a row up by user, but anyone with access to the database can read it. This is the most significant gap in our deletion story, and it only applies if an AI provider has been configured — with the current default configuration nothing is ever written to that cache. Unresolved: REVIEW: fix this before enabling any AI provider. A per-user purge on deletion, or a TTL, or simply not caching résumé parses, would close it. A function to clear the cache already exists in the code and is never called. Until it is fixed, this paragraph must stay exactly as blunt as it is.
- Rejected AI rewrites. When a proposed rewrite of one of your bullets fails our quality checks, we keep up to 200 characters of the original bullet and of the rejected rewrite, so we can tell whether the checks are working. These records are deliberately designed to outlive the account they came from; on deletion, the link to your account is severed but the text excerpt remains. Unresolved: REVIEW: a deliberate measurement decision that needs a decision from you: keep it and defend the legitimate interest, or delete these rows on account deletion too. As written it is a real, disclosed retention of personal data past an erasure request, and a regulator would want to see the balancing test.
- Notification preference rows keyed by your account id survive deletion, leaving the id behind with no account attached to it. The same applies to a calendar-feed link if you created one — the link's record survives, though the interviews it would have shown are gone. Unresolved: REVIEW: a one-line fix in the deletion routine. Do it, then delete this paragraph.
Retention for everything else
| Data | How long |
|---|---|
| Sessions (including the IP) | 30 days, then deleted. Expired sessions are cleared when they are next touched, and in bulk on a scheduled sweep. Unresolved: REVIEW: that sweep only runs if the operator schedules it. Schedule it, or this is a 30-day promise the deployment does not keep. |
| Password reset tokens | 60 minutes, or until the link is used — whichever comes first |
| Prepared-but-abandoned application plans | 24 hours |
| Everything about a hand-off you actually made | Kept for as long as your account exists. A hand-off is a record of something that happened with a real employer, and we do not quietly expire it. |
| Job postings | Marked inactive when stale; the posting itself is kept |
| Job-view history, notifications, generated messages, apply runs, tailored bullets, match scores, application timelines | Kept for as long as your account exists — no automatic expiry today |
12Your rights and how to use them
Where GDPR or UK GDPR applies you have the rights to access your data, correct it, delete it, restrict or object to processing, port it elsewhere, and withdraw consent for anything based on consent. We do not make decisions with legal or similarly significant effects about you by automated means — Crossing scores and ranks jobs for you; it does not decide anything about you, and nobody else uses its scores to decide anything about you.
What you can do right now, without asking us
| Right | How |
|---|---|
| Access / portability | Settings → Data → Download everything (.json), or GET /api/export/data.json. It is versioned and self-documenting. |
| Your original résumé files | Download each résumé from its own page — the export JSON carries résumé text, not the file bytes. |
| Applications, jobs, interviews | CSV exports of the tracker and board, and an .ics calendar of interviews. On the Free plan the two CSVs carry your 25 most recent rows and say so in a response header rather than truncating silently; a finished apply run always exports in full. |
| Correction | Edit anything in Settings, your profile, your apply profile or the tracker. |
| Withdraw demographic consent | Settings → Apply profile: set the mode back to "ask me" and clear the fields. |
| Deletion | Settings → Account → Delete account. Immediate and permanent. |
What the self-serve export does **not** yet include
Being straight about this, because it is the part you would most want in an access request: the JSON export currently omits your apply profile (so your phone, postal address, work-authorisation answers, pronouns and any demographic values), your remembered answers, your application receipts — the record of exactly what was filled in for which employer — your apply-run history, tailored bullets, job-view history, hidden jobs, match scores, notifications, generated messages, API key metadata, and sessions.
If you want any of that, ask us and we will produce it.
Asking us directly
Write to Unresolved: REVIEW: contact email. We will respond within one month, as GDPR requires, and will tell you if we need to extend that. We may ask you to confirm you control the account's email address — that is identity verification, not obstruction.
Complaints
If you think we have handled your data badly, tell us first — we would rather fix it. You also have the right to complain to your data protection authority: in the EU, the supervisory authority where you live or work; in the UK, the Information Commissioner's Office. Unresolved: REVIEW: name the lead supervisory authority once establishment/representative is settled.
13California residents (CCPA / CPRA)
We do not sell your personal information, and we do not share it for cross-context behavioural advertising. We have not done so in the preceding 12 months. There is no advertising, no ad network, no data-broker relationship and no tracking pixel in this product. Because we do not sell or share, there is nothing for a "Do Not Sell or Share My Personal Information" link to switch off — but we will keep saying so here in plain terms.
Categories of personal information collected, in the statute's own terms:
| CCPA category | Do we collect it? | What |
|---|---|---|
| Identifiers | Yes | Name, email, phone, postal city/region/country/ZIP, account id, IP address |
| Customer records (Cal. Civ. Code §1798.80) | Yes | Employment history, education, phone, address — from your résumé |
| Protected classifications | Only if you opt in | Race, ethnicity, gender, veteran status, disability — see §4 |
| Commercial information | Yes | Plan and subscription status |
| Internet activity | Yes | Which jobs you viewed, saved, hid; searches you saved |
| Geolocation | Coarse only | The city/region/country you type; no precise location, ever |
| Professional or employment information | Yes | The whole résumé and application history |
| Education information | Yes | Schools and degrees parsed from your résumé |
| Inferences | Yes | Match scores and missing-keyword lists |
| Sensitive personal information | Only if you opt in | The demographic fields above |
Sensitive personal information. The only sensitive personal information we hold is the four demographic fields, and only if you choose to save them. We use them for exactly one purpose: filling in the employer question you asked us to fill in. We do not use or disclose sensitive personal information for any purpose that would require offering you a right to limit its use under §1798.121 — but if you want it gone, clear the fields, and it is gone.
Your rights: to know, to access, to delete, to correct, to opt out of sale/sharing (nothing to opt out of), to limit use of sensitive information, and not to be discriminated against for exercising any of them. Our plans do not vary by whether you exercise a privacy right. Use the self-serve tools in §12, or write to us. You may use an authorised agent; we will ask for proof of their authority.
Retention: stated by category in §11.
14Crossing is not a consumer reporting agency
Stating this explicitly, because it matters for a product in the hiring space.
Crossing is a tool you use to look for work. It is not a consumer reporting agency as defined by the US Fair Credit Reporting Act, and it does not assemble or evaluate information about you for the purpose of furnishing consumer reports to anyone.
- We do not run background checks, credit checks, criminal-records checks, employment verification or reference checks, and we do not verify anything on your résumé.
- We do not sell, license or otherwise provide information about you to employers, recruiters, background-check companies or anyone else.
- Our match scores are a search-ranking aid shown to you. They are never shown to an employer, never sent to one, and are not intended or authorised for use in any decision about your eligibility for employment, credit, insurance or housing.
- We do not make employment decisions and we do not participate in them. Every application is submitted by you, on the employer's own site.
Nothing in Crossing is an automated employment decision tool.
15Security
- Passwords are stored only as hashes.
- The session cookie is signed, HTTP-only, same-site and marked secure in production. Sessions expire after 30 days.
- API keys are stored only as hashes; the secret is shown once.
- Every database query for your data is scoped to your account id, including when reading child records — a résumé file, for example, can only be read through a query that joins back to your own account.
- Requests our server makes on your behalf ("add a job by URL") are hardened against being redirected at internal or private addresses.
- Outbound connections to applicant-tracking systems are limited to a fixed allowlist of hosts, HTTPS only, checked before a connection is opened, with size and time limits.
- Feature endpoints are rate limited.
No system is perfectly secure, and we will not claim otherwise.
16Other people's data — recruiters, hiring managers, interviewers
Your tracker lets you store contacts (name, title, email, phone, LinkedIn, relationship, your notes) and the names of your interviewers. Those people are not Crossing users and have not agreed to anything with us.
- We use their details for one purpose only: showing them to you in your own tracker, and — if you ask for an outreach draft with an AI provider configured — using the contact's name in that draft.
- We never contact them. We do not add them to any list, send them anything, or use their details for any purpose of our own.
- Their details are deleted when you delete the contact, or when you delete your account.
- Please only store what you actually need, and treat it as you would want your own details treated.
17International transfers
18Children
Crossing is for adults looking for work. It is not directed at children, and you must be at least 18 to create an account. We do not knowingly collect personal data from anyone under 18; if we learn we have, we will delete it.
19Changes to this policy
If we change this policy we will update the date at the top. If the change is material — a new subprocessor receiving your data, a new purpose, an AI provider being switched on — we will tell you in the product before it takes effect, not merely edit this page.
20Contact
Unresolved: REVIEW: contact email Unresolved: REVIEW: postal address Unresolved: REVIEW: EU/UK representative, if appointed