Privacy policy

Who we are

Viewpoint is built and operated by Marcos Barbero, based in the Netherlands, who is the data controller for your personal data.

Contact for any privacy question, request, or complaint: [email protected].

The short version

On Free and Pro, if you don’t sign in, we store nothing about you on our servers. Your Locations, photos, and notes stay out of our hands, your purchase is handled entirely by the store you bought it from (Apple on iPhone and iPad, Google Play on Android), and you can capture, browse, and plan as a guest — we never see any of it.

“No account” is not the same as “no server contact” — a few things still reach us, and none of them identify you. Without an account, the app may download public reference data that’s the same for everyone (satellite orbits, sky events); it may send the coordinates of a place you’re looking at, or your current location when you allow location access, to get that place’s horizon, ground heights, time zone, forecast or light-pollution reading (nothing else about you, and the coordinates aren’t stored beyond ordinary request logs); it sends feedback or analytics only when you choose to; and on Android, Settings → Check connection asks our server whether it is reachable, with nothing about you. On any plan, the app also asks which features are switched on for it. Below Max, that request carries only its platform (iPhone and iPad, Android, or web), app version and build channel (a store, test, or development build), with no identifier, and nothing is stored about your device. On Max and Ultra it is sent with your account, so features can be rolled out gradually. Below Max and signed out, no account, token, or store receipt is ever sent, and none of this creates a server row for you. Signed in, on any plan, the app also asks our server for the nearest place name when you pin a Location or save a plan: it sends that place’s coordinates with your account, so the lookup can be limited per account, and the coordinates aren’t stored beyond ordinary request logs.

“We never see it” is not the same as “it never leaves your phone”, and you should see the difference up front. With Pro your library is copied to your own cloud account by the platform, not by us — through your iCloud on iPhone and iPad (that is how Pro syncs your Locations and photos between your devices), and through Android’s Auto Backup into your Google Drive on Android. In both cases the copy sits under your account, your storage, and your control; we have no access to it. Android adds one more thing that is the platform’s and not ours: Google’s own services register every Android install at first launch, before you sign in and whether or not you ever turn notifications on. The detail is in What we store about you and in Providers and sub-processors.

The Max and Ultra subscriptions (server-backed sync, live weather and condition alerts, backup, and sharing; Ultra adds the 3D world) require a Viewpoint account, so signing in is part of starting one; Free and Pro never need one.

Once you sign in, Viewpoint collects what it needs to do that job (your account, your Locations, your photos, your subscription state) and nothing else. Analytics is opt-in and behavior-only — it never includes your photos, GPS coordinates, names of Locations, or anything you typed, though it does reach Mixpanel with your IP address so events can be attributed to a country (see Analytics). We don’t sell data and we don’t show you ads. We do share with the platform services your device already runs on — Apple’s on iPhone and iPad, Google’s on Android (sign-in, payments, push, maps, and location) — and with the named providers below, which include a small number outside the EU. Searching for a place in Explore without Max or Ultra sends the name you type to your phone’s own place search — Apple’s geocoder (MapKit) on iPhone and iPad, Google’s geocoder on Android — and not to us.

What we store about you

Only if you sign in. Everything in this section applies once you create an account by signing in. As a guest (not signed in) none of it reaches us: there is no account, and your Locations, photos, Lists, plans, and watches live only in the app’s local database on your phone.

Two caveats, and neither is ours.

On iPhone and iPad, Pro keeps your devices in step through your own iCloud: the app writes your Locations, Lists, plans, watches and the captured photo files into the private CloudKit database of your Apple account. It is your iCloud storage and your data; we cannot read it, and no Viewpoint server is involved. Photo files are uploaded only over Wi-Fi. Turn it off by signing out of iCloud for the app in iOS Settings → your name → iCloud.

On Android, the operating system’s own Auto Backup is enabled for the app, so it may copy the app’s local data — including that database and the photos it stores — to your Google Drive backup, under your Google account’s storage and your control. We never see it. Turn it off in Android Settings → Google → Backup, or per-app in your device’s backup settings.

