Lightshadow — Privacy Policy

Last updated: 2026-10-09

This policy describes the Lightshadow mobile application, the Lightshadow web client that runs in a browser, and the Lightshadow server (the "API") that answers them both, and also the contact form on the lightshadow.app site (§4, §5.6). It is written to be checkable: every statement below describes what the software actually does, not what a privacy policy usually says. Where the app and the web client behave differently, it says which one it is describing. The older frozen demonstration page, published separately, is different software with a different data flow and is not covered by this policy.

One thing has to be said before the rest, because most of what follows depends on it: there are two configurations of this service, and the server picks which one you get. In the Google stack, the map and the address search come from Google, so your browser or your phone talks to Google directly and Google receives your IP address, the part of the map you are looking at, and the text you type into the search box — under Google's privacy policy, not this one. In the fallback stack, the map and the search are ours and OpenStreetMap's, and your search text does reach our server and is stored there. Neither you nor the app chooses between them. The server selects one for everybody, from how much of Google's free monthly allowance is left, and the answer can differ from one visit to the next. §8 describes both in full.

---

1. Who is responsible for your data

Lightshadow is made and operated by Nikita Khromushkin, an individual developer resident in Spain. There is no company behind Lightshadow and no corporate entity of any kind.

For anything in this policy, write to info@lightshadow.es.

He is also the controller of the messages you send us through the site's contact form.

No data protection officer has been appointed.

---

2. The short version

• Lightshadow has no accounts, no login and no profile. It never asks who you are.
• The start and finish points you choose are sent to the Lightshadow server so it can compute a route. They are used to answer that request and are not stored.
• The coordinate of each point you set is sent to the Lightshadow server and stored there, rounded to about 100 metres, in a separate store that contains no IP address, no device identifier, no session key and no precise time — only the hour. We keep the points, coarsely; we do not keep anything that says who sent them.
• What happens to the text you type into the search box depends on which stack the server has selected, and the difference is not a small one. In the fallback stack it is sent to us and stored in that same separate store, exactly as it has been until now. In the Google stack it is not sent to us at all: your browser or your phone asks Google directly, so Google receives the text you typed and the IP address you typed it from, as its own controller and under Google's privacy policy. We never see it, so there is nothing of it for us to keep, to show you or to delete.
• Whoever draws the map you are looking at receives your IP address and which part of the map you are looking at, every time you pan or zoom. In the Google stack that is Google. In the browser, in the fallback stack, it is OpenFreeMap (tiles.openfreemap.org). Something in that position has been true of the web client for as long as it has existed and no earlier version of this policy mentioned it; §8 and §17 say so plainly. It was the OpenStreetMap Foundation's tile servers until 14 September 2026, when the basemap moved. We have not audited what OpenFreeMap keeps, and we say so rather than imply a guarantee we did not obtain.
• Precise location leaves your device. Under Google Play's definition that means Lightshadow collects precise location, and we declare it as collected.
• While you have Lightshadow open it may show you where you are and keep the map centred on you while you look at it. Those positions stay on your device: they are not written down, not sent to us, and not kept after you close the screen. What reaches our server is only a point you deliberately set. This is narrower than what an earlier version of this policy promised — §17 says exactly what changed and what was given up.
• The routes you save stay on your phone. They are excluded from Android cloud backup and from phone-to-phone transfer, and they are deleted with the app.
• There is no advertising, no analytics SDK, no tracking, and nothing is sold.
• If the app crashes, it tells our server — and only our server. From the first build released after 0.2.1 (from 2026-09-16) the app sends the crash's stack trace, its own version, the Android version and the phone model to the Lightshadow server, so we can fix the fault. No identifier goes with it: no install ID, no advertising ID, no account, no location. It is kept for 90 days with the hour it arrived, and it never goes to Google, Firebase or any other crash-reporting company. §4, §5.5.
• If you write to us through the site's contact form, your name, your e-mail address, the topic and the message reach us by e-mail at info@lightshadow.es, and the server keeps none of it. The mailbox is hosted by Google Workspace and messages are deleted after 90 days. It is the only place in Lightshadow where you give us your name, and only if you choose to write. §4, §5.6.
• Your device position, when you ask for it, comes from Google Play services. The Android build distributed from lightshadow.app (version 0.2.0 and later) shows a Google Maps base map, so Google receives your IP address and the map area you look at, every time you pan or zoom, as its own controller and under Google's own privacy policy (https://policies.google.com/privacy), not this one. Until 2026-09-15 no released Android build carried a Google Maps key and the app drew a blank canvas instead; §8 keeps that history. In the browser, in the Google stack, the base map is Google's and is drawn by your browser talking to Google.

