Job listings, sources and takedown

For each posting: the title, company, location as published, salary range if the source published one, employment type, tags, posting date, the description, the source's own URL for the posting, and the apply URL. Descriptions are stripped down to a safe subset of HTML before display, and links inside them are marked nofollow noopener and open in a new tab.

We also store, per posting, aggregate counters — how many times it was viewed, saved, or marked as applied to. These are counts, not a list of people.

We do not receive, store or process candidate data from any source. Nothing flows back to a source: these are reads.

Every listing shows which source it came from ("Via …"), and every listing carries a direct link to the original posting — a plain link to the source's own URL, with no redirect, no interstitial and no tracking hop in between. That link is a normal followable link; we do not mark source links nofollow.

Several of our sources require exactly this, and the details of their terms differ:

• Remote OK requires anyone using its API feed to name Remote OK as the source and to link back to the listing's URL on Remote OK with a direct link, no redirects, on the page or app screen where the data is used — and says API access is suspended otherwise.
• Remotive requires a mention plus a link back to the URL on Remotive, recommends no more than a few API calls a day, blocks callers who exceed roughly two requests a minute, and delays feed jobs by 24 hours specifically so that attribution works.
• Jobicy asks for attribution back to Jobicy.com and asks that its listings not be redistributed to other job platforms. For Jobicy rows the apply button deliberately points at the original Jobicy URL rather than resolving through to the employer.
• Arbeitnow asks for a link back to arbeitnow.com and points at German and EU law (UWG, BDSG, GDPR).

Two honest gaps we found while writing this, both cheap to fix and both worth fixing before launch:

1. The source label is auto-generated. A generic title-caser turns the internal source id into a display name, so Remote OK renders as "Remoteok". If a board's terms require you to name them, naming them correctly is the least of it. Unresolved: REVIEW: add a display-name table for sources.
2. The link back is one level too deep. "View original posting" currently lives in an overflow menu on the job detail page. Remote OK's wording — "on the page or app screen where you use the data" — reads like it should be visible on the card. Unresolved: REVIEW: surface the source link on the job card.

Job titles, companies, locations and salary bands are facts. A well-written job description is somebody's writing, and may be protected by copyright. Trademarks, logos and company names belong to their owners; showing them identifies whose job it is, and is not a claim of affiliation, sponsorship or endorsement in either direction.

What we do with that: we index, we attribute, and we link through to the original, and applications happen on the employer's site. What we do not do: claim ownership of any posting, sell postings as our own content, or present a company's material as ours.

Crossing is an index of other people's data, refreshed on a schedule. So:

• A posting may already be filled or closed. We re-check sources on the schedule above; a posting stops appearing 30 days after we last saw it in its source, or on the expiry date the source published, whichever comes first.
• Details may be wrong at the source. Salary, location, remote status, seniority and employment type are shown as the source published them. Where a source omits something, we leave it blank rather than inventing it.
• Some sources publish noise. One feed regularly leaks page fragments into the title field; we filter what we can recognise, imperfectly. The Hacker News rows are parsed out of free-form comments written to a loose convention, so their fields are a best-effort reading of a human's line of text.
• Deduplication is a judgement call. The same job can arrive from several sources; we merge on the source we trust more. That means the row you see may not be the version you would have seen on your preferred board.
• Match scores rank jobs for you. They are a ranking of postings against your résumé, not an assessment of you, not a prediction that you will be hired, and not something any employer sees.
• A listing is not a recommendation, a verification or an endorsement. We do not vet employers, we do not verify that a company exists, and we do not confirm that a role is open.

Recruitment fraud. Fake job postings are a real and growing category of fraud. A legitimate employer will not ask you to pay for equipment, training, a background check or a "starter kit", will not ask for bank details or identity documents before an offer, and will not interview you only over a chat app. If you see a posting in Crossing that looks like this, report it — see below — and report it to the source board as well.

