Privacy.

Consumer summary / 要点

Technical details / 詳細

The sections below are the full technical layer behind the summary above: what each feature sends, to which provider, and what is stored where. Your itinerary is parsed and scheduled in your browser. Place and hotel text is sent through protected TripCheck endpoints only when a map provider must locate it. TripCheck does not store the itinerary in a server database or make it available for human review. Up to ten recent plans may be kept only in this browser so you can reopen them. 以下は上の要点を裏づける技術的な詳細です。

Weather outlook

For trip days inside the forecast horizon, TripCheck may send the calendar date and the approximate geographic centre coordinates of that day to Open-Meteo after the route is already usable (directly from your browser where this site is served as static files). It does not send place names, itinerary text, hotel text or reservation notes. The forecast is shown as optional planning context and never moves a stop or decides whether a plan is feasible.

Open-Meteo weather data is attributed under CC BY 4.0. Its free service may process request IP addresses and coordinate-bearing web-server logs for service protection and troubleshooting; Open-Meteo states that those logs are deleted after up to 90 days. See the Open-Meteo terms and privacy information.

Public holidays

To warn about public-holiday closures, TripCheck sends only the destination's two-letter country code and the bare calendar dates of the trip to the Nager.Date public-holiday service — directly from your browser where this site is served as static files, otherwise through a protected TripCheck endpoint. No place names, itinerary text or coordinates are included in the request, and it is optional context that never gates the plan.

Map and key-free place lookup

The result map uses MapLibre and the key-free OpenFreeMap style by default. Opening it makes style, font and map-tile requests from your browser to tiles.openfreemap.org, so that service receives your IP address and ordinary web-request metadata. OpenFreeMap receives no itinerary text from TripCheck. If its map cannot load, TripCheck keeps the same coordinates visible in a local schematic fallback. Map data is attributed to © OpenStreetMap contributors.

When you explicitly choose to create or re-check a plan, your browser looks each unknown place name, and the hotel or area text you entered, up directly in Wikipedia and Wikidata (operated by the Wikimedia Foundation) and, when it is reachable, in the Photon search service operated by komoot, which is built on OpenStreetMap data. A name those sources cannot place is sent, one bounded search at a time, to the public OpenStreetMap Nominatim service. Nominatim is never used for autocomplete while you type. Because your browser makes these requests itself, these services receive the place name, the interface language and, once the rest of your list has shown where the trip is, an approximate trip-area coordinate, together with your IP address and ordinary web-request metadata; they never receive your dates, times, notes or the rest of your itinerary. Where the operator has connected the Apple Maps Server API, a place name the open sources could not place, and the coordinate of a meal area when you ask for places to eat, are sent to a relay on TripCheck's own server, which forwards only that search to Apple; Apple receives no itinerary text and not your browser IP. Photos of sights are loaded by your browser from Wikimedia Commons, which therefore sees your IP address and which photos were shown. Train legs are worked out in your browser from a station map shipped with the site; no journey is sent anywhere. To draw a walk or a drive along the actual streets, the coordinates of the two places at either end of that leg are sent to the relay and on to Apple, or, where Apple has no answer, by your browser to the OpenStreetMap routing service operated by FOSSGIS e.V. (routing.openstreetmap.de), which therefore sees those two coordinates and your IP address. See the Wikimedia privacy policy and the Nominatim usage policy.

Paid Google place resolution, Google autocomplete and Google Maps display are disabled by default. A deployment operator must deliberately enable each public opt-in as well as the corresponding server-side provider access before those requests can occur.

Planning-time routes

When paid route access has been deliberately enabled, after the core dated plan appears TripCheck sends only the origin and destination coordinates, route mode and planned departure time for each bounded route leg to a protected TripCheck endpoint. That endpoint requests transit, walking or driving duration from Google Maps Platform and progressively replaces estimates. With paid route access disabled, the plan keeps clearly labelled estimates and no Google route request is made. Walking requests do not send the departure time onward to Google. Your pasted notes, hotel text and reservation descriptions are not included.