Sections 4 to 7 say exactly what this means, and §8 says who else is in the path.

---

3. What Lightshadow stores on your phone

All of it is ordinary app storage, readable only by Lightshadow, and removed when you uninstall the app.

None of this is sent anywhere. Android cloud backup is switched off for Lightshadow, and so is device-to-device transfer, so your saved routes do not travel to another phone or to a Google account.

You can erase the saved routes at any time from Settings → Delete saved routes, and the recent searches from Settings → Clear search history. Uninstalling the app removes everything in this table.

In the browser, the web client keeps the equivalent of that table in your browser's local storage, and nothing else: the saved routes (the same 100-entry limit), the language you chose, whether you have seen the first-run screen, the municipalities you have already asked for, and one true/false record that you have been shown the location prompt once, so that you are not asked again on every visit. No coordinate, no accuracy figure and no time of any position fix is ever written there. There is no cookie and no service worker. Clearing this site's data in your browser removes all of it.

Saved routes are a record of estimates you asked for, not of walks you took. Lightshadow records no track of where you went — not on the phone and not on our server — has no background location permission, and does nothing while it is closed.

---

4. What is sent to the Lightshadow server

This section is about our server only. In the Google stack your search does not come here at all — it goes from your device to Google, and §8 is the section that describes that. Everything below is what reaches us.

Lightshadow is a thin client: the sun and shade computation happens on the server, so the app has to send what you asked about. Every request carries:

• the app version, the platform (Android), the operating-system version, the build number and your interface language (es or en), in the User-Agent header. This string deliberately contains no advertising ID, no install ID, no device model and no serial number of any kind;
• a fixed key that is the same in every copy of the app. It identifies the build, not you, and it cannot distinguish two phones;
• your IP address, which is unavoidable in any internet connection.

The connection is HTTPS. The app refuses to send anything over plain HTTP. It stores no cookies and keeps no HTTP disk cache.

Per feature:

There is nothing else. The app makes no other network calls to us.

The web client does the same things through the same endpoints — one launch call that carries no coordinate at all, then coverage, route, shade, search and city requests, exactly as the table describes them. What differs in the browser is who draws the map, and in the Google stack who answers the search: §8.

---

5. What the server keeps, exactly

The server keeps three kinds of record about a request, and only three.

Corrected 14 September 2026: this line read "The server writes to three places, and only three". Read literally — as a count of files — it had stopped being true: there is a fourth file on the server, described in §5.4, and the service also reads two build keys from disk at start-up. Neither holds anything about you. The sentence now promises what it was always meant to promise. §17.

5.1 The operational log. One line per request, containing the HTTP method, the path, the status code and how many milliseconds it took. It contains no query string, no request body, no coordinate, no search text, no IP address, no User-Agent and no request identifier. The web server's own access log, which would otherwise print the full request line including coordinates and search text, is switched off.

5.2 The analytics store. This holds the things §4 says are kept:

• for a search in the fallback stack: the text you typed, the number of results, and — only if you had already set a start point — that start point, which the app sends so that nearby results rank first. In the Google stack there is no such row, because the text never reaches us;
• for a point you set: the coordinate and whether Lightshadow covers it.

Every coordinate in this store is rounded to three decimal places — about 100 m — before it is written. The exact value is used to answer your request and is not kept; what is stored places a point on a block, not at a doorway.

Every row carries only the hour it happened in, never a clock time. No row contains an IP address, a device identifier, a session key, the app's build key, the User-Agent, a request identifier or a sequence number. Rows are deliberately shuffled within each hour so that their order cannot be matched against the order of the operational log.