Who can ask. The employer whose job it is; the board or applicant tracking system it came from; or an individual named in a posting (a recruiter's name, direct email or phone number in a job description, for example).

Where to send it. Unresolved: REVIEW: takedown contact address — a monitored inbox, published here and in security.txt.

What to include, so we can act on the first email rather than the third:

• The Crossing URL of the listing (or the search that finds it), and the URL on the original source.
• Who you are and your relationship to the posting or the company.
• What you want: removal of one posting, removal of all postings for a company, or removal of a whole source.
• The basis: copyright, an inaccurate or fraudulent listing, a personal-data request, a terms restriction, or simply that you would rather not be indexed. "We would rather not be indexed" is enough. We are not going to litigate an employer's preference about their own jobs.

What we do.

• Acknowledge within Unresolved: REVIEW: pick a number you can keep — 3 business days.
• Deactivate the listing so it stops appearing, and suppress it from future ingests so the next poll does not simply bring it back. Unresolved: REVIEW: a per-posting and per-company suppression list is not built yet. Today an operator can disable an entire source or purge stale rows, which is a blunter instrument than a takedown deserves. Build this before launch.
• If the request comes from a source board, we can switch that source off entirely, immediately.
• Tell you what we did.

What removal does not do. Removing a listing from Crossing does not remove it from the board or the employer's careers site, and does not affect anything a user already saved, applied to, or exported into their own tracker. If the posting should not exist anywhere, the source is the place to go.

Copyright complaints (DMCA). If you believe a description we display infringes your copyright, send a notice with: your contact details, identification of the work, identification of the material on Crossing and enough detail to find it, a statement of good-faith belief that the use is not authorised, a statement under penalty of perjury that the notice is accurate and that you are authorised to act for the owner, and your signature. We will remove or disable the material and notify whoever supplied it. A counter-notice can be filed and, if no action is brought, the material may be restored after the statutory waiting period.

Personal data in a posting. If a listing contains your personal data — your name, your work email, your phone number — and you want it removed, say so and we will remove it. You do not need to establish a legal basis and we will not ask you for one. Unresolved: REVIEW: this route also needs to be reachable from the privacy policy's rights section.

The in-app "Report posting" button — an honest note. There is a report action on every listing. Today it hides the posting for the person who pressed it and records their reason; it does not open a ticket, and no one reviews a queue, because there is no queue yet. Until there is, email is the real channel for anything that needs a human. Unresolved: REVIEW: build the operator triage queue before launch, and delete this paragraph when it exists.

• To get your board indexed: Unresolved: REVIEW: no self-serve process exists. Decide whether to offer one, or to keep the source list curated and handle requests by email.
• To correct data: correct it at the source. We re-poll on the schedule above and the correction will flow through; if it does not, tell us and we will look at why.
• To be excluded permanently: email us. We will suppress the company and keep the suppression in place across future ingests. Unresolved: REVIEW: depends on the suppression list above being built.

Ordered roughly by whether it blocks a public launch.

Needed before launch

• Real contact addresses and a legal entity. Every document in this set has a Unresolved: REVIEW where a company name, address, privacy contact, security contact and takedown contact should be. Nothing ships until those exist.
• Feed terms review. Per-source, in writing — Remote OK, Remotive, Jobicy, Arbeitnow, We Work Remotely, Hacker News. Remotive is the sharpest conflict with a paid product. Get permission, get a paid API, or drop the source.
• Set the outbound user-agent to the real domain and a monitored inbox.
• Attribution fixes: correct source display names, and put the "original posting" link where it can be seen.
• Takedown plumbing: per-posting and per-company suppression, plus an operator queue behind the report button.
• Security headers and secrets hygiene: CSP, HSTS, nosniff, frame-ancestors, referrer policy; and a hard gate that refuses to boot with the development session secret or cron secret. See the security policy.
• Incident-response and breach-notification runbook (GDPR Art. 33's 72-hour clock is not something to improvise), plus a data-processing record (Art. 30).
• Fix the deletion gaps named in the privacy policy — the model cache and the guard rejection log currently outlive the account.
• Email sender authentication (SPF, DKIM, DMARC) before any mail leaves a real transport. Today every message is written to an in-app outbox and nothing is actually sent.
• Payments: the billing integration has no webhook, so a completed payment does not activate a plan. That is a functional blocker, not a legal one, but it lands in the same launch.

Needed at launch, or very shortly after

• Subprocessor list page. Today it is genuinely short — a hosting provider, possibly a payment processor, possibly a model provider. Publishing a short list is a stronger trust signal than publishing none, and enterprise buyers will ask for it. Commit to notifying before adding one.
• Data Processing Addendum for any business customer with EU/UK staff, with the current Standard Contractual Clauses annexed, plus the UK Addendum. Needed the first time a company pays for seats.
• Model-provider disclosure. No model provider is configured today and every AI feature has an offline path. The moment one is configured, the privacy policy and the subprocessor list must name it and say exactly what leaves the machine — résumé text for parsing, your own bullets for tailoring, a summary of your background for cover letters.
• security.txt at /.well-known/security.txt pointing at the security contact, plus a PGP key.
• Accessibility statement. WCAG 2.2 AA as the target, an honest list of known gaps, and a contact for accessibility problems. In the EU the European Accessibility Act now reaches consumer-facing services, and in the US a job-search product excluding disabled users is both a legal and a moral problem. Unresolved: REVIEW: an accessibility remediation pass has been done on other projects; get a real audit here.
• Robots and sitemap. Neither robots.txt nor a sitemap exists. Decide what should be indexable — in particular whether individual job pages should be, given the sources' attribution terms.
• Age gate and minimum age, consistent across the Terms and the signup flow.

Later, or when a specific customer asks

• Status and uptime page. Not credible pre-launch; a "we don't promise uptime yet" line in the Terms is more honest than an SLA nobody can meet. Add the page when there is a service to measure. Unresolved: REVIEW: no SLA until there is monitoring.
• Imprint (Impressum). Required for services directed at Germany — §5 DDG. Worth flagging because one of our sources is German and German-language postings will pull German traffic. Needed if we market into Germany; the trigger is intent, not accident.
• EU representative (GDPR Art. 27) if we target EU users without an EU establishment, and a DPO assessment (almost certainly not required at this scale, but record the reasoning).
• Compliance artefacts — SOC 2, penetration test, security questionnaire answers — when the first buyer that needs them appears, not before.
• Refund and cancellation policy, and a statement of what happens to your data when a subscription lapses.
• Complete the data export. The current export is missing the apply profile, learned answers, apply receipts, queue history, view history, notifications and the original résumé bytes. That is a real GDPR Art. 15/20 gap and it should be closed by engineering rather than papered over.