When enabled, the same protected TripCheck endpoint requests Google's encoded route geometry so the map can follow actual roads and transit paths. The browser receives only the bounded route result; route responses are used in memory for the current page and are not stored by TripCheck. Google processes the provider request under the Google Privacy Policy.

Planning-time place checks and recommendations

Google autocomplete is a separate paid feature and is disabled by default. If a deployment deliberately enables it, pausing after typing sends that one place name, interface language and selected destination country to a protected TripCheck endpoint so Google Maps Platform can return a short candidate list. If you choose a Google candidate, only its stable Google Place ID is retained with that input occurrence. Paid Google resolution can likewise be enabled as a fallback to the key-free build-time lookup described above; the core planner may then request the identity and opening-hour fields needed to check the selected itinerary. The response is not stored by TripCheck. A specific hotel name is sent only when it must be resolved or matched as a named property.

When paid recommendation access is enabled, after the resolved places produce a usable core plan TripCheck automatically looks up bounded hotel and meal shortlists. Automatic hotel discovery sends a search-anchor coordinate, up to ten day-route coordinates, a bounded area label, interface language and destination country to a protected TripCheck endpoint. Meal discovery sends the meal-slot coordinate, a bounded area and query, lunch or dinner, interface language and destination country. For a dated meal slot, its date and planned meal time are sent to the TripCheck endpoint only so returned structured opening periods can be checked in memory; Google receives the bounded location, category or query and language/region fields, not that travel date or time.

When a completed day has a gap of 30 minutes or more, TripCheck automatically looks up one bounded along-route shortlist. The gap's length selects only which bounded nearby-place categories are requested. It sends up to twelve sampled coordinates from available Google route geometry (falling back to the ordered stops), interface language and destination country to a protected TripCheck endpoint. If selected lodging is the day's base, its coordinate may be one of those route points. Existing public place IDs and names are used by the endpoint only to remove duplicate suggestions and are not included in the Google search request. Google receives the coordinates and a bounded nearby-place query. The automatic hotel, meal and gap searches do not send Google your raw itinerary lines, raw hotel text, travel dates, reservation notes, airport details or completed schedule.

Google may return public listing fields such as names, coordinates, opening periods, ratings, review counts, photos and Google Maps links. Food and gap-fill suggestions stay in page memory and are never automatically accepted: they are recalculated as ordinary itinerary items only after you explicitly choose one. If you leave the hotel unspecified and ask TripCheck to recommend a base, the leading hotel candidate may be used as a provisional planning base and remains replaceable.

These paid-provider endpoints require same-origin requests, apply individual hotel, food and route feature kill switches, set no-store response controls and reserve bounded request, anonymous-session, trip, day and month quotas before provider access. Production requests fail closed when the durable quota store is unavailable. The quota ledger contains only opaque subject hashes plus provider, operation, scope, time bucket and counts; it does not contain itinerary, place, hotel, date or reservation content.

Photographs shown on hotel, meal and place cards are fetched one at a time from Google Maps Platform when the card is displayed. Each request carries only the photo reference Google itself returned for that listing, together with a short-lived signature TripCheck issued for that exact reference; it carries no itinerary, place name or date. Photo requests are counted against the same bounded request, anonymous-session, trip, day and month quotas as every other paid endpoint, and a photo TripCheck did not issue a signature for is refused before Google is contacted.

Source cards from the public-web check show the cited page's own preview image. That image is fetched by TripCheck's server and passed through to the browser, so the cited site never receives a request from the traveller's device, never sees an IP address, and cannot set or read a cookie. Only a page address the public-web check itself returned is fetched, and only with a short-lived signature TripCheck issued for that exact address; the response must be an image, is size-limited, and no redirect is followed. The same signature requirement applies to reading a page's title and description for those cards.

When Rakuten Travel integration is configured, TripCheck may also send only the hotel-search anchor coordinates to Rakuten Web Service. Rakuten may return nearby property names, coordinates, a reference minimum charge, review score, review count and a Rakuten Travel page URL. TripCheck attaches these facts only to a clearly matching Google-listed property and links the displayed Rakuten information back to Rakuten Travel. It does not send your itinerary text, travel dates, airport details or completed schedule to Rakuten.