5.3 The city-request counters. How many times each municipality has been asked for, and in which hour. No coordinates, no identifiers, no one row per request.

5.4 The Google spend counter — a fourth file, which contains nothing about you. Since 14 September 2026 the server keeps a count of how many times each Google product we pay for has been used, per calendar month: a product identifier and a number. It exists so that Lightshadow can stop using Google before the bill does. It holds no request, no coordinate, no search text, no time finer than the month, no IP address and no identifier, and nothing in it can be traced back to a person or a request. It is named here because §5 promises a complete account of what the server writes, and a complete account has to list a file even when there is nothing of yours in it. It has no row in §9 and none in §10 for the same reason: there is no personal data in it to have a lawful basis or a retention period for.

5.5 The crash store — a third kind of record, since 16 September 2026. When the app crashes it sends one report to our server (§4, last row), and the server keeps it: the stack trace, the app version and build number, the build channel (sideload, Play or debug), the Android version, the phone model, the failing thread's name, the time by the phone's clock, and the hour the report arrived. Nothing else is written: not your IP address, which the server sees only to count requests and never writes down; not the User-Agent line; not a request identifier; not a sequence number. A crash report contains no identifier of you or your phone — the app's crash reporter is configured to collect none, and the server refuses a report carrying any field outside that list. The phone model is the one field with any fingerprinting value, and it is kept because a fault that only happens on one model is the commonest kind of Android fault; it is a model name shared by millions of devices, not a serial number. Crash reports go to us and to nobody else — not to Google, not to Firebase, not to any crash-reporting service. Under Google Play's data-safety vocabulary this is "crash logs: collected, not shared". They are deleted after 90 days (§10).

5.6 The contact form — no record on the server. A message sent from the site's form (§4) is not kept on the server: the server forwards it at once by e-mail to info@lightshadow.es and writes neither the message, nor your name, nor your address to any file, database or log. What remains is in the mailbox, hosted by Google Workspace as our processor (§8), where the message is deleted after 90 days (§10). We read messages to answer them and for nothing else: we add them to no list, send you no marketing, and match them against nothing else in this policy. Nor could we, because nothing the server keeps carries your name or your address.

A limit we will not hide. Storing search text and coordinates apart from anything identifying is the whole protection here, and it is not perfect. In an hour with very few requests, comparing how many lines the operational log has with how many rows the analytics store has can narrow down which request produced which row — and if there was exactly one of each, it identifies it. There is no fix for that at low traffic. It stops mattering as traffic grows, and we would rather say so than claim a separation that is stronger than it is.

---

6. What the server does not keep

• No account, because there is none to keep.
• No IP address in either the analytics store or the operational log.
• No device identifier, no advertising identifier, no installation identifier, no fingerprint.
• No route. The start and finish points you plan between — the most revealing coordinates Lightshadow ever sees — are computed with and discarded.
• No cookies, no session, nothing that survives a request and links it to the next one.
• Nothing about your health, your body, your age, your name or your contacts. Lightshadow never asks for any of them, except your name and e-mail address if you choose to write to us through the contact form — and those are not kept on the server either (§5.6).

Every line above is a statement about our server. None of them is a statement about Google or about the tile servers, which receive your IP address directly from your device and keep whatever their own policies say they keep. §8.

---

7. Location

Lightshadow collects precise location. Google Play defines "collect" as transmitting data off the device, and coordinates good to a few metres do go to our server. We declare it in the Play Data safety form as collected, required for app functionality, encrypted in transit, and not sold or shared for advertising.

How it works in practice:

