SAR Helper lets hikers share their location with the local SAR team proactively, so that if something does go wrong, responders already have a location.
SAR Helper never dispatches anyone, and it never contacts a team. It is a database that a hiker can report their position to, and that SAR team can access, after when a call has already arrived through the normal channels.
SAR Helper solves two separate problems. The first is about the hours before anybody calls; the second is about the call itself.
Most people who get into difficulty in the backcountry are not certain they are in difficulty. They are unsure. They wander, and they usually find the trail again — and because they are unsure, they do not want to waste anybody's time. So they say nothing, for hours, until it is dark and they are cold and now they are genuinely lost, several kilometres from where the trouble started.
By then, they may be out of battery, out of service, injured, unable to think clearly, or unresponsive. SAR Helper lets them share their position before all of this happens - without initiating a call for help.
In Canada today a caller's GPS position frequently does not reach the responding team through the call itself. The hiker is on the phone reading numbers off a screen, or describing a creek, and the coordinates get written down, relayed, mistranslated, and sometimes lost between the call taker and the people walking in.
SAR Helper provides a second path for sharing location information that does not go through the call at all.
Make it as easy as possible for a hiker to share their location proactively, and put the result somewhere a responding team can open. Nothing else: no alerting, no monitoring, no promise that anyone is watching.
A hiker scans a QR code on a sign, or enters sarhelper.com from memory. That gives them a web page — or, if they have installed the app, the app — and one button. Whatever they send lands in a database that a team covering that region can search after a call reaches them through the channels it always does.
Every screen in the app says that nobody has been notified. It is repeated to the point of monotony, because a hiker who believes a rescue is already coming will sit still and wait for it.
Both problems fall out of the same mechanism. The hiker who checks in at the gondola has recorded a position hours before anyone would have thought to ask for one; the hiker who flags themselves before dialling has put exact coordinates in front of the team without them having to survive the call.
A sticker on a trailhead board, or at a junction where people go wrong. Scanning it is the only thing the hiker has to do — no app to have heard of, nothing to sign up for.
A scan on its own records the code and the time. Not the phone, not an address. Somebody who scans a poster out of curiosity has not entered the system.
Signs learn their own position from the hikers who scan them, so nobody has to survey where each one went, and a sign that gets moved corrects itself.
One page. No images, no scripts, loads on one bar of signal. Two levels: check in, and may be lost. Keeping them apart is the design — a hiker offered only "I am lost" usually sends nothing, because pressing it feels like raising an alarm. The sign decides which one leads.
Same two levels, plus what a page cannot do: it records from a pocket, holds the backlog when there is no signal, and draws the hiker their own trail — so it doubles as a way back.
No account either way. Identity is a random id per outing; a name only if one is typed.
A web console, behind a sign-in, showing only the ground the team is responsible for.
| 6:40 pm | A hiker comes off the Habrich loop above the gondola, flags themselves in the app, and calls 911. |
|---|---|
| 6:52 pm | The call reaches the team through the channels it always does. SAR Helper has played no part so far. |
| 6:55 pm | Someone with a console login searches the name, or draws a polygon around the area. |
| 6:56 pm | If the hiker used it: an exact position, the route they walked to get there, how much battery remained, and the plan they set off with. |
| 6:56 pm | If they did not: nothing, and the search proceeds exactly as it would have. |
The last row matters as much as the one above it. This is not a system anyone has to rely on. It is a system that occasionally saves hours.
| Sign-in | Existing Google or Microsoft accounts, restricted to the team's domain. No new passwords. |
|---|---|
| An area | A polygon for the ground the team is responsible for. It decides which tracks they can see, and which hikers are told they are covered. |
| Nothing else | No integration, no radio work, no change to how the team is dispatched, and no obligation to look at it. |
| Kept for | 7 days, then deleted. A safety net, not a record. Nothing accumulates, so there is nothing to subpoena a year later and nothing to lose in a breach that is older than last week. |
|---|---|
| Who can see it | Only teams whose area covers the position, and only after signing in. Hikers outside any registered area are told, in the app, that nobody is reading it. |
| Identity | None. A random id per outing. A name only if one is typed. There is no account to compromise, because there are no accounts. |
| Residency | The intent is that data stays in the jurisdiction it was collected in — Canadian positions on Canadian infrastructure — and the design routes it that way. No residency guarantee will be claimed until there is a contract behind it. If that matters to a team, it is one of the first things to settle rather than something to take on trust from a web page. |
| At rest | Free text a hiker writes — the trip plan, the note about themselves — is intended to be encrypted per record, with the keys held apart from the database, so that a stolen copy of the database is not a copy of everyone's private circumstances. Positions stay queryable so that an area search still works. Access is by sign-in and area, with no key for a team to install or lose. Designed, not yet built. |
| In transit | HTTPS only, with the app pinned to its own server. A position is a few hundred bytes, so nothing is batched up in the clear waiting for a better connection. |
The app and the console are built and working; the screenshots above are of the real thing. The hosted service they would run on is not: today it is a single server suitable for a pilot, the console sign-in is a development placeholder, and encryption at rest is designed but unwritten. The public site is a concept preview and is not live.
Saying that is better than showing a page that implies otherwise. If a team is interested, the first conversation is about what would have to be true before they would put real callouts near it.
| Hosting | Move off the single box onto managed infrastructure in a named Canadian region, with a contract that says so. |
|---|---|
| Sign-in | Replace the placeholder with real single sign-on against a team's own Google or Microsoft domain. |
| Encryption | Build the per-record encryption of free text that the table above describes. |
| One team | A pilot with a single team and a handful of signs, on ground they already know, with no expectation that anybody looks at it. |
SAR Helper is free, carries no advertising, and collects nothing it does not show. In an emergency, call 911 — this system cannot.
SAR Helper was created by Eagle Eyes Search.