Google evidence is ranked and converted into schedule constraints by deterministic code. Structured opening periods are checked against each travel date; flexible places may move to an open day, and a place with no usable verified window is left out and disclosed. TripCheck does not send your full itinerary, dates, reservation notes, airport details or completed schedule to an AI.

Selecting a stop can automatically load its current Google listing in the detail panel. For meal candidates discovered beside the active day's route, TripCheck may send only the supplied candidate names, public addresses, place types, meal period and area to Anthropic, which writes compact comparison labels for those candidates. For the shortlisted hotel candidates it may also send their names, bounded areas, Google rating and review counts, planner-computed travel minutes and style or price hints to Anthropic, which may run up to three web searches to check recent reputation before writing its comparison notes. In both cases deterministic TripCheck code chooses the recommended order and the recommended base among the shortlisted candidates; the AI only writes short explanation labels for the supplied candidates; the AI cannot add a restaurant or invent ratings, opening hours, prices or menu facts, and every displayed fact stays Google-owned. TripCheck sends a resolved place, restaurant or hotel name, its public address or area, interface language and search purpose to Anthropic's web-search tool only when you request recent public-source context or explicitly refresh an eligible result. It does not automatically run public-web searches for every place in a new plan. Anthropic may search indexed public sources such as X, Instagram, local news and firsthand blogs. TripCheck accepts only source URLs actually returned by the search, shows factual notes only when a cited excerpt is available, rejects sources verifiably older than 90 days and labels unknown dates instead of presenting them as recent. A quick check is capped at one search and this optional enrichment never blocks access to the core itinerary.

Results are held in page memory and are not written to a TripCheck database. To prevent duplicate charges, the public-web result may remain in server memory for up to 30 minutes. If AI search is unavailable or slow, the Google listing and rule-based checks remain usable. Anthropic processes the search under the Anthropic Privacy Policy.

Device storage

TripCheck stores your interface language and up to ten recently generated plans in this browser. Plans use IndexedDB when it is available and fall back to non-persistent in-memory storage when private-mode or browser restrictions prevent it. A saved entry contains the user-authored inputs and edits needed to reopen that plan. If you explicitly choose one ambiguous Google match, it may also contain only that stable Google Place ID so TripCheck can request the current listing again; it does not save Google's display name, address, hours, reviews, photos, route response or other variable provider content. A manual pin retains only the name, address and coordinates you entered. You can remove each recent plan from the planner, and clearing this site's browser data removes all persistent copies.

If you enter your passport expiry date for the validity check, it is kept only in this browser's local storage and is never sent to TripCheck or any provider — the comparison against the destination's validity rule happens entirely on this device. Clearing the field or this site's browser data removes it.

Share links

When you choose to copy a share link, the same form inputs, explicit Place-ID choices and any traveller-authored manual pins are encoded in the URL fragment after the # symbol. Browsers do not send that fragment to TripCheck when opening the page, and TripCheck does not store the link. Anyone who receives the complete link can read and rebuild the shared trip, so treat it as containing your itinerary and do not share it more broadly than intended.

Operational data

TripCheck records a small, enumerated set of aggregate funnel events so it can measure whether the planner works and control provider cost. Allowed fields are limited to counts, elapsed solver time, result state, provider/error category and the type of alternative applied. These events contain no itinerary text, place or hotel name, address, exact date, reservation detail, Place ID or stable user identifier. Unknown fields and free text are rejected by the event endpoint.

Normal hosting and logging infrastructure may process an IP address, request time and basic request metadata to deliver and protect the service. TripCheck does not intentionally place itinerary content in analytics or application logs. Operational log retention follows the configured hosting provider retention period and must be reviewed before production release.

Contact and changes

This early product does not yet create user accounts or process payments. The policy will be updated before introducing server-saved trips or any AI processing of full itinerary text.