• Location permission is requested only while a screen that needs it is open. There is no background location permission and Lightshadow cannot ask for your position while it is closed.
• While such a screen is open, Lightshadow may read your position more than once, to show you where you are and to keep the map centred on you as you move. That is a drawing operation: the positions behind it exist in the running app and nowhere else.
• No track is recorded. No sequence of positions is written to storage, sent to our server, or kept once the screen is closed. The saved routes in §3 are the start and finish you chose, never a path you walked.
• Nothing continuously sampled is sent to us. What our server receives is the two endpoints of a route, a point you set, and a search query — the table in §4 is the complete list. A position that is only moving the map is never one of them.
• Successive positions cannot be joined up. There is no account, no cookie, no session and no device or installation identifier anywhere in a request (§4, §6), so even the coordinates you do send carry nothing that would tie one to the next.
• What the Android app released today actually does, as opposed to what this section permits: when you press "My location" it asks for one position, once, and subscribes to no updates at all. The map that keeps up with you is being built in the browser client first. This section is written to be true of both, and it will be updated with the date the following map was switched on, in the same way §8 will be for the base map.
• If you refuse the permission, everything still works: you can type an address or press and hold the map instead.
• Android lets you grant only an approximate position instead of a precise one. Lightshadow accepts that grant and works with it, and in that case what leaves your device is the approximate position rather than a precise one.
• The device position is obtained through Google Play services' location provider, so Google is involved in producing the fix. See §8.
• In the Google stack, a point you set by searching for it was produced by Google, from text you sent to Google. The position your device measures is not sent to Google by us; what you type is, and §8 says what goes with it.

---

8. Who else is involved

Who is in the path depends on the stack, and the server chooses the stack — not you, and not the app. Each recipient below says in which state it receives anything.

Google is involved in four ways now, and they are not all switched on at once.

Your device position — active in both stacks. When you use "My location" in the Android app, the fix comes from Google Play services' location provider. Google receives data as part of producing it, as its own controller and under its own terms, not under this policy. In the browser the position comes from the browser's own geolocation, which on an Android phone is usually the same Google service underneath.

Address search — active in the Google stack only, and this is the change that matters most. In the Google stack, what you type in the search box goes from your browser or your phone straight to Google, through Google's Places service. Google therefore receives the text you type and the IP address you type it from, as its own controller, under the Google Privacy Policy and not under this one. It does not pass through us on the way and it is not copied to us afterwards: we are not in that path, we cannot read it, and there is nothing about it for us to store, to show you or to delete. And the ranking coordinate goes with it. The client sends one coordinate to Google alongside the text, so that results near it come first, and Google receives it too. In the browser it is your start point, only if you had already set one. In the Android app from version 0.2.1 (2026-09-15) it is the other point of the walk if you had set one, otherwise the centre of the map on your screen, otherwise the centre of the prepared city; until 0.2.1 the app sent the start point or nothing. The centre of the map is an area Google already receives with every tile it draws (above); it is not a new fact about you, but it is now sent with the text, and this paragraph says so.

In the fallback stack none of that happens. There is no Google search call at all: your text is answered by Lightshadow's own Valencia street index on our own server, and it is kept there exactly as §4 and §5.2 describe.