Weather lookups still work as a guest — they send only the latitude/longitude you’re checking, never an identity (see Providers and sub-processors → Open-Meteo) — and your subscription is verified directly with the store (Apple or Google Play), so we don’t see it either.

• Your account — email address, a display name, and the opaque identifier returned by Sign in with Apple or Sign in with Google if you sign in that way. The display name is whatever Apple or Google hands us at your first sign-in — with Sign in with Apple that is the name you chose to share on the consent screen, and if you shared nothing we derive one from your email address instead. We never ask you for your real name.

• Your Locations, photos, Lists, plans, and watches — the data you create in the app. Captured photos are stored in our own object storage; the rest lives in a PostgreSQL database. Both run on owner-operated infrastructure in the EU. Every photo you upload to our servers is put through an automated safety check for illegal and adult imagery before it can appear anywhere public. That check runs on the same servers as everything else — the image is never sent to a third party for it. It happens on every upload, not only on photos you choose to publish. See Trust and safety for why the check exists.

  (An earlier version of this policy said the safety check was performed by Hugging Face, an inference provider outside the EU, and that photographs were sent there. That is no longer true: the check now runs on our own hardware and no photograph you upload leaves our infrastructure. Hugging Face is no longer a recipient of anything.)

• Publicly-shared Locations — if you explicitly publish a Location, its location, name, photos, composition notes, and access info become visible to other Viewpoint users via the public-Locations surface. Private notes and per-account state (favorites, sync timestamps) never become public, regardless of the Location’s sharing state. Publishing is opt-in, friction-bearing (a confirmation sheet spells out what gets exposed before you confirm), and reversible — see Sharing a Location publicly for the full mechanics + the wildlife-protection safeguard.
• Subscription state — whether you’re on a Max or Ultra free trial or a paid Max or Ultra subscription, and which billing period (monthly, quarterly or yearly). A Pro purchase stays with your store and your device; we keep no record of it. The actual payment is handled by your store — Apple’s StoreKit on iPhone and iPad, Google Play Billing on Android — and we never see your card details. On both platforms, buying while signed in passes your Viewpoint account identifier to the store so the subscription can be matched back to your account — to Apple as the purchase’s appAccountToken, to Google Play as its obfuscated account id. Buying as a guest passes no identifier of ours on either store. The two differ only in how the subscription’s state then reaches us: on iPhone and iPad the app sends Apple’s signed receipt to our server; on Android, Google reports it to our server directly.
• Push notification token — an opaque identifier for your device so we can deliver condition alerts: Apple’s APNs token on iPhone and iPad, a Firebase Cloud Messaging (Google) registration token on Android, and — if you switch browser notifications on in the web app — a push subscription whose address is minted by your own browser’s push service (Mozilla’s for Firefox, Google’s for Chrome, Apple’s for Safari). We store it only once you’re signed in, and it is invalidated server-side immediately when you sign out (the device stops receiving alerts for the signed-out account immediately). On Android the token exists before we ask for it: Google’s Firebase libraries register the install with Google at first launch — see Providers and sub-processors → Google. Signing out invalidates our copy; only uninstalling the app (or clearing its data) removes Google’s.
• Analytics events (only if you turn analytics on) — see the next section.
• Crash reports — no third-party crash-reporting service is involved on either platform; each platform’s own reporting is what we use.
  • On iPhone and iPad, Apple’s on-device MetricKit framework produces a diagnostic (stack trace, exception/signal codes, device model + OS version, app version). Crashes are visible to us through Apple’s standard developer crash reporting (App Store Connect), and a summary is also sent to a Viewpoint server so we get a timely heads-up.
  • On Android, the app ships no crash-reporting code at all. Crashes and ANRs reach us only through Google Play Console’s standard reporting, which the operating system collects; nothing is sent to a Viewpoint server. Whether that collection happens is governed by your device’s own usage-and-diagnostics setting, not by the app.

  Either way: never your photos, GPS, notes, email, real name, or Location / List / plan content. Default is on (legitimate interest under GDPR Art. 6(1)(f) — knowing the app crashes is necessary to keep it working for you).

