## Physical Business Verification: What the Public Postings Show, and What Three Technical Checks Don't Prove
This is the second of a small set of research pages that do the work an indie developer would actually do before writing code: look at real posted demand, then actually test the tools that would have to do the job, and report what happened — including the parts that don't work.
### 1. Who has this problem, and what are they actually asking for?
Searching the catalog for "site verification, on-site verifier, business verification" style demand turns up three published features built from **65 real, budget-posted freelance tasks** (Freelancer.com, public postings, PII-scrubbed; a frozen snapshot as of 2026-09-10 -- the underlying feature pages have since grown to 69 as new postings arrived, but this article's numbers refer to the fixed 65-task set archived alongside this research) — all traceable to the same real, named requester: **Confirmis**, a Singapore-based business information and trade-intelligence provider. Confirmis posted new one-off "site verifier needed" tasks continuously from July 10 through September 10, 2026 — over two months of repeated demand in the postings we found, not a one-time spike. Representative source postings: [Site Verifier Needed in Paris - France](https://www.freelancer.com/projects/photography/Site-Verifier-Needed-Paris-France), [Site Verification in Dammam, Saudi Arabia](https://www.freelancer.com/projects/photography/Site-Verification-Dammam-Saudi-Arabia-40573670), [Site Verifier Needed in Bengaluru, Karnataka, India](https://www.freelancer.com/projects/photography/Site-Verifier-Needed-Bengaluru-Karnataka).
The pattern is consistent across every posting: hire a local freelancer to go to a specific business address, take photos confirming the business is real and operating, and file a short report. Budgets are mostly $10–95 per assignment (a few run $140–150, and two are INR-denominated equivalents in the $150–450 range). The cities span dozens of countries across every populated continent in the same window: Odessa, Colombo, Takoradi, Istanbul, Al Kharj, Bengaluru, Montevideo, Lviv, Belgrade, Addis Ababa, Szolnok, Hamburg, Wenzhou, Sana'a, Karachi, Selangor, Baghdad, Phuket, Melbourne, Manila, Komotini, Kuala Lumpur, Birgunj, Libya, Verona, Paris, Boca Raton, Miami, several Vietnamese provinces, Seoul, Kuwait City, Chennai — the list goes on.
**An important correction from the first draft of this research: [Confirmis's own website](https://www.confirmis.com/) states it has "more than 6,000 trained site verifiers across the globe."** That is Confirmis's own self-reported figure, not something we independently verified, and their site does not explain how that network is recruited, trained, or dispatched — so it doesn't tell us whether their internal tooling is good, mediocre, or nonexistent. But it directly contradicts an earlier draft of this article, which read the freelance postings as evidence Confirmis has "no standing verifier network" and was running everything "purely by hand." That claim was wrong, or at minimum unsupported — a company can have a large named network and still supplement it with one-off freelance postings for specific cities, urgent turnaround, or coverage gaps, for reasons we don't know. What the postings actually show is **continuous purchasing of on-site verification labor or capacity through the open freelance market** — not the absence of any other system.
### 2. Which of these are actually the same underlying need?
Collapsing the three features by what's actually being asked for, this is a single underlying job at global scale: route a physical verification request to a trustworthy local person, get back photographic proof the business exists and operates at the stated address, and be confident the photos weren't faked or reused. The only real variation visible in the postings is jurisdiction (varying ID/registry quality) and urgency (some postings are marked urgent same-week).
What the postings do **not** tell us, and what a real evaluation of this opportunity would need: how Confirmis's existing 6,000+ verifier network is actually organized (a self-serve app? a call list? regional coordinators?), why they're still posting on the open market if that network already covers these cities, what their internal acceptance rate and turnaround time look like, and what they currently pay per assignment through their own channel versus the open-market rate seen here. None of that is answerable from freelance postings alone.
### 3. Why isn't existing tooling already good enough?
Rather than assume "just check GPS and call it done" (the generic pitch), we built and ran three real technical checks against real inputs. One of them — the tamper-detection check — turned out to be a much narrower experiment than the first draft of this article described, and that correction matters more than any individual number below.
**Geocoding (OpenStreetMap Nominatim, free public API):** tested against 5 real addresses across Singapore, the US, Germany, Japan, and the UK. 4 of 5 succeeded; the UK address (`Unit 4B, 100 Commercial Road...`) returned zero results as submitted. This is a single observed case, not a general finding about Nominatim's handling of unit/suite numbers — we did not test enough addresses to say how often this happens. Similarly, the Singapore address resolved only to road level rather than a specific building — again a single observation, not evidence of a "systematic several-hundred-meter" error across addresses in general.
**EXIF GPS cross-validation:** built test cases — one genuine camera photo with embedded GPS (sourced from the public [ianare/exif-samples](https://github.com/ianare/exif-samples) test-fixtures repository, not a real business-verification photo), two synthetically-tagged photos matching real target coordinates, one deliberately mislabeled photo (claiming Singapore, actually tagged with Kuala Lumpur coordinates), and one photo with GPS stripped entirely. The cross-check logic correctly flagged the mislabeled photo (316.7 km off — an unambiguous mismatch) and correctly reported the no-metadata photo as unverifiable rather than silently passing it. **We did not measure what share of real-world photo uploads retain usable GPS EXIF** — the specific retention percentages and per-platform stripping claims in an earlier draft of this article were not produced by this experiment and have been removed. What we can say concretely: any photo with GPS metadata already stripped (for whatever reason — forwarded through a chat app, re-saved, edited) is unverifiable by this check alone, full stop.
**Follow-up test: how hard is it to fake these tags in the first place?** Using the free command-line tool `exiftool` (one command: `exiftool -GPSLatitude=1.2849361 -GPSLatitudeRef=N -GPSLongitude=103.8504269 -GPSLongitudeRef=E photo.jpg`), we wrote a real target's exact coordinates onto a plain synthetic image that had no GPS data at all beforehand. The command took 0.48 seconds. Running the same distance check against the result: 0.00m from target, reported as VERIFIED_LOCATION. **The EXIF cross-check cannot tell a real photo taken at the location apart from any arbitrary image with the right numbers typed in after the fact** — this was a known, listed-but-untested attack vector in an earlier draft of this article; it is now confirmed.
**Error Level Analysis (image tamper detection) — corrected description of what this experiment actually was:** we implemented ELA from scratch (JPEG recompression difference visualization) and ran it against five images, including two we deliberately edited ourselves (a painted-on fake signage overlay, a solid-color patch covering part of the image). **Important: the script computed compression-difference statistics inside the exact pixel region we ourselves had edited — it did not independently detect or locate any tampering.** There was no localization step, no threshold, and no pass/fail classifier; "which region is suspicious" was an input to the script, not an output. So this experiment cannot support a claim like "ELA correctly identified the tampering" or a false-positive *rate* — nothing was ever classified. What we can honestly report: the compression-difference signature inside a known-edited region differed measurably from the surrounding background in our samples, and a clean, unedited high-contrast graphic (a vector-style sign converted to JPEG) produced a comparably large signature purely from normal compression artifacts — which is a real reason to distrust a naive "big difference = tampering" threshold, even though we never built or tested such a threshold ourselves. Full data and the exact methodology are archived alongside this article.
**Honest bottom line on the technical checks:** geocoding needs address cleanup and shouldn't be trusted at face value below building-level precision; EXIF cross-checking is a real, useful signal only when metadata survives, and we don't know how often it does; and our ELA work, corrected, is a compression-artifact visualization on known regions — a possible aid for a human reviewer, not a tested tamper detector, and definitely not something we can honestly credit with a "detection rate."
### 4. What would a piece of software actually need to do?
Based on the corrected findings in section 3, and treating everything below as an **untested design hypothesis, not a validated recommendation**:
- **An address-normalization layer** (a library like `libpostal`, or a purpose-built regex set) that keeps the full original address on record — including the unit/suite/floor number — while deriving a separate, cleaned query string for the geocoder, with a fallback to a commercial geocoder (Google Places, Mapbox, HERE) for the free API's failure and low-precision cases. - **Live in-app capture instead of photo-library upload**, pulling location from the camera/browser API at the moment of capture rather than trusting EXIF on an already-taken photo. This is a plausible way to reduce (not eliminate) the "upload an old or unrelated photo" failure mode, but we have not built or tested this against any adversarial input — we don't know whether it actually stops a motivated verifier from faking a submission, only that it removes one specific weak point (EXIF that was never trustworthy to begin with). - **A dynamic physical challenge issued per-assignment** (e.g. "hold up a card showing code CF-8492 next to the storefront sign") — a design idea that, on paper, would defeat simple photo reuse and screen-replay attacks. We have not built or tested this either. Untested attack vectors that a real implementation would need to account for before making any claim about effectiveness: an old photo of the actual location combined with a printed or digitally-composited code card (harder to fake than GPS coordinates alone, since it requires the code text to actually appear in the image, not just a metadata field — but not tested here), a genuine visit paired with a staged prop, and ordinary user error (wrong code, blurry card, refusal, reshoot cost and cost to the assignment timeline). One adjacent attack **is** now confirmed rather than assumed: see the EXIF forgery test in section 3 — that one command execution took under half a second with a free tool (not a claim about how long defeating a full verification flow would take end to end), which is exactly why this section's challenge-code design leans on something visible in the photo's actual pixels, not a metadata field alone. Mock GPS apps and screen-replay attacks remain untested by this research; confirming one cheap attack against one passive check is not the same as a full adversarial test of the design above. - **A real independent tamper-detection step**, if image forensics are wanted at all — meaning an actual localization/classification model or algorithm evaluated on samples it wasn't told the answer to in advance, not the known-region visualization we ran here. - **Human review as the default for anything ambiguous**, given that none of the three checks above is validated as an automatic accept/reject signal.
None of this should be read as "the answer" — it's the list of untested engineering questions this research surfaced, not a proven design.
### 5. What we know, what we're inferring, and what's still unverified
| Item | Status | |---|---| | Confirmis posts recurring, city-by-city verification tasks on the open freelance market ($10–95 typical, dozens of countries, 2+ months continuous) | **Fact** — directly observed in 65 sourced postings | | Confirmis operates a network of 6,000+ trained verifiers | **Fact, self-reported** — Confirmis's own website; scale and actual dispatch mechanics not independently verified | | Confirmis relies solely on ad-hoc freelance hiring with no standing network | **False** — contradicted by Confirmis's own site; earlier draft of this article stated this incorrectly | | Why Confirmis still posts on the open market despite an existing network (coverage gaps? urgency? cost?) | **Unverified** — would need a direct conversation with Confirmis or a comparable firm | | Confirmis's internal acceptance rate, turnaround time, and per-assignment cost through their own network | **Unverified** — not derivable from public postings | | A dispatch platform would measurably reduce cost or turnaround versus Confirmis's current approach | **Unverified hypothesis** — the "operational drag" read from postings alone is not sufficient evidence | | Geocoding, EXIF cross-check, and ELA as tested here can reliably block fraudulent submissions | **Not supported by this research** — see section 3; ELA in particular was not a detection experiment | | Live capture + per-assignment challenge code is more effective than the three passive checks | **Untested design hypothesis** — no comparative experiment was run | | EXIF GPS tags can be forged to match any target location, cheaply and quickly | **Fact, tested** — a free command-line tool (`exiftool`) wrote exact target coordinates onto an image with no prior GPS data in 0.48 seconds; the same distance check that flagged a genuine mismatch in section 3 reported this forged file as VERIFIED_LOCATION | | Real-world GPS EXIF retention rate on unconstrained photo uploads | **Untested** — no experiment measured this |
A pilot would also need to define, upfront and separately from any technical design: photo and location-data retention limits, what happens to a rejected verifier's submission, consent and disclosure for the freelancer whose real-time location is being captured, and basic safety considerations for someone physically visiting an unfamiliar address on assignment — none of which this research addresses.
### 6. So — worth building?
**The demand signal is real and unusually well-documented — a specific, named, currently-operating buyer, posting continuously for over two months across dozens of countries. But the software opportunity is unverified, not validated, and the most defensible read of this research is narrower than the first draft claimed:** there is a real, recurring purchase of on-site verification labor happening in the open market, and it is not obvious from the postings alone why a company with a reported 6,000+ verifier network still buys through Freelancer.com — that gap is exactly the question a real pilot conversation with Confirmis (or a comparable trade-intelligence firm) would need to answer before any build decision. On the technical side, none of the three checks tested here — corrected for what they actually measured — currently support a "fraud-resistant" product claim; they're starting points for further, more rigorous engineering and testing, not a working detector. The right next step is the conversation in the fact table above, not further building.
*Evidence sources: 3 published demand-signal pages built from 65 real, budget-posted, PII-scrubbed Freelancer.com tasks (linked above by feature), all traceable to Confirmis (confirmis.com), posted 2026-07-10 through 2026-09-10. Technical verification: OpenStreetMap Nominatim geocoding API, Pillow 10.2.0 / exifread 3.0.0 / piexif 1.1.3 for EXIF extraction and synthesis, a from-scratch Pillow-based JPEG-recompression difference visualization (not an independent tamper detector — see section 3), tested against 5 real-world addresses and image test cases on 2026-09-10; a follow-up EXIF-forgery test added 2026-09-15 using `exiftool` (libimage-exiftool-perl 12.76); full scripts, raw JSON results, and the frozen 65-task source list are archived under docs/low-value-2026-09-05/ (verifier-research-scripts/, including the README with reproduction steps and task-snapshot-65.md). This article went through several rounds of internal fact/methodology review plus direct manual verification by the site owner -- which caught and fixed the business-premise error in section 1, a methodology error in the original tamper-detection description, and the EXIF-forgery gap addressed above -- but has not yet been read by independent outside developers. Treat it as fact-checked and evidence-grounded, not as validated by the audience it's written for.*