The base map — in the app. Lightshadow draws on a Google Maps base map, and the Google Maps SDK is bundled in the Android app. The Android build distributed from lightshadow.app — version 0.2.0, published 2026-09-15, and every later one — carries a Google Maps key and shows the Google base map, in both stacks. So, in the app, Google receives your IP address and the map area you look at, on every pan and every zoom, as its own controller and under the Google Privacy Policy (https://policies.google.com/privacy), not under this one. Nothing you typed goes with a map request, and no account of yours is in it. One identifier is, and it is Google's, not ours: by Google's own disclosure for the Maps SDK and the Places SDK (https://developers.google.com/maps/documentation/android-sdk/play-data-disclosure, https://developers.google.com/maps/documentation/places/android-sdk/play-data-disclosure) the SDKs generate a pseudonymous, SDK-specific identifier to count daily active users, and send Google their own crash and diagnostic data. We never see that identifier, it is not tied to anything of ours, and we cannot read it back; it is declared in the Play Data safety form as collected by Google. Added 2026-09-16.

Until 2026-09-15 this was not so: no released Android build carried a Google Maps key, no map was ever requested from Google from the app, and the app drew its own blank canvas instead, with the route, the shade and the markers in their correct relative positions and a visible label saying there was no base map. The previous version of this section promised that the day a key was added would be recorded here. That day is 2026-09-15, with version 0.2.0; §17 records the change.

In the browser, in the Google stack, the base map is already Google's: it is drawn by the Google Maps JavaScript API running in your browser, so Google receives your IP address and the map rectangle you are looking at, on every pan and every zoom, for as long as that stack is selected. In the fallback stack the browser's base map is not Google's — see the tile servers below.

Your use of a Google map is subject to the Google Maps/Google Earth Additional Terms of Service and the Google Privacy Policy. Those two links are already shown in the app's Data licences screen in every build.

For what your device sends Google for the map and the search, we answer together with Google. The Court of Justice of the EU has held (Fashion ID, 2019) that whoever embeds another company's service in their app or page decides, together with that company, that your data is collected and transmitted to it, and is therefore jointly responsible for that step; for what the other company does with the data afterwards, it alone is responsible. So for the Google Maps map and the Google Places search — the SDK in the app and the JavaScript API in the browser — we are joint controllers with Google of your IP address, the map area and, if you search, the text and the ranking coordinate reaching Google. Our basis for that transmission is our legitimate interest in showing you a working map and an address search (§9), and what triggers it is something you do: opening or moving the map, or typing in the search box. What Google does with that data afterwards remains Google's own business, as its own controller and under its own policy.

Distribution. Lightshadow is distributed through Google Play, which gives us only aggregate, anonymous install and crash statistics that we cannot trace to a person.

A tile server — active today, in the browser. In the fallback stack the web client draws its base map as vector tiles that your browser fetches directly from tiles.openfreemap.org, which is operated by OpenFreeMap. That request never touches our server, so the tile server receives your IP address and which tiles you asked for — which is to say, roughly where you are looking and at what zoom — every time you pan or zoom. Nothing you typed goes with it, and there is no account and no identifier in the request: it carries the tile numbers and nothing else.

Until 2026-09-14 this text named tile.openstreetmap.org, run by the OpenStreetMap Foundation, and that was correct at the time. The web client moved to a vector base map that day and the sentence was left behind for a few hours, naming the wrong company as the recipient of your address. Corrected here rather than quietly.

What we have not checked, and say so rather than implying otherwise: how long OpenFreeMap keeps request logs, and what it does with them. We chose it because it requires no account and no key, not because we have audited it. The map DATA is still OpenStreetMap's, under ODbL, and that credit is unchanged — the data and the server that hands you the tiles are two different obligations, and only the server changed.

This has been true of the web client since it existed, and no version of this policy said so. It is written down here because it is a fact about the product, not because it changed — the Google stack merely put a second company in the same position and made the omission impossible to leave standing. The Android app fetches no OpenStreetMap tiles. This is a different thing from the OpenStreetMap data in the shade model, which we downloaded in advance; that is the last paragraph of this section.

Hosting. The Lightshadow server runs at Hetzner Online GmbH, Germany. The provider can technically reach the machine, as any host can; it is not given the data for any purpose of its own. Hetzner is our processor: it handles the data only on our behalf, under a data-processing agreement that obliges it to follow our instructions, to use the data for nothing of its own, to keep it confidential, to protect it with appropriate security measures, and to delete or return it when the service ends. That is the contract Article 28 GDPR requires.

E-mail. Messages from the contact form (§5.6) arrive in a Google Workspace mailbox, Google's e-mail service (Google Ireland Limited and Google LLC). For that mailbox Google is our processor: its data-processing terms for Google Workspace oblige it to handle the mail only to provide the service to us and on our instructions, not for purposes of its own such as advertising (Article 28 GDPR). Messages are deleted after 90 days (§10).

Nobody else. There is no analytics provider, no crash-reporting service, no advertising network, no attribution SDK and no customer-support tool.

And one sentence that used to stand here has been removed because it is no longer true. It read: "Address search is answered by Lightshadow's own street index on our own server; your search text is not forwarded to any outside service." That describes the fallback stack exactly, and it is false in the Google stack — where the text is not forwarded by us to anyone, for the simpler and larger reason that it never comes to us at all, and goes to Google instead. §17 records the change. It is not a narrowing of the old promise: it is the same promise pointing at a different company.

Data sources are not recipients. Lightshadow's shade model is built from OpenStreetMap, from the Instituto Geográfico Nacional's PNOA-LiDAR survey and from the Dirección General del Catastro. That data was downloaded by us in advance and is credited in the app because the licences require it. Nothing about you is ever sent to them.

---

9. Legal basis for each purpose

Lightshadow is operated from Spain, so the EU General Data Protection Regulation applies.

Your search text in the Google stack never reaches us: it travels from your device to Google, which answers for what it does with it under its own policy. All we answer for is that our app and our page send it to Google, and that is the row for the Google map and search. Corrected 2026-10-09: this paragraph said the table had no row for that search, because we cannot state a lawful basis for something we never receive. Under the ruling cited in §8, whoever embeds the service answers for the transmission even without receiving the data, so the transmission does need a basis.

The rate-limit counters that stop one address flooding the API do hold IP addresses, but only in the server's memory, for at most an hour, and they are never written to disk and are lost on every restart.

You can object to processing based on legitimate interest at any time — see §11 for what we can and cannot do about it.

---

10. How long it is kept

Stated plainly: the periods above are enforced by the software itself, not by a procedure. The deletion runs when the server starts and then once a day, and it refuses to run — and says so in the server's log — if a fault such as a wrong clock would make it delete more than half of a store at once; a refusal keeps everything until a person looks. The 30 days for the operational log is the one period the software does not enforce itself: once a line is written it belongs to the server's journal, and it is the server's log rotation that discards it.

---

11. Your rights, and the honest limit on them

Under the GDPR you have the right to access your personal data, to have it corrected or erased, to restrict or object to its processing, to data portability, and to lodge a complaint with a supervisory authority.

Here is the awkward part, stated rather than hidden. Lightshadow keeps nothing that identifies you. There is no account, no device identifier, no IP address next to the stored data and no session key. If you write and ask what we hold about you, we cannot find it, because there is nothing to search by — a stored search query and a coordinate look identical whoever sent them.

Article 11(2) GDPR covers exactly this situation: where a controller can show it is not in a position to identify the data subject, the rights of access, rectification, erasure, restriction, notification and portability (Articles 15 to 20) do not apply, unless you provide additional information that makes identification possible. We do not ask for such information, we do not want it, and providing it would mean handing us more data than we hold today.

There is one exception: contact-form messages. There we do know who you are, because you gave us your name and your address, and the limit above does not apply. If you wrote to us, you can see that message, have it corrected or ask us to delete it before the 90 days are up: write to us from the same e-mail address and we will look it up by that address.

What you can do, effectively and immediately:

• Delete everything on your phone — Settings → Delete saved routes, or uninstall the app. That is the only place where a record of your routes exists.
• Refuse location permission. Nothing in Lightshadow requires it.
• Object, or ask questions, at info@lightshadow.es. We will answer honestly, including when the honest answer is that we cannot locate a record.
• Complain to the Spanish supervisory authority, the Agencia Española de Protección de Datos (AEPD), at https://sedeaepd.gob.es/sede-electronica/home, or to the authority of the EU country where you live.

This limitation is a consequence of holding as little as possible. It is not a way of avoiding a request.

---

12. Children

Lightshadow is not directed at children, offers nothing designed for them and collects no age information. Because it has no accounts, it also has nothing to delete from a child's account. If you believe a child's personal data has somehow reached us, write to info@lightshadow.es and we will look into it — while noting that §11 applies to us equally here.

---

13. Advertising, tracking and sale of data

• Lightshadow shows no advertising and contains no advertising SDK.
• Lightshadow performs no tracking across apps or websites, uses no advertising identifier and builds no profile.
• Lightshadow does not sell your data and does not share it with anyone for advertising, marketing or profiling.
• There is no automated decision-making that produces legal or similarly significant effects about you. The route is a suggestion; you decide whether to walk it.

These four statements are about Lightshadow. What Google does with what your own device sends it directly (§8) is governed by Google's privacy policy: we receive none of it, we are paid nothing for it, and we cannot switch it off on your behalf. The one thing you can do inside Lightshadow is not type in the search box — tapping the map sets a point without sending anything to Google.

---

14. Not a medical device

Lightshadow is not a health app and is not a medical device. It does not diagnose, treat, cure or prevent any condition, and it processes no health data whatsoever. Lightshadow never measures anything about your body and holds no special-category data of any kind.

Lightshadow shows no ultraviolet figure of any kind, and no figure about sun exposure beyond how much of a route is modelled as shaded. Removed from this section on 2026-09-14: it described a feature that does not exist. The service returns uv: null (route_service.py), no client reads that field, and no such string ships in either language. If an ultraviolet figure is ever built, this section has to be rewritten before it ships, and design §7C governs how it may be worded.

---

15. Where your data is processed

The Lightshadow server is hosted at Hetzner Online GmbH, Germany. Germany is inside the European Economic Area, so the data described in §5 is not transferred outside it.

Transfers to the United States. Google LLC, the US company of the Google group, may receive in the US what your device sends Google for the map and the search (§8), and the contact-form mail kept in Google Workspace (§5.6). Google LLC is certified under the EU-US Data Privacy Framework: the European Commission has decided that companies certified under it protect personal data at a level equivalent to the EU's, so data may be transferred to them without further safeguards (adequacy decision of 10 July 2023, Article 45 GDPR). Google LLC's certification can be checked at https://www.dataprivacyframework.gov/.

Google's involvement (§8) is governed by Google's own terms and privacy policy, including any transfers Google makes. In the Google stack that involvement includes the text you type and the map you are looking at, sent from your device to Google rather than by us. We answer together with Google for that transmission taking place (§8); we are not a party to what Google transfers afterwards and cannot place conditions on it. The same is true of the tile requests your browser makes to OpenFreeMap in the fallback stack.

---

16. Security

• All traffic between the app and the server is encrypted with HTTPS. The app is built so that it cannot send anything over an unencrypted connection.
• The server rejects request fields it does not expect, rather than ignoring them, so a future version of the app cannot quietly start sending more than this policy describes.
• Request sizes and parameters are capped, and requests are rate-limited.
• The strongest protection here is the one described in §5 and §6: what is not kept cannot be lost.

No system is perfectly secure, and Lightshadow is operated by one person. This policy describes the measures that exist, not measures that are planned.

---

17. Changes to this policy

If what Lightshadow does changes, this policy changes with it, and the date at the top is updated. The current version is always at https://lightshadow.app/legal/privacy/, and the app links to it from the first-run screen and from Settings.

2026-10-09 — a contact form, and three clarifications about Google and hosting

The contact form is new processing. From today the site has a contact form. What you write in it — name, e-mail address, topic and message — is forwarded to us by e-mail and not kept on the server; the mailbox, at Google Workspace, deletes it after 90 days. It is the first time Lightshadow handles your name and your e-mail address, and only if you choose to write, so it is recorded here as a widening. The row in §4, §5.6 and the rows in §9 and §10 are the full account, and §11 says how to exercise your rights over a message.

Three clarifications that do not change what the software does. §8 now says that, for what your device sends Google for the map and the search, we answer together with Google, and §9 gives the lawful basis for that transmission; it used to say Google was the only controller and there was no basis to state. §15 says why Google LLC may receive data in the US. And §8 says that Hetzner, which hosts the server, is a processor under a contract that obliges it to handle the data only on our behalf.

2026-09-16 — recent searches, on the phone only

From Android 0.2.4 the app keeps the last ten places you picked from a search — our name for the point and its coordinate — on the phone, so the search box can offer them back. Nothing is sent anywhere; the list is cleared from Settings → Clear search history and goes with the app. It never holds the text you typed or anything Google returned. The row in §3 is the full account.

2026-09-16 — a place picked from Google's search is named after our own street

In the Google stack the name Google gives a place may not be shown on the map, so the app used to label a picked point with the words you had typed. From Android 0.2.4 it sends the picked place's coordinate to the Lightshadow server and labels the point with the nearest OpenStreetMap street name from our own data, when one is within 60 metres; otherwise your typed words, as before. This is one coordinate reaching us that in the Google stack did not before — recorded here as a widening. The call stores nothing: no row is written for it. The same coordinate was already stored, rounded to about 100 metres, the moment you set the point (§4, §5), so nothing new is kept. The row in §4 is the full account.

2026-09-16 — the app reports its own crashes, to us

Until this version the app reported nothing when it crashed: the fault was gone with the process and we learned of it only if someone wrote to us. From the first build released after 0.2.1 the app sends a crash report to the Lightshadow server — the stack trace, the app version, the Android version, the phone model and the time — and the server keeps it for 90 days with the hour it arrived. This is new data leaving your phone, so it is recorded here as a widening, not as a repair. What was decided about it, and why: the report goes to our own server and to no crash-reporting company — the usual alternative would have put an installation identifier next to every trace, and an identifier next to a trace is a record of what one phone was doing; ours carries no identifier at all, and the server refuses a report that tries to send one. The row in §4, §5.5, and the rows in §9 and §10 are the full account.

2026-09-15 — the Android app shows Google Maps

Until this version, no released Android build carried a Google Maps key: the app drew a blank canvas, and this policy said Google received nothing through the app's map. The build distributed from lightshadow.app — version 0.2.0 and every later one — shows a Google Maps base map. So, from the app as well as from the browser, Google receives your IP address and the map area you look at, on every pan and every zoom, under Google's own privacy policy. This is a real widening of what leaves your phone, not a repaired omission: the previous text was true when written and stopped being true with this release. What has not changed: no account, no identifier, no search text in a map request, and nothing about the map you look at reaching our server beyond the viewport already described in §4. §2 and §8 say the same in full.

2026-09-14 — a fourth file on the server is named

§5 opened with "The server writes to three places, and only three", and listed three. That count was a promise about files, and a fourth file had appeared: a per-month counter of how many times each Google product we pay for has been used, added the same day as the Google stack itself. It holds a product identifier and a number and nothing else — no request, no coordinate, no search text, no IP address, no identifier, and no time finer than the calendar month — so nothing about you became less private. What was wrong was the enumeration: a policy that says "and only three" has to be complete, and this one was counting the stores that hold your data while promising a count of every file. The sentence now says three kinds of record about a request, and the counter is written up as §5.4 so nobody has to take our word for what is in it. Nothing you gave up; an omission repaired.

2026-09-14 — the search can now go to Google, and the web client is disclosed

Two changes, one of which is a real widening of what leaves your hands and one of which is an omission being repaired.

The search. Lightshadow can now run in either of two configurations, and the server chooses. In the Google stack the address search is Google's and the map may be Google's, so your browser or your phone contacts Google directly and Google receives your IP address, the map you are looking at and the text you type. In the fallback stack everything is as it was: our own street index answers the search, and the text reaches us and is stored as §5.2 describes. You cannot pick a stack, and neither can the app.

The web client. This policy described only the mobile app. It now covers the browser client as well — which matters immediately, because in the fallback stack that client has always fetched its map tiles straight from a third party's servers, so those servers have always received the visitor's IP address and viewport. That third party was the OpenStreetMap Foundation until 14 September 2026 and is OpenFreeMap since. What changed today is that it is finally written down.

What you gave up. Until today, the honest one-line summary of address search was that what you typed never left our hands. In the Google stack that is no longer true, and it is not the same promise made smaller — it is the same promise pointed at a different company, one that already knows far more about you than we ever will. There is no setting that avoids it, because the stack is the server's choice and not yours. What has not changed is everything in the table above that says "unchanged": no account, no identifier, no background location, no recorded track, and a continuous position that still never leaves your device.

2026-09-14 — the location promise was narrowed

Until this version, this policy and the text inside the app said that Lightshadow never follows a walk. That sentence was written to rule out three things: location while the app is closed, a recorded track, and a location history. All three are still ruled out, in §3, §6 and §7.

But the sentence also ruled out a fourth thing by accident — a map that keeps up with you while you are looking at it, with your position never leaving the device — and that is something Lightshadow is being built to do. So the promise has been narrowed rather than restated, and the honest summary of the exchange is:

What you gave up. A reader of the old sentence could reasonably conclude that Lightshadow asks your phone where you are only at the moment you press something. That is no longer true, and we are not going to pretend it is. What has not changed is where those positions can go, which is nowhere.

---

18. Contact

Nikita Khromushkin info@lightshadow.es Spain

Supervisory authority: Agencia Española de Protección de Datos (AEPD), https://sedeaepd.gob.es/sede-electronica/home