How long we keep your library after Max or Ultra ends. When your Viewpoint Max or Ultra subscription ends, we keep the server copy of your library for 7 days, so a late renewal or a change of mind costs you nothing. After those 7 days we delete it from our servers: the records and the photo files themselves, not just a flag. The copy on your phone, tablet or computer is never touched. We warn you 48 hours before the deletion, with a push notification and a notice on the Tools and Planner tabs. What the people you share with added to your Locations and Lists is kept, your shares stay in place, and a shared Location’s pin stays on our servers, without its name, your notes or your photos, until you subscribe again. We keep your account and your billing records, which we need for tax and audit. If you subscribe again later, what your device syncs from then on is stored again.

How location is used

Location is requested and used only in the context of the Map and capture features, to place and find Locations. Almost everywhere, the app asks the operating system for a single fix at the moment you need one, and nothing runs when the app is closed.

One feature is the exception, and it is on iPhone and iPad only. Suggest watches when I travel (Settings → Travel) notices when you have arrived somewhere new and offers to set up a watch there. To do that it needs iOS’s “Always” location permission, and iOS will only grant it if you say yes to a dialog it shows you by name. Until you do, nothing runs in the background; if you grant it, iOS wakes the app on a significant change of location, the app works out whether you have arrived somewhere worth suggesting, and that is the whole of it — the position is used on your device and in the reverse-geocoding lookup described below, and it is never sent to us. Turn the setting off, or revoke Always in iOS Settings → Privacy → Location Services, and the monitoring stops. Android has no background-location feature at all and asks for no background-location permission.

The map itself comes from a provider, and that provider sees it. Viewpoint does not draw its own map tiles, so panning the map, opening street-level imagery, searching for a place by name, turning a coordinate into a place name, or taking a position fix are all requests to a map or location service. The Explore map uses Google Maps while you are online on Max or Ultra — on iPhone, iPad and Android, from app version 2.3.1; earlier versions use it online on every plan — so Google receives the map requests, your IP address and the area you are looking at, under the Google Privacy Policy, and Google is a separate controller of that data. When you are offline, or when Google Maps is not in use (the Free or Pro plan, a build without a Google key, a Google map that does not load, or Google switched off from our side), Explore draws the OpenStreetMap-based map (rendered with MapLibre). Map data already on your device needs no request; a tile it has to fetch comes from the map’s tile host — our own tile style, or OpenFreeMap as the fallback — which sees your IP address and the area requested, and nothing else about you. Beyond Explore’s map, the rest is your platform’s:

• On iPhone and iPad that is Apple — MapKit for the tiles of every other map in the app (Saved, planning and watch maps), Look Around for street-level imagery, Core Location for the position fix, Apple’s place search for typed searches, and Apple’s geocoder for turning a coordinate into a place name.
• On Android that is Google — the Google Maps SDK for tiles, the Street View panorama for street-level imagery, Android’s system geocoder for both directions of place lookup, and Google Play services’ fused location provider for the position fix, which uses nearby Wi-Fi and cell signals as well as GPS.
• In the web app that is Google — the Google Maps JavaScript API for tiles, Places Autocomplete for typed searches, Street View for street-level imagery, and the Static Maps API for the small map images on a Location page and on a shared plan card.

Place lookup runs in both directions, and they send different things:

• Searching by name sends the text you type. Every keystroke in a place-search field goes to Apple (on iPhone and iPad) or Google (on Android and the web) as you type, together with a rough map region so the results are nearby.
• Reverse geocoding sends a coordinate. To label a Location with a place name, or to work out which timezone a Location is in, the app sends the coordinate to the platform’s geocoder and gets a name back. On iPhone and iPad this runs for Locations that don’t yet have a label, in the background, a batch at a time — so over the life of your library, the coordinates of the Locations you have saved are sent to Apple’s geocoder. On Android the one place this happens is the shareable plan card, and the coordinate is deliberately blurred before it is sent — snapped to a 0.05° grid, roughly 5.5 km, so what leaves the device is the neighbourhood and not the viewpoint.

