What we store, and what we don’t

No Google Analytics. No Facebook Pixel. No advertising or attribution tags. No session replay or heatmaps. No profiling, and nothing sold or shared with data brokers. No third party is given anything about you beyond what the services listed below need to do their one job.

This site used to show a cookie banner asking permission for Google Analytics and the Facebook Pixel. Neither was ever actually installed — the banner was gating tracking that did not exist. We removed it rather than leaving you a decision to make about nothing.

This app runs on Base44, and its platform records a first-party page view each time you open a page here. It is theirs and ours, not an advertising network’s, and it does not follow you off this site.

• What it records — the path you opened (for example /privacy), the time, the page you arrived from, and your account id if you are signed in (nothing, if you're not).
• Session id — a random string kept in your browser's local storage, so several page views in one visit can be counted as one visit rather than several. It is not tied to you, and clearing your browser storage ends it.
• What it's for — knowing which pages get used, so we build the ones that do. Nobody is targeted, scored or advertised to on the back of it.

It is part of the hosting platform rather than something we added, and it cannot be switched off from our side. If that matters to you, a tracker blocker will stop it without breaking anything on this site.

All of it is in your browser’s own storage, and all but the last line is there to make something you asked for work.

• Sign-in session — keeps you logged in. Set by Base44, which hosts this app.
• Onboarding flag — remembers you finished the intro so it doesn't ambush you again. It lasts until you close the tab.
• Onboarding answers — if you answer the set-up questions without an account, they wait here and are added to your account the first time you sign in and come back to set-up.
• Checklist progress — your own ticks on the remote work checklist, saved in your browser so you keep them without an account.
• Schengen stays — the stays you enter in the Schengen calculator. They are kept on this device only and never sent to us.
• Tour progress — which stops of the two-minute tour you have opened, so they show as ticked.
• Nearby OpenStreetMap results — what OpenStreetMap listed near a place you searched on Find a spot, so going back to it doesn't ask again. It lasts until you close the tab.
• Last visit to Spots — the time you last looked at the spots list, so it can say what has been added since.
• Check-in draft — a report you started writing but haven't filed, so a refresh doesn't lose it. It lasts until you close the tab.
• Platform keys — a handful of Base44 values: the app id, a stored answer to the old cookie prompt, and the page-view session id described above.

Clearing your browser storage clears all of it. The checklist ticks and your Schengen stays are the only things you would actually miss.

“Use my location” on Find a spot asks your browser where you are, only when you press it, and your browser asks your permission first. The exact position stays in your browser. We round it to about 100 m before it goes anywhere: into the page’s address, so the results can be shared (which also means our host’s page-view log can see it, like any address), and to OpenStreetMap and Open-Meteo, to look up what’s nearby. Nothing on our side stores it.

Some features work by asking someone else. Your browser connects to these directly, so they see your IP address, as any site you visit does. Beyond what each line says, we don’t send them anything about you.

• OpenStreetMap map tiles — draw every map on the site.
• OpenStreetMap (Nominatim) — turns an address into map coordinates when you look one up while adding a spot.
• postcodes.io — looks up a UK postcode when you add a spot, or when you search with one on Find a spot.
• OpenStreetMap (Overpass) — lists the cafés, libraries and coworking spaces near a place you search on Find a spot. It is sent only that map point, rounded to about 100 m.
• Open-Meteo geocoding — suggests towns and cities as you type a place on Find a spot, so it sees the letters you type there.
• Cloudflare — runs the Wi-Fi speed test on a check-in (download, upload and latency), and only when you start one. The upload part sends it a few MB of blank data. Its answer also names the network you're on: we keep only the provider's name and network number (ASN) from it, never your IP address or location.
• Open-Meteo — sends the live forecast for the Trip Watch demo in the Engine room, and only when you run it. On a Find a spot trip search for a city the team planner doesn't cover, it also sends a month's past weather for that place, given only the map point rounded to about 100 m.
• Wikimedia Commons — serves the demo photos inside seeded reports. Venue photos are copies of Commons files that we host ourselves, so they make no request to Wikimedia.
• Google Maps photos — Google's photos of a venue, on spot pages and spot cards, load straight from Google's image server (googleusercontent.com), so Google sees your IP address when one loads. We ask your browser not to send it the page you were on.

The two typefaces the site is set in are served from this site itself, not from Google Fonts.

Trip Watch’s forecast check and the weather part of a city’s score run on our server, not in your browser, so these services see our server’s address, never yours. They are sent a city’s map point and, for Open-Meteo, the days wanted; nothing about you, your team or your trip’s name.

• Open-Meteo — gives the daily forecast Trip Watch re-scores your cities with, and the past weather a city's score uses for your dates.
• MET Norway — the Norwegian Meteorological Institute's forecast, asked only when Open-Meteo has no answer for a city. It is sent only the city's map point, rounded to four decimal places (about 10 m), and a line naming this app with our contact address, as its terms ask.

A spot page’s “On Google” panel shows Google’s public listing for that venue (rating, opening hours and Google’s review summary), and its “Working environment” card shows a few of Google’s listed facts (coffee, food, outdoor seating, wheelchair access, price level). Our server fetches them from Google Places at most once a day per venue, and only when the card or the panel comes into view. Google is sent only the venue’s name, town and map point. Nothing about you goes with it, not even your IP address, because the request comes from our server. Our server keeps Google’s answer about the venue for up to a day, so the next view of that spot doesn’t ask Google again; it holds nothing about you. Beyond that, only Google’s id for the venue is kept. The “View on Google Maps” and review links open Google’s own site, under Google’s privacy policy.

Photos from Google are shown live; we never store the photo itself. When a spot page or a spot card comes into view, our server asks Google for that venue’s photos, using only Google’s id for the venue, and passes your browser a short-lived link to each one. We keep that link, with its credit, for up to a day so the next visitor doesn’t cost another request, and check it still works before reusing it. Each photo is credited to the person who took it, with “Google Maps”.

When you ask Ask RWA a question, our server sends the words you typed to Google’s Gemini API, which chooses spots from our list and OpenStreetMap and writes the short line under each. On Find a spot it is also given the place on screen: its name, and its map point rounded to about 100 m. Google is not told who you are, and because the request comes from our server, it doesn’t see your IP address either. Please don’t put personal details in a question. To answer, our server also asks OpenStreetMap (Overpass) and Open-Meteo (place search and the day’s forecast), sending them only a place name or a map point. The question itself is not stored.

The app’s data lives with Base44, which hosts it. Anything private below is readable only by your own account (and by us, as the app’s admins).

• Your account — your sign-in details, and the settings you choose: home city, timezone, working hours, passport country, trip budget and what you care about in a spot.
• Trips, teams and saved spots — the trips, budgets and itineraries you create, your saved spots, and the teammates you add (the name, email, timezone and working hours you enter for each). Private to your account.
• Team planner — each run that uses the AI step stores the day and either your account id or, if you're signed out, a salted hash of your IP address that changes every day. That is only to apply the daily AI limit; we never store the IP itself, names or the team you typed. The AI step goes through Base44's AI service and is given the teammates' timezones and each city's figures, never names or emails. A public run log keeps counts only (cities checked, picks made).
• Google lookups — each "On Google" panel that loads, and each Google photo shown, stores the day and either your account id or, if you're signed out, a salted hash of your IP address that changes every day. That is only to apply the daily limit on Google lookups; we never store the IP itself, or the photo.
• Ask RWA — each question stores the day and either your account id or, if you're signed out, a hash of your IP address keyed with a secret only our server holds, which changes every day. That is only to apply the daily limit on questions; we never store the IP itself or the question.
• Usage counts — when you're signed in, each AI call and team email is counted against your account id for the day, to apply the daily limits.

All of them are sent through Base44’s email service, and only when you ask for them:

• Trip Watch — to the trip's owner, if they switched it on for that trip, and only when the best city changes or the forecast flags something.
• Monday brief — to the team's owner, if they switched it on for that team.
• Your itinerary — to you, when you press the button to email it.
• Notify team — to the teammates you added to a trip, with the trip dates and their shared hours, when you press the button.

Posting a trip to a team chat sends its summary to the Discord or Teams address you paste in. That address isn’t stored.

We store your email address, the first name you gave us, the date and time you opted in, and the exact wording of the opt-in you ticked. That last one matters: it means we can show precisely what you agreed to, rather than just claiming you agreed.

We only add you if you tick the box. If you don’t tick it, nothing is saved at all — we don’t keep the address for later. The guide hasn’t launched and nothing is sent yet: the list is used for one email telling you it has, and nothing else.

The partnerships form stores the name, email, company, role and message you send, so a person can reply. The “Tell us your working policy” form for venues stores the venue’s answers, your name and your email the same way, so a person can review them and reply; nothing from it is published automatically. Asking to hear when Pro launches stores your name and email, and we email you once when it can be bought. Neither adds you to a mailing list.

Spots, reports, check-ins and reviews you file are shown publicly on the site under your profile name, because the whole registry is built from them. A check-in photo is public too, under your name. If you follow someone, that is stored against your account. Your email address is not shown.

A check-in’s Wi-Fi test stores the speed results (download, upload, latency and jitter), the network provider’s name and network number (ASN), and how to get on the Wi-Fi. We record the speed results and the network provider name, not your IP or location beyond this venue. We never store a Wi-Fi password: anything in your note that looks like one is removed before it is saved.

A check-in can also record one-tap answers about working there: power sockets, calls, noise and music, seating, what it costs to work, laptop rules, the price of a coffee and whether food is served, plus an optional one-line worker deal (links are taken out, and a deal with anything in it that looks like a password is not saved at all). They are public with the rest of the report, and the spot page shows them as counts, such as “4 of 6 members”.

A check-in can include one photo of your table. Your phone shrinks it and removes its location and camera details before it is uploaded. Every photo is then reviewed automatically, by our server sending it to Google’s Gemini API, before it can be added: a photo showing someone’s face, a child, anything explicit or offensive, a screen or document someone could read, a password, Wi-Fi code or door code, a number plate, or signs and writing is rejected and never attached to your report, and so is a photo the check isn’t sure about or that isn’t of a place to work. Gemini isn’t told who you are. An accepted photo is shown publicly in your report, and may become the spot’s main photo. We can also take a photo down by hand. The same check suggests a few answers (sockets, seating, daylight) for you to confirm; nothing is saved unless you tap it. Each check stores the day against your account id, to apply the daily limit of 10.

A spot with notes from three or more check-ins can show “What members say”: two or three short points our server asks Gemini to write from those notes (never the launch demo data), each linked to the check-ins it came from. Notes are sent without names or account ids.

You can delete your own trips in the app. For anything else, including your whole account, a report or an enquiry, email hello@remoteworkanywhere.com from the address you use here and tell us what you want to see, correct or delete. A person handles it by hand: there is no self-serve delete button for these yet.

There are none today. If we ever add them, tracking a click for commission is not something we can do quietly under “strictly necessary” — we will ask first, in a prompt about exactly that and nothing else, and any link will still work perfectly well if you say no.