Confirming candidate country without location permissions

01 The approach: a two-stage check

Capture the network country when the candidate clicks Continue, then ask them to declare their country later in the application, and compare the two on submission. The browser Geolocation API and GPS are never used, so there is no permission popup — yet the comparison still separates honest answers from convenient ones.

02 Decision rules

The comparison is a plain table — no triangulation, no scoring model. Only the country pair and the whitelist matter.

Do not reveal which country was detected, and never accuse or reject automatically on a mismatch — VPNs, travel, corporate networks and mobile roaming all produce legitimate discrepancies.

03 Result taxonomy

One enum recorded per submission, alongside both country codes:

type LocationCheck =
  | "MATCH"
  | "MATCH_LOW_CONFIDENCE"
  | "MISMATCH"
  | "UNVERIFIABLE"
  | "INCOMPLETE";

04 Implementation notes

The core check is a few lines. Server-side only — no browser Geolocation API, no GPS, no client-side geo API:

// Cloudflare Worker — swap the first line for your host's header if not on CF
const resolvedCountry =
  typeof request.cf?.country === "string"
    ? request.cf.country.toUpperCase()
    : null;

const claimedCountry =
  form.claimedCountry?.trim().toUpperCase() || null;

const locationCheck =
  !claimedCountry                            ? "INCOMPLETE"
  : !resolvedCountry ||
    resolvedCountry === "XX" ||
    resolvedCountry === "T1"                 ? "UNVERIFIABLE"
  : claimedCountry === resolvedCountry        ? "MATCH"
                                              : "MISMATCH";

Where the country comes from

05 What to store

Data minimisation: country is all that is needed, so country is all that is kept. The raw IP is discarded once the country is derived.

{
  "applicationSessionId": "sess_456",
  "candidateToken": "cand_123",
  "resolvedCountry": "IN",
  "claimedCountry": "IN",
  "countryStatus": "MATCH",
  "capturedAt": "2026-09-10T12:30:00Z"
}

06 Candidate-facing copy

The disclosure stays general. It must be transparent enough for the privacy notice to hold up, but must not reveal the whitelist, the matching rule, or the stage at which comparison happens — and it must not nudge the candidate toward any particular answer.

The privacy notice should identify the purpose, the data used, the retention period, the processors, and the review / correction process. Whether consent or another lawful basis is required depends on the jurisdictions involved — have employment and privacy counsel approve the final wording, especially where the result can influence applicant eligibility.

07 Limits and cautions

• This checks the apparent country of the network connection — not residence, citizenship, or the legal right to work.
• Legitimate mismatches are common: VPNs, corporate networks, mobile roaming, travel, privacy relays, and simply wrong IP-geolocation records.
• Never automatically reject an applicant solely on an IP-country mismatch — treat it as a review trigger.
• Never use email-open pixels or the initial link GET to establish country. Apple Mail privacy protection, mail proxies and security scanners fetch pixels and links from locations unrelated to the recipient. Capture only on the deliberate Continue POST and compare only at final submission.
• For legal eligibility: rely on the declaration and attestation first; conduct document / right-to-work verification at the appropriate later stage for shortlisted candidates.
• Counsel review before launch — the check informs eligibility decisions, which raises the bar for notice, lawful basis and correction rights.

That asymmetry is the whole design: a useful inconsistency signal, captured without invasive permission prompts, honest in what it claims, and paired with a human review step instead of an automated gate.