In every case the coordinates and search text go to the platform, not through our servers, and are handled under that platform’s own privacy policy. We never send your account identity along with them.

Our own servers also send coordinates onward. Some features are answered by asking a third party about a place, always with a coordinate or an area and never with anything that identifies you: weather from Open-Meteo, map and landmark facts from OpenStreetMap’s Overpass service, Wikidata and Wikimedia Commons, a street-level preview image from Google, terrain elevation tiles from an Amazon Web Services open-data bucket (a tile covers about a 10 km square, so what AWS sees is the tile, not your position), the text you type into a place search from Geoapify or, on the higher plans, Google, and — for the assisted mode of Find your viewpoint only — the subject you are planning around, including its coordinate, to OpenAI. Each is named in Providers and sub-processors.

Analytics — opt-in

Analytics is OFF by default. Turn it on from Settings → Privacy → Share usage analytics. When it’s on:

• We forward behavioral events (e.g., “user viewed Explore tab”, “user captured a Location”, “trial converted to paid”) to Mixpanel via an EU-resident ingest endpoint (api-eu.mixpanel.com).
• Each event carries your user UUID (the same one in our database) and a fixed set of allow-listed properties — closed enums or booleans, never free-text from your Locations, Lists, or photos.
• Your IP address is forwarded with each event, so that Mixpanel can attribute it to a country and city rather than to our server’s location. That is coarse, network-derived location — not your GPS position, which is never sent. If you would rather not have it sent, leave analytics off.
• Beyond that: name, email, GPS coordinates, EXIF, your Location/List/plan names, anything you typed — none of it is ever included in analytics. The backend enforces this with a closed allow-list on the event-ingest path; events that try to carry disallowed properties are rejected at the edge.
• You can turn analytics off any time. The pipeline stops immediately. Deleting your account also queues a deletion request to Mixpanel that purges your historical events.

Full breakdown: How analytics work.

Providers and sub-processors

Viewpoint relies on the following providers. None of them have access to your unencrypted account or data beyond what their service requires. Which of them your copy of the app talks to depends on the platform you’re on, so each entry says so explicitly.

Most of these are inside the EU or are your own platform’s services. Two are not, and they are the ones worth reading closely: OpenAI receives what you type into Find your viewpoint and the coordinate of the subject you are planning around, and Mixpanel receives your IP address with each analytics event if you have opted in.

No provider on this list receives your photographs. The automated safety check that reads every uploaded image runs on our own servers.

Our own infrastructure (both platforms)

• Self-hosted infrastructure — the API server, the PostgreSQL database, the object storage that holds your captured photos, and the automated safety check that reads every uploaded image all run on owner-operated infrastructure located in the EU. No third-party cloud host stores your account data or photos, and your photographs are never sent anywhere outside that infrastructure.
• Cloudflare — provides the secure network tunnel and DNS that route traffic to the backend (TLS terminates here in transit; Cloudflare does not store your account data or photos).

Apple — iPhone and iPad, plus sign-in on the web

