Who can see your position

This page answers one question as precisely as we can: who, exactly, can see where you are?

It is the plain-language companion to the Privacy Policy. Where the two differ, the policy is the binding text.

The short answer

Who	When	What they see
You	Always	Everything
Contacts you chose for an outing	Only while that outing is running	Your live position, your plan, your track and the outing conversation
Contacts you did not choose	Never	Nothing
Other myJikita users	Never	Nothing
Rescue services	In an emergency, under the conditions below	Data needed to locate you
Alpik staff	Only where strictly necessary to operate the service or respond to an emergency, and it is logged	Depends on the reason
Advertisers, data brokers, anyone else	Never	Nothing. We do not sell data and run no advertising

Nothing is shared outside an outing

Your position is recorded only while you have started an outing. There is no always-on mode, no background collection between trips, and no way for anyone to check on you between outings.

• Before you start an outing: nobody sees anything.
• While it runs: only the contacts you selected for that outing.
• After you stop: nobody sees a live position. Your track becomes history, and it is yours.

Being someone's contact does not let them see you. Sharing is per outing, chosen each time, and it is never reciprocal — following someone does not share your own position with them.

What your contacts see

While your outing is running, the contacts you selected see:

• Your position, updated at your chosen interval.
• Your plan: activity, place, expected return time, planned route.
• Whether you are overdue, and whether you raised an SOS.
• Your track — where you have been during the outing.
• The outing conversation.
• How far you are from them.

They do not see your position between outings, your other outings, your other contacts, or anything else about your account.

Rescue services

In an emergency, data needed to locate a person may be made available to authorised rescue organisations through a dedicated console, separate from this application.

What this is not:

• It is not a live feed of every user. There is no map somewhere with everybody on it.
• It is not automatic. Pressing SOS does not send anything to a rescue service; it alerts your contacts, and a person decides to call. The reasoning is on the SOS page.
• It is not open access. It is restricted to authorised rescue organisations.

What it is: a way for the people who are looking for you to get the last known position, the track, the planned route and the plan — so the search starts somewhere sensible instead of in the middle of a massif. What that data is worth operationally is described in How rescue teams use your data.

How it actually works

There are two separate steps, and only the second one reaches your data.

1. Searching. A rescue or emergency service can search for a person. A search tells them whether you are a user and, if you have an outing running:

• its name — the activity and place you wrote yourself, such as "Ski touring · Pointe de Chalune",
• its date and the time you are expected back,
• whether you have raised an SOS.

You are not notified of a search, and it is worth explaining why, because at first glance it looks like the wrong way round.

A rescue service takes a call from somebody worried about a person. Before it can do anything it has to establish which person — and that is rarely obvious. It has to rule out people who happen to share the same name, people who have no outing shared at all, and people who turn out to have no connection to the person calling. A search is how it does that, and it is the step that narrows the question down to one individual.

Everyone ruled out at that stage is someone the service never needed to know anything about. Emailing each of them — "a rescue service looked you up today" — would alarm people who have nothing to do with the emergency, about an emergency that is not theirs. It would also be the opposite of helpful during the minutes that matter most.

The search is deliberately narrow: enough to tell two people apart, and nothing about where anybody actually is. It exists so that fewer people's records have to be opened, not so that more can be looked at. Without it, a service would have to open several full records to find the right one, and opening a record is the thing you are told about.

2. Access. If a rescue service then opens your profile, your position or any other information about you, you are notified by email. That email names the rescue service's own Data Protection Officer and how to contact them.

The email is sent at the moment your data is accessed. You then get nothing for the next 24 hours, however many actions are taken — one notification per day, not one per click. If the access is still going on after 24 hours you are emailed again, and every 24 hours after that for as long as it continues. Access during a search is meant to be short; a service still in your record the next day is something you are told about rather than something you have to discover.

Asking what was done with your data

Every action is logged — what was done, exactly when, and which operator did it. That log is available to the rescue service's Data Protection Officer, who can answer your questions about how your data was handled and why.

This is why the notification email gives you the DPO's address rather than ours. A rescue service that accesses your data decides for itself what to do with it, which makes it a separate data controller and makes it answerable for that processing under its own obligations — not ours. We can tell you what was disclosed and when; only they can tell you what they did with it, and they are required to.