• Sign in with Apple — on iPhone, iPad and the web app, and only if you choose that sign-in method. On the web this loads Apple’s sign-in script into the page.
• StoreKit — payments and subscription management. Apple, not us, takes the money and holds the payment details.
• APNs — push delivery for condition alerts. Registered only after you sign in and grant notification permission; if you decline, no push identifier is created.
• App Store Connect + MetricKit — crash and hang diagnostics.
• MapKit, Look Around, Core Location — the tiles of every map other than Explore’s (which uses Google Maps online on Max and Ultra, see Providers → Google), street-level imagery, place search, reverse geocoding, and position fixes (see How location is used).
• iCloud (CloudKit) — Pro only, and it is your own iCloud. The app mirrors your Locations, Lists, plans, watches and captured photos into the private database of your Apple account so your devices stay in step without a Viewpoint account. This is the largest amount of your content that leaves the device with Pro — and it goes to your storage, not ours. We have no access to it, and no Viewpoint server is involved. Photo files upload over Wi-Fi only.
• SKAdNetwork — Apple’s privacy-preserving install attribution. When you first launch the app, and again if you buy Pro or start a Max or Ultra subscription, iOS sends an aggregated, anonymous postback to the ad network that showed you the ad — see Meta below. There is no advertising identifier (no IDFA), no tracking permission prompt, and no advertising SDK in the app; Apple is the sender and it tells the network only that an install or subscription happened, never that you did.

Google — most of it Android-only, two items on both

• Sign in with Google — on iPhone, iPad, Android and the web app, and only if you choose that sign-in method. On the web this loads Google’s sign-in script into the page.
• Street View Static imagery — on all surfaces, including iPhone and iPad. When a Location has no photo of its own, we fetch a street-level preview for it, and that request goes to Google carrying the Location’s coordinates. It is made by our backend, not by your phone, so Google sees the coordinates and our server’s request — never your account, and never your device’s address. The same is true of the street-level preview in the web app.
• Google Map Tiles API (3D view) — iPhone, iPad, Android and the web app, Ultra plan, beta. The 3D view draws Google’s photorealistic 3D map tiles. Your device asks tile.googleapis.com for them directly, so Google receives the area you are looking at, our Map Tiles key and your device’s IP address, as any Google service does when your device contacts it. Our servers are not in this path, we do not store or cache the tiles or the requests, and no account, photo, Location or plan is sent. The 3D view needs a connection. 3D world on the web. If you have Ultra and open the 3D view in Viewpoint on the web, your browser loads Google Photorealistic 3D Tiles directly from Google (tile.googleapis.com) for the area around your camera pin, as the iOS and Android apps do. Google receives the requested map area, your IP address and the address of our web app (web.getviewpoint.app) as the referring page; Viewpoint does not proxy, store or cache these tiles. Where no photorealistic coverage exists, the view shows open terrain imagery (Sentinel-2 cloudless by EOX, CC BY 4.0) served from our own servers. Google’s own Privacy Policy applies to what it receives.
• Google Places API (place search) — server side, on the higher plans only (Max and Ultra). When you search for a place by name, our backend asks Google’s Places API first and sends the text you typed and the language of your app. Google does not receive your account, your device or your IP address, only our server’s request. We do not store Google’s answers. If Google has no answer, or on any other plan, the search is answered by Geoapify instead (below).
• Static map images — the web app is different, and it is worth knowing. The small map picture on a shared plan card in the web app is loaded by your browser directly from Google, not proxied through us, and the coordinate is in the image’s address. So for that one, unlike the preview imagery above, Google sees the coordinate together with your IP address and browser. The same is true of the interactive maps the web app draws, which are Google’s and run in your browser. In the phone apps, Google Maps appears in Explore on Max and Ultra (and, on Android, on the other map screens) and Google receives the map requests directly from your phone — see How location is used.
• Firebase Cloud Messaging + Firebase Installations — Android only, and this one is not conditional. Google’s Firebase libraries start with the app and register the install with Google at first launch — before any sign-in, before the onboarding screens, and whether or not you ever allow notifications. Google receives an install identifier for the app on your device plus the usual technical details of such a request (app and library version, device model, OS version, IP address). It does not carry your account, your email, your Locations, or your location. We only store the resulting token, and only once you’re signed in; when you sign out we invalidate our copy, but Google’s registration lives until you uninstall the app or clear its data.
• Google Play Billing — Android only. Payments and subscription management on Android are Google’s, not Apple’s. If you’re signed in when you buy, your Viewpoint account identifier is passed to Google Play with the purchase so the subscription can be matched to your account, and Google reports the subscription’s state to our server. Buying as a guest passes no identifier of ours. If you bought as a guest and later sign in, the app sends that purchase’s Google Play token to our server with your account, on any plan, so the purchase is matched to you and follows you to your other devices.
• Google Maps SDK — Android, and the Explore map on iPhone and iPad while you are online on Max or Ultra. Google is the processor for the map display in Explore. The iPhone and iPad SDK (version 11.2.0) declares in its own privacy manifest that it collects a device identifier (linked to the device, for analytics and app functionality), other data (linked), and crash, performance and product-interaction data. That collection is Google’s, under the Google Privacy Policy; we never send Google your account, your Locations or your plans. On Android it also covers Street View, Android’s geocoder and Google Play services’ fused location provider. Map tiles, street-level imagery, place searches (the text you type), reverse geocoding of a deliberately blurred coordinate, and position fixes go to Google. See How location is used.
• Google Maps JavaScript API, Places Autocomplete, Street View and Static Maps — web app only. The browser loads these from Google directly, so Google sees your IP address along with the map region, the coordinate, or the text you typed. See How location is used.
• Google Fonts — the web app and our website; not the phone apps. Our two typefaces are loaded from Google’s font CDN rather than served by us, so Google sees the request — your IP address, your browser, and the page you came from. That happens on every page of the web app, on every page of getviewpoint.app including this one, and again inside the assistant panel when you open it. Be aware of the timing: unlike the analytics above, the font request is not behind the cookie banner — it fires as the page loads, whether you go on to accept or decline. No account data is involved and nothing is stored; it is a hosting choice rather than a tracking one, and self-hosting the font files would remove it.
• Google Play Console — Android only. Crashes and ANRs on Android reach us through Play’s standard OS-collected reporting; the app itself contains no crash-reporting code.
• Google Play Developer API — Android only, server side. To confirm a subscription is real, our server sends the purchase token back to Google for verification. The same mechanism runs a one-time, stateless check for anyone who bought Viewpoint’s earlier Offline or Online (now Max) subscription on Android: your active purchase token is checked against Google’s API to grant Pro permanently, with no account and nothing stored.
• Not used on any platform: Google Analytics / Firebase Analytics, Google advertising, Google’s advertising identifier, and Google’s attribution SDKs. The Android app deliberately ships Firebase messaging only.

Meta — iPhone and iPad only, and only in the aggregate

• We advertise Viewpoint on Instagram and Facebook, so we need to know whether those ads work. On iPhone and iPad that measurement runs entirely through Apple’s SKAdNetwork: when the app first launches, and again if you buy Pro or start a Max or Ultra subscription, Apple — not the app — sends Meta an anonymous, aggregated postback saying an install or a subscription happened. There is no Meta SDK in the app, no advertising identifier, no tracking permission prompt, and nothing that links the event to you, your device, or your account. Apple deliberately delays and coarsens these postbacks so they cannot be traced back to an individual. Nothing equivalent runs on Android or the web.

Everyone else (both platforms)

• Mixpanel — analytics (only if you opt in; EU-resident endpoint). In the apps — iPhone, iPad, Android and the web app — there is no Mixpanel SDK on your device: events go to our own server first and we forward them. Each forwarded event carries your user UUID and your IP address, which Mixpanel resolves to an approximate country and city. Nothing else identifying goes with it — see Analytics. Our website is the exception, and it works the other way round. getviewpoint.app does load Mixpanel’s own script into your browser — but only after you accept the cookie banner, and it is configured to tell Mixpanel not to record your IP address. Decline the banner and the script is never loaded at all.
• Open-Meteo — weather forecasts, satellite cloud and radiation readings. Calls go through our backend; your account identity is never sent to Open-Meteo, only the latitude/longitude of the location you’re checking.
• Geoapify — place search. Calls go through our backend; your account identity and IP address are never sent to Geoapify, only the place name you type into search.
• NASA — the night-time light measurements (Black Marble) behind the light-pollution map. Our backend downloads the public dataset from NASA’s servers on a schedule; the request is the same for everyone and carries nothing about you, your account or your locations. NASA and the U.S. Naval Observatory also supply the sky events in Explore and Conditions, and every one of these requests is made by our server on a schedule, never by your device, with nothing about you in it:
  • aa.usno.navy.mil — U.S. Naval Observatory: moon phases, equinoxes, solstices and Earth’s apsides. The request carries only a year.
  • eclipse.gsfc.nasa.gov — NASA GSFC eclipse catalogue: solar and lunar eclipse circumstances, from fixed catalogue pages.
  • ssd.jpl.nasa.gov — NASA JPL Horizons: planet positions for a date range, computed for the centre of the Earth, so no location of yours is in it.
  • ntrs.nasa.gov — NASA Technical Reports Server: the Meteoroid Environment Office annual meteor forecast we credit. Its figures are an import checked into our code, so no request to it is made while the app runs.
  • www.nasa.gov — NASA’s media usage guidelines, the terms we follow when we use NASA material. A reference link; no request to it is made while the app runs.