The legal basis

The legal basis is the vital interests of the person concerned — GDPR Art. 6(1)(d) — which exists precisely for situations where processing is necessary to protect someone's life. Where the rescue service is a public body, it also relies on its own public-task basis, Art. 6(1)(e).

This does not rest on your consent, and that is deliberate. Consent can be refused and withdrawn, and a mechanism to find you cannot be one that quietly stops working. Art. 6(1)(d) exists for exactly this and does not depend on you having agreed to anything in advance — which also means nothing here is buried in a checkbox.

Notification is never deferred or suppressed. There is no case in which a rescue service can open your data quietly.

The log lives as long as your account does. If you delete your account, the record of any disclosure about you goes with it — see Delete your account.

For the record — the reasoning behind not notifying searches

This is the justification counsel should formalise. It is not an open question; it is a position to write up.

Purpose. A search disambiguates. A rescue service answering a call must establish which person the call is about, eliminating homonyms, people with no shared outing, and people unconnected to the caller, before it opens anybody's record.

Minimisation. The search returns the fewest fields that can separate two people, and nothing locational. Its net effect is fewer full-record accesses, not more — without it, a service would open several complete records to identify one person. It is a data-minimisation measure under Art. 5(1)(c), not a cost against it.

Proportionality of the alternative. Notifying candidates would reach people eliminated at that step: uninvolved individuals told that a rescue service looked them up, about an emergency unrelated to them. Notifying on a match does not solve this, because a candidate set legitimately contains homonyms — matching is not identification.

Transparency instead of notification. Art. 13 is satisfied in advance, on this page, rather than per event — users are told before they ever set out exactly what a search reveals and that it is not notified.

Accountability remains. The step that actually exposes a person's data is always notified, never deferred, and the rescue service's DPO answers for it.

Two things still to settle:

• Confirm searches are written to the operator log as well as accesses. If they are, the argument is complete: not notified, but recorded and auditable on request. If they are not, that gap is the weak point in the reasoning above.
• SOS status and Art. 9. It is the most revealing field in the result, since "this person is in distress" can shade into data concerning health depending on why the SOS was raised — and it is also the field with the strongest operational justification, being the triage signal itself. The assessment should say both. See the Privacy Policy.

Also outstanding: the data-sharing agreement with each rescue organisation, putting the separate-controller position in writing.

Jikita tag sightings

This one surprises people, so it is stated here in full.

Every phone running myJikita reports every Jikita tag it hears — including tags belonging to people the user has never met.

What is reported

• The tag's own broadcast, exactly as it was heard. The phone is a courier; nothing it interpreted or decoded is sent. The broadcast is signed by the tag and verified on our servers, so a sighting is evidence about the tag rather than a claim by the phone.
• How strong the signal was — a rough indication of distance.
• When it was heard.

What is not reported

A sighting says this tag was heard, at this strength, at this time. It identifies the tag, not the person carrying the phone that heard it.

Why it works this way

Because it is how somebody gets found in a valley with no mobile coverage. Their phone may be dead, drowned or out of signal — but if anybody walks past their tag and later returns to coverage, the tag's position is known.

Your phone does this for other people. Other people's phones do it for you.

note

A tag doesn't include any personal data, and the sighting report does not include any personal data about the phone that delivered the sighting. The only personal data is the tag's own identifier, which is necessary for the system to function.

If you carry a tag

Your tag is broadcasting continuously, and that is the point of it. If you do not want to be findable this way, do not carry one. Removing a tag from your account is described in Pairing a Jikita.

Alpik staff

Access to production data is restricted to authorised personnel and is limited to what is necessary to operate the service, investigate a fault, or respond to an emergency or a legal request.

Where your data is

In the European Union — hosted in France. The only routine exception is push notification delivery, which passes through Apple's and Google's systems. Full detail in the Privacy Policy.

Turning it off

You are always in control of the two things that matter:

• Stop the outing — sharing stops immediately.
• Do not start one — nothing is recorded at all.

And, at the extreme: revoke your phone, sign out, or delete your account.