• GeoNames (download.geonames.org) — a public list of place names. Our server downloads the whole list on a schedule to answer “nearest place name” from our own copy, so a coordinate you look up is never sent to GeoNames. The request is the same for everyone.
• EOX (tiles.maps.eox.at) — the Sentinel-2 satellite imagery on the Explore map. Your device asks our server for an imagery tile, and our server fetches it from EOX and keeps it. EOX therefore sees our server’s address and the tile requested (a square of the map), not you.

• OpenAI — reached from two places, always through our backend and never from your device.

  1. The assisted mode of Find your viewpoint. Two calls happen there and they send different things. Reading your request sends the words you type (up to 2,000 characters), which OpenAI turns into a structured query — which landmark, which body, what time window. Proposing vantage points then sends the subject you are planning around: its name and its coordinate (to about a metre), plus the alignment and time window you asked for, so the model can suggest places to shoot from. If you started the feature from one of your own Locations, that Location is the subject — so its name, which you wrote, and its location go with the request. Your account identity is not sent, and none of your other Locations are. The deterministic mode of the same feature makes no call at all.

  2. The assistant on our website. Every page of getviewpoint.app — including this one — carries a small chat button, the Viewpoint Assistant. Whatever you type into it is sent through our backend to OpenAI, both to find the relevant documentation and to write the answer. Type nothing into it and nothing is sent. It has no idea who you are; it is not connected to your account, and it is available to anyone reading the site.

  (An earlier version of this policy said coordinates and saved Locations were never sent to OpenAI, and that OpenAI was reached only from Find your viewpoint. Both were wrong, and this entry corrects them.)

• Wikimedia (Commons, Wikidata) and OpenStreetMap’s Overpass service — used to find an existing public photo and place name for a Location that has none of its own, and to look up landmarks and legal-access boundaries while planning. Called by our backend with the Location’s coordinates, or an area around them; no account identity is sent.
• Amazon Web Services — terrain elevation tiles from a public open-data bucket, used to work out what the horizon and the skyline look like from a Location. Our backend requests the tile covering the coordinate; a tile spans roughly a 10 km square, so AWS sees the tile, not your position. The alignment search reads the same tiles to work out the ground height at your camera and subject pins and between them: the coordinates of the pins are used by our server, and AWS still sees only tiles. The 3D view’s open-terrain fallback (used where Google has no 3D coverage) also reads these elevation tiles directly from your device, so AWS sees the tile address and your device’s IP address. No account identity is sent.
• Esri (ArcGIS) and the European Environment Agency — protected-area boundaries used to warn you when a viewpoint falls inside a nature reserve or a national park. Our backend sends a bounding box around the area you are looking at; no account identity is sent. These feeds are optional and off unless configured; when they are off, no request reaches either.
• Your browser’s push service — web app only, and only if you turn browser notifications on. The address your browser hands us belongs to whoever makes your browser (Mozilla for Firefox, Google for Chrome and Edge, Apple for Safari), and that service delivers the alert to you. It can see that a notification was sent to your browser instance, and when — the contents are encrypted with a key only your browser holds, so the service cannot read the alert.
• Slack — a private channel Marcos reads. Two things reach it. Support messages: when you write from Settings (Talk to Marcos on iPhone and iPad, Message support on Android, and the same on the web app), your message goes there with your account UUID, your plan, and your app version and device model — plus your email address only if you tick the opt-in box, which is off by default and labelled with the address it would send. Server error alerts: when something fails on our side, the error line is posted there too, so a fault gets noticed rather than sitting in a log. Those alerts carry the technical failure and where in the code it happened — and, on iPhone and iPad, a summary of a crash your device reported. They do not carry your photos, your coordinates, your notes, or your email.

What we don’t do

• No ads inside Viewpoint — no banners, no interstitials, no advertising SDK in any of the apps. (We do buy ads elsewhere to tell people the app exists, and on iPhone and iPad Apple sends the ad network an anonymous, aggregated result — see Meta.)
• No cross-app tracking — no advertising identifier on either platform, no tracking-permission prompt because there is nothing to ask for, no fingerprinting.
• No data sale — your data isn’t a revenue stream and never will be.
• No third-party crash or analytics SDK in the apps — on iPhone, iPad, Android and the web app the only analytics is ours, opt-in, and forwarded from our own server. (Our website is separate: it loads Mixpanel’s script in your browser once you accept its cookie banner. See Mixpanel under Providers and sub-processors.)

Your rights (GDPR — including Article 17, Apple Guideline 5.1.1(v), and Google Play’s User Data policy)

Viewpoint launches in the EU; the EU General Data Protection Regulation applies.

• The right to erasure (Article 17). Every platform’s Settings has a Delete account action — iPhone, iPad, and Android alike. Triggering it permanently deletes your profile from our servers and every record that depends on it — Locations, photos, Lists, plans, routes, watches, device tokens, sessions, subscriptions and purchases. Captured photos in our object storage are scrubbed by a background job within minutes. Mixpanel events are queued for deletion via Mixpanel’s GDPR-erasure endpoint. The library already stored on your own device is deliberately left in place, the same as on sign-out, so deleting the account doesn’t take your captures with it. You do not need the app installed to do this — see Delete your account for the web request path, the full list of what is erased, and what is retained and for how long.
• Access and portability. Self-service export isn’t built yet. Email [email protected] and we’ll send a JSON dump of everything tied to your account.
• Withdrawing consent. For analytics, toggle Settings → Privacy → Share usage analytics. The change is immediate — the next event your phone would have sent is the first one suppressed. See How analytics work for the full picture.
• Objection, rectification, restriction. Email [email protected] for any GDPR rights request not covered by the in-app surfaces above. We will respond within 30 days.
• Cancel your subscription through the store that bills you, using its own instructions: Apple or Google Play. Cancellation is independent of account deletion. If you cancel Viewpoint Max or Ultra without deleting your account, the copy of your library on our servers (your Locations, their photos, Lists, shoot plans, routes and condition watches) is deleted from our servers 7 days after your subscription ends. Your account, your billing history and everything on your device stay. Subscribe again within those 7 days and nothing is deleted. What the people you share with added to your Locations and Lists is kept, your shares stay in place, and a shared Location’s pin stays on our servers, without its name, your notes or your photos, until you subscribe again. If you delete your account without cancelling, the subscription keeps billing until you cancel it in the store, because only the store can stop the billing.

Changes to this policy

If we change this policy in a way that affects you, the Last updated date at the top of this page reflects when. Material changes (new sub-processors, broader data collection, change in operating entity) will be announced in-app and via the email associated with your account before they take effect.

Contact

For any privacy question, request, or complaint: [email protected].