Privacy Policy

At a glance

Wingman is operated by Todd Hendricks in Illinois, USA. This policy covers the Wingman website and installed web app. There is no account registration, but that does not make your activity anonymous. Contact todd@hendricks.cc with privacy questions.

Information we process and why

• Your request: the name, age, gender, preferred company, plan text and optional photo you provide; your chosen meetup address and coordinates, time or relative travel allowance, selected transportation mode, travel radius and Wingfam/manual-or-auto status. We use these to display your plan and identify nearby, compatible requests.
• Location and searches: with browser permission, Wingman requests device location at startup and watches for updates while the page is visible. The watch stops when hidden and restarts on return. The browser and operating system determine the update frequency. Suitability and automatic business preparation sample the latest coordinates separately, initially and about every 30 seconds while visible; cached results can avoid downstream requests. Background timers and operating-system restrictions can delay updates. Refreshes update nearby discovery without moving an already selected meetup point. After the current-location suitability screen succeeds, Wingman automatically sends the device coordinates through our server to prepare a mapped business within 50 metres, including its checked main entrance or mapped center. Unsuitable, unknown or failed screens suppress automatic business preparation. The detected name is displayed; clicking Use my location copies this prepared result without a new lookup. The most recent prepared business or no-business result is reused in page memory for up to 24 hours within 5 metres of its lookup origin. Movement or expiry can trigger new preparation on a device update; failures can retry after 30 seconds. Retained precise coordinates can reuse a prepared result. Your device location supports aggregate nearby visitor counts, helps center the map and checks that your proposed meeting point is within the supported area. The distance from your supplied location to that point, together with your selected transportation mode, also limits relative travel-time choices. This calculation uses no new routing provider and does not add a stored journey origin. If device location is unavailable, an IP-based lookup can provide an approximate area. Address autocomplete sends partial text through our server to Geoapify after at least three characters and a short typing pause, or when you submit a search. When available, the current browsing origin is rounded to two decimal places and sent as a proximity hint. This may use device or approximate IP-based coordinates. The hint helps rank suggestions; it is not a newly selected meetup point. An active, undismissed query is sent again when location first becomes available or its rounded hint changes. Updates within the same rounded area do not resend the query, and refresh waits during selection or another busy action. Opening Nearby businesses or changing its distance sends the chosen search center and radius through our server to Geoapify Places. The center is the selected meeting spot when present, otherwise the detected browsing origin, rounded to five decimal places. Once activated, changes to that center can refresh the list. Failed lookups retry about every two minutes while enabled, or when you choose Try nearby businesses again. Selected map points and current-business preparation separately process the coordinates needed to find and screen a place. Device coordinates are also screened to choose a close business view for suitable locations or a wider request view otherwise. The browser temporarily reuses the most recent presentation result within 5 metres for up to 24 hours; this affects map zoom and whether business preparation runs, not approval of a new meetup point. Movement or expiry prompts a new check on a device update; failures can retry after 30 seconds. Candidate meetup coordinates and these device coordinates are sent through our server to the existing Overpass providers to check mapped land use, building footprints and venue eligibility. Names, photos and plan text are not sent for that check. Suitability results are also cached in our database for 24 hours using exact coordinate pairs and a screening-rule version. Each row stores the approved/rejected result, whether it is a business, an explanation and expiry, without a visitor identifier, session identifier, profile or IP address. Exact coordinates can still describe a sensitive place; these are geographic lookup records, not anonymous location data. Expired rows are removed during later successful uncached suitability checks. Up to 500 results may additionally be reused in temporary server memory for the remainder of the same 24-hour period. Expiry stops reuse; it is not a separate physical-deletion timer, and database backup limitations still apply. Reusable mapped venue and building geometry is also cached for 24 hours with its lookup coordinates and expiry. Points within 5 metres can reuse this data when it has sufficient boundary detail; each selected point is classified separately. Derived results retain the source data expiry. Up to 100 map-data records may be held in server memory. Expired map-data rows are removed by shared background cleanup. Provider failures are not stored as suitability decisions. Provider logs have their own retention. Your browser time zone helps interpret your proposed meeting time.
• Match coordination: invitations, acceptances, proposed places and times, readiness confirmations, recognition details and an optional phone number help you agree on and find each other at a meetup. Waiting records associate a waiting request with a target request and match, store queue order and waiting/closure/activation status, and may include the reopened Wingfam request identifier. Failed-attempt records associate two request identifiers to avoid repeating a declined match; an explicit request update clears them, and deleting either request removes them. A manual-approval Wingfam decline notice contains the host request identifier and matcher’s display name until dismissed or the host request is deleted. Auto-allow declines suppress the owner’s decline notice while still recording ended status to remove saved copies. A Wingfam permission stores the posted-request owner’s session-token hash and partner session-token hash, provided recognition/phone details and continuation decision to restrict activation and coordinate close-versus-activation races.
• Session and technical information: a random session identifier and short-lived cookie let you manage your request without an account. The server stores a hash of the session token. IP-derived hashes and counters help limit abusive requests. Hosting systems also process network and device information, requested URLs, timestamps, errors and other operational records to deliver, secure and troubleshoot the service.
• Messages to the operator: if you email us, we receive your email address, message and anything you include so we can respond to a question, rights request or report.

Wingman automatically screens submitted text for dating, sexual solicitation, marriage, wedding and drug-related content, and suggestive, drug-associated or arrow emoji before saving it. The screening runs within Wingman; it does not send text to an external moderation service or keep a separate log of rejected text. The browser may still retain draft text as described below.

Wingman does not add advertising trackers or use your submitted details to target ads. The app does not change its behavior in response to a browser’s Do Not Track signal; the no-sale and no-advertising-sharing commitments apply regardless of that setting. Photos are resized and re-encoded for display, with smaller thumbnail copies; the app does not perform facial recognition or create biometric identification templates.

Recognition choices

We store the recognition option selected for a wingmatch alongside any written description. Your partner can see whether you chose “I’ll find you” before finalization, so both people can resolve a conflicting choice. Written recognition details and preset meeting instructions are included in the finalized exchange. Selecting the front-door option triggers a mapped-business check of the agreed coordinates. These match records follow the match-retention and cleanup rules described below.

Who can see your information

Public requests: other visitors can access your posted name, age, gender and preferences, comment, chosen address and exact coordinates, time, radius, wingfam status and request timing information. These details can be returned in map and request responses even when a particular screen shows only part of them. Treat your meetup pin as public; choose a public venue and avoid putting your home address, phone number or other sensitive details in public fields.

Photos: thumbnails are available with live requests. The app limits opening a full-size request photo to visitors with an active request and a photo of their own. This does not prevent someone from saving, copying or photographing an image they can see.

Your match: proposed meeting details are shared during coordination. Recognition details are revealed to the other person when the wingmatch is finalized. Phone exchange is optional: ordinary pairs reveal numbers only when both have entered one. A Wingfam owner explicitly consents to share their provided meetup details and supplied phone with approved guests even without a reciprocal number. Auto-allow instead makes the selected address, time, written description and supplied phone available to everyone browsing the live Wingfam, including the current match, until the host withdraws or expires. A partner may retain the final details or take a screenshot.

Save and admission notices: each automatic admission stores a guest public quick-info snapshot for the host’s persistent notification queue, until acknowledged or the host request is deleted. Finalization records the match ID, both session-token hashes, display names, owner request ID, save flags, separate owner and matcher session deadlines, and any unmatch initiator and time so participants can see counterpart session status, receive save/unmatch notices, manage Wingfam membership and expire local copies. The owner’s members list remains available after notification dismissal, without automatically saving meetup details. For recovery, the server also retains each participant’s private finalized screen, including the agreed plan, recognition information, permitted contact details and request snapshots. Each participant can retrieve only their own view through their session. Raw session tokens are not stored in these records. Private recovery and saved-copy authorization end at the locked meeting time plus 60 minutes, or sooner on explicit withdrawal, Unmatch or confirmed unsaved dismissal.

Waiting for a match: the posted-request owner sees the number of active waiting requests. A waiter receives their own waiting status and whether the owner explicitly closed without Wingfam, opened Wingfam, cancelled, or became unavailable. Waiting does not expose the existing pair’s recognition details or phone exchange.

Service operation: the operator and infrastructure providers can process stored information for hosting, support, security and service administration. Match details are not end-to-end encrypted. We may disclose information when legally required, to address unlawful conduct or protect people and the service, consistent with applicable law. We do not sell or rent personal information, including as a business model for the service.

Immediate photo removal by visitors

Any visitor, including someone without an account, live request or uploaded picture, can open a photo’s three-dot menu and select the red X beside “This photo violates someone’s rights, copyright, or laws.” After a successful removal, the photo is detached from the live request and its original and thumbnails stop being served. The request itself stays live. The action is immediate and does not wait for the uploader’s approval or an operator review.

We chose this approach to let people act quickly when an image may infringe privacy, consent, copyright or other rights. Protecting someone from continued unwanted exposure takes priority over the inconvenience of losing a profile picture. This means a visitor can remove a photo mistakenly or abusively. Removal does not establish that a law or someone’s rights were actually violated.

The updated app removes visible copies when the removal reaches that page, normally through its next successful check-in or photo-status check. It also clears the uploader’s associated saved browser photo and photo references in saved match data. A closed, offline, suspended or outdated browser cannot be remotely erased: a browser that has recorded the photo’s association checks again when it returns and connects. Older browser copies may lack that association. Screenshots, downloads, device backups and copies outside Wingman remain outside our control.

We attempt deletion of the original and thumbnail files immediately; storage failures are retried by later cleanup while the live photo stays unavailable. A small removal record containing the photo identifier, associated request identifier when available, and removal time is retained without a fixed expiry so returning browsers can recognize the removal. It contains no image or reporter identity and is not subject to the 90-second live-request timeout. Infrastructure logs and backups have their separate retention described below.

This tool removes the selected uploaded photo and references to that same upload. It does not automatically recognize separately uploaded duplicates. For duplicate images, repeated uploads, other content or a formal rights request, use Report a concern.

Live expiry, server cleanup and backups

While your request is active, the page normally checks in about every 10 seconds. A successful renewal extends its live expiry by 90 seconds. Closing the page, losing connectivity or having the browser suspend it stops renewals when no further check-ins reach the server. A background tab can still check in, so simply switching tabs does not necessarily end a request.

• Requests and matches: Later matching, meetup-check, business-search or place-search activity schedules bounded background cleanup. Unmatched scheduled requests expire at their meeting time. Unfinished invitations and arrangements retain the 90-second check-in requirement and scheduled-time-plus-one-hour cutoff. Finalized connections instead use the locked meeting time plus 60 minutes, independent of missed check-ins or either original proposed time. Retained host rows can support private finalized details without keeping an offline Wingfam publicly discoverable. Live access checks enforce these limits before physical deletion. No later traffic, a backlog or a failed cleanup can leave expired storage in place longer.
• Finalized plans and wingfams: Finalization removes ordinary matched requests from discovery. The server keeps private final-screen recovery and the connection authorization until 60 minutes after the locked meeting time. Saving and dismissing can remove the ordinary request rows while preserving the other participant’s recovery and the saved radar card. Confirmed dismissal without saving, withdrawal or Unmatch ends the connection sooner and clears server recovery payloads and save flags. An owner-bound Wingfam permission can preserve request and sharing details through the same meeting deadline; explicit owner dismissal closes that permission. Permissions and expired recovery records are physically removed by later cleanup.
• Saved-details notices: A connection stores an immutable meeting-time-plus-60-minute expiry, separate from each participant’s 90-second presence timestamp. Check-ins refresh presence but never extend the connection deadline. Ended-state markers remain through the original deadline so returning participants can receive revocation; they can miss the notice if they return later. Explicitly closing the auto-allow dialog withdraws its host and retained connections. Closing or locking the browser sends no withdrawal; public availability still requires check-ins.
• Waiting status: one waiting record per live requesting session records its target and outcome. Normal polls renew it for 90 seconds while its request stays live. It is removed when that request is deleted or by later bounded cleanup after expiry. The target’s cleanup does not erase an outcome before a still-live waiter can retrieve it. Offline or suspended users may miss a notice before their request expires.
• Uploaded photos: the photo endpoint stops serving a photo once it has no active associated request. Removal of stored originals and thumbnails happens in background cleanup batches triggered by subsequent matching, meetup-check, business-search or place-search API activity. A valid wingfam reopening permission can temporarily preserve the photo. Cleanup failures are retried on later activity, so storage deletion has no guaranteed 90-second deadline.
• Abuse prevention and map results: IP-derived rate-limit records generally have a two-minute expiry and are removed during later cleanup. Address and business-name search results are cached in D1 for 24 hours, including valid empty results, using the provider, normalized partial search text and two-decimal proximity hint, or exact reverse-lookup coordinates. The search text and rounded hint are included in the cache key. These shared rows contain result addresses, coordinates and expiry without visitor/session identifiers; up to 500 entries also remain in server memory. Expired rows stop being reused and are deleted by shared background cleanup; provider errors are not cached. Selected places use the separate coordinate suitability cache. Shared raw business-query results are retained for 24 hours, including valid empty results; those results concern searched places and areas rather than your full profile.

Hosting backups and logs have separate retention. The site uses Cloudflare D1 database storage. Cloudflare documents automatic database recovery history of up to 7 days on Workers Free or 24 hours on Workers Paid. Deleted database information may remain recoverable during the applicable window. See Cloudflare’s D1 Time Travel and backups policy (opens in a new tab) for its current documentation. These are provider plan limits, not a claim about which plan Wingman’s hosting platform uses.

The 90-second timeout does not apply to provider logs, backup history, browser storage, copies already received by someone else, or emails and reports sent to the operator. Hosting providers apply their own retention settings and legal obligations. Support and report correspondence may be kept as needed to handle the matter and meet legal obligations; it is not subject to a fixed 90-second deletion schedule. We do not promise that every copy is erased when you leave.

Live visitor counts

The worldwide posted-request count also offers a public breakdown by the approximate city, state/province and country of each request’s selected meeting spot, including groups containing one request. These labels describe the posted plan, not the requester’s current physical location. City resolution sends meeting-spot coordinates rounded to three decimal places to Photon and reuses the geography and public city-point caches described below, with the same expiry periods. This adds no requester-location history or new identifying fields. Only aggregate counts, city labels and approximate city-point distances are added to the breakdown. Requests with unresolved cities remain counted as pending or unavailable; expired requests and satisfied ordinary requests are excluded, while open Wingfams remain included.

To count browsers viewing available wingmen, the visible homepage sends a random, short-lived visitor identifier with its regular activity checks. Ordinary tabs share this identifier through local storage. The server stores its hash, a 90-second expiry, available device coordinates or approximate IP-based coordinates, approximate city, state/province and country labels derived from device coordinates when available, with Cloudflare’s incoming-connection geography as a fallback, and a temporary request-session hash used to consolidate duplicate visitor markers from the same session and exclude people with an open request from the nearby viewer count. Visitor coordinates and identifiers are not included in public responses. Public aggregate counts include a breakdown by city, state/province and country, including groups with one viewer. The breakdown can be sorted by count or by approximate straight-line distance from your supplied device or IP-fallback coordinates to a public city map point. Distances are not calculated to other visitors’ positions. To obtain public city points, our server sends only city name, state/province and country to Photon. These separate city-point cache rows store the geographic name key, public city coordinates and expiry, without visitor identifiers or individual visitor coordinates. Successful city points are reused for 24 hours and unsuccessful lookups for 30 seconds; expired rows are removed during later uncached city-point lookups. Distances are computed for the current response, not stored as a visitor history. Your browser locale formats distances locally in miles or kilometres. The popover hides state/province and country labels when they match the viewing browser’s approximate region and country, but the grouped response retains those labels. To resolve device coordinates into geographic labels, our server sends coordinates rounded to three decimal places to Photon, our existing address-lookup provider. Subdivision and neighbourhood labels are excluded from city selection. When no usable city/town label is returned, an additional query to the same Photon provider searches for a nearby city-level place within 20 km, matching the known country and state/province. This is an approximate community label and may differ from your postal city or legal municipality. Rounded-coordinate city lookup results are also cached in the database for reuse across visitors and server restarts. Successful results are reused for 24 hours; unsuccessful lookups are reused for 30 seconds before retrying. These lookup records contain the coordinate grid cell and city/region/country labels, without visitor identifiers, session identifiers or IP addresses. Expired lookup rows are removed during later cache lookup activity, and provider backup limitations still apply. Up to 500 results may additionally be reused in server memory for five minutes. This avoids a lookup for every heartbeat or small GPS change. Without usable device labels, Cloudflare’s IP-based geography supplies a fallback; if hosting labels are missing, available approximate IP coordinates can also be reverse-geocoded. IP-based geography may differ from physical location, especially on mobile networks or VPNs. This feature does not add raw IP addresses to visitor records. Small-area counts may still reveal that someone is present, especially where few people are nearby. This is not a verified count of individual people: separate devices, private windows, blocked storage, automated clients or simultaneous new tabs can affect accuracy. Viewers include people who have posted a request.

After 90 seconds without renewal, a visitor no longer counts. The server measures that window from receipt of the check-in, before location lookups, and ignores expired or superseded observations. Changing from IP fallback to device location updates the same session’s presence rather than adding a viewer. Expired server entries are removed on subsequent matching-API activity; the city, region and country labels follow that same lifecycle. Physical deletion and provider backups have the limitations described above. The browser marker may remain while the site is closed, but an expired marker is replaced on a later visible visit. It is not used for a cross-site profile or advertising.

Last browser activity: while the Wingman page is visible, it observes pointer movement and presses, mouse-wheel or touch scrolling, taps and keyboard interaction. Scroll events count only near a trusted input event, so automatic page positioning alone does not mark someone active. This activity feature keeps only the latest interaction time in page memory; it does not collect key values, typed content, pointer coordinates, scroll positions, event histories or activity in other tabs, sites or apps. When this page has a live request, or posts or reopens one, the next existing heartbeat or request action sends elapsed milliseconds since that interaction to Wingman. No separate request is sent for each movement. The server converts that reported age into an approximate timestamp and stores the newest value on the request; an older report from another tab does not replace a newer value. The public request, quick info and wingmatch views show elapsed time since this activity separately from request age and the last check-in. This is browser-reported activity and can be delayed, blocked or inaccurate; it is not proof that a person is watching or will respond. Browsing without posting does not store an activity timestamp on a visitor record. The timestamp follows the request’s existing expiry and deletion rules; already received snapshots or the existing short-lived finalized-match recovery copy can retain it under the rules described above. It is not added to saved previous-request history, a separate activity log, an advertising profile or a cross-site identifier. Reloading clears the page’s interaction observation; the server can retain the previously reported request timestamp until the request is deleted.

To prevent duplicate map lookups, D1 also stores short-lived lookup leases containing a lookup key, random per-attempt owner token and 20-second expiry. Text keys include normalized searches; suitability keys contain exact coordinates; business keys identify the provider and hash either the Geoapify search center, radius and categories or the separate Overpass current-business query. These records are not linked to visitor/session identifiers. They are released when work ends or become eligible for replacement after expiry. Abandoned expired rows are removed by shared background cleanup, not by a separate timer. Normalized Geoapify business lists and separate raw Overpass current-business responses, including valid empty results, are cached in D1 for 24 hours, with up to 100 entries in server memory for each provider path. Provider failures are not saved as empty business lists. Expired results are removed by shared background cleanup. These lifetimes do not override hosting backups.

The page also keeps up to 100 successful and 100 rejected meeting-point checks in memory, keyed by exact coordinates and carrying the server-provided expiry. Rejection entries include the reason, so an unsuitable location can remain crossed out and unavailable in the text-search results or nearby-business picker until expiry. Reuse stops at that original expiry, at most 24 hours after the source check; reading a result does not extend it. These approvals and rejections are cleared on reload and are not written to localStorage or sessionStorage. Network failures, service errors and timeouts are not stored as suitability decisions. Confirmed rejections are never treated as approvals. The suitability diagnostics also display check times, result sources, cache expiry and reuse explanations in page memory. This does not create a persistent browser suitability cache. The diagnostics Log displays failures from this page’s provider requests and lookup coordination events such as cache hits and waits, as well as IP-fallback attempts, cache provenance, result and expiry times, and changes between IP and device location. IP-fallback events do not include the IP address or coordinates. Entries include timestamp, API purpose, provider hostname, HTTP status and up to 4,096 characters of provider output. That output can echo a searched location. Coordination events include only the lookup category and event, not the query, coordinates or owner token. The latest 100 entries are kept only in page memory and clear on reload; they are not written to browser storage or a shared diagnostic database. Provider labels omit query strings. Other visitors cannot retrieve this page’s log through the app.

Your appearance choice (Light, Dark or Auto) is stored locally under wingman-theme and shared between same-site tabs. Auto is the default and follows your device appearance. This preference is not sent to Wingman’s server.

What stays in this browser

In an installed app, informational pages can open in an overlay while the main Wingman page and its existing check-ins remain active underneath. A same-origin frame message closes the overlay; it contains only a close command and is not saved or sent to the server. Interactions in the embedded document are not added to the main request’s browser-activity timestamp. When you return from a separately opened informational page, a same-origin browser channel can check whether another main Wingman tab is open, ask it to focus and close the informational tab if the browser allows it. These messages contain only temporary correlation and page-instance identifiers, not your request, location or profile. They stay in browser memory and are not sent to Wingman’s server or saved in browser storage. If this coordination or closing is unavailable, the link navigates to Wingman in the current window.

The browser uses a short-lived posting marker and a change signal to coordinate Wingman tabs. These contain a temporary random marker and timing information, not your request text or photo. They do not create a persistent browser identity. The browser also records dismissed wingmatch identifiers for up to 24 hours so closing a completed match persists across reloads. Expired dismissal entries are ignored and replaced on later dismissals. A saved photo identifier lets this browser check whether its associated profile photo was removed.

Wingman uses browser storage for convenience and recovery. This can remain on your device after you close the site, including on a shared device. A later visit can use these values again.

Cached form fields

Display name, Age, Your gender and Looking for are saved in one local-storage record for 30 days after each successful request submission or update. The plan and photo are not included. Reading, typing and reloading do not renew this deadline. Expired entries are rejected and cleared on startup, focus or a minute-by-minute check while open; closed browsers may retain expired bytes until Wingman runs again. Clear cached form data deletes this record without clearing the visible form, photo, live request or Previous requests history. The next successful submission saves the four fields again. Reset form clears the editable form and photo but leaves this separate cache available for later visits. Browser restrictions can prevent saving or removal.

Draft and profile photo

Saved place/timing drafts include search radius, selected place, scheduled-versus-relative mode, relative arrival/travel preferences and an associated request ID, but exclude plan text, profile fields and absolute meetup clock time/date. Obsolete profile and plan values in older drafts are stripped when read. Drafts expire 12 hours after their last changed save; reopening an unchanged draft does not extend that deadline. Expired drafts and older drafts without a verifiable expiry are removed when the app next reads draft storage. A closed browser cannot run a deletion timer, and an already open form is not forcibly cleared. The processed profile photo is stored separately until you reset or remove it, overwrite it, or clear this site’s data. Active request displays also show time since creation and the last server-observed check-in derived from the existing expiry timestamp; these displays do not create a new tracking record. Typing a draft does not itself post a public request, but location and search features still contact the services described here.

Previous requests

Up to five previous requests, including saved plan details and comments, are kept in this browser for reuse. Each entry expires 30 days after it is first saved, or 30 days after you select it for reuse. Reopening the page or reading history does not extend the deadline. Older entries use their original save date to establish expiry. Expired entries are removed when history is read, when the page regains focus, or during a periodic check while open; closed browsers can retain the underlying expired data until Wingman runs again. Entries can also be replaced by newer ones, cleared with the history control, or removed through browser settings.

Explicitly saved wingmatches

Either participant can save received name, place, fixed meeting time, recognition and exchanged phone details in up to 30 local entries. The other participant receives a save notice. After saving and dismissing, a Previous wingmatch card reopens the copy following a successful server check. Dismiss inside the saved view preserves it; Delete or the trash icon removes only this browser’s saved entry. All copies expire 60 minutes after the locked meeting time, regardless of check-ins. Withdrawal, Unmatch or confirmed dismissal of an unsaved final screen ends the connection sooner. Updated browsers remove affected details when they connect. Expired local values are physically cleared when the browser next runs; externally copied details cannot be recalled.

Ended connections

Confirmed Unmatch removes that connection’s saved entries and final view when each updated browser receives the server state. Offline, suspended or outdated browsers cannot be erased immediately. Up to 100 ended match identifiers and 24-hour deadlines are kept locally to prevent delayed responses or reloads from restoring details. These markers contain no meetup details and are pruned on later unmatches. The server keeps a host request ID and excluded partner-session hash to prevent re-entry into that specific Wingfam request; the exclusion is removed when that request is deleted. This does not block a new browser identity or hide publicly shared auto-allow details.

Final wingmatch recovery copy

The browser can retain the finalized plan, recognition details and exchanged phone for reload recovery until 60 minutes after the locked meeting time. Rewriting or reading it never extends that deadline. The app validates server state before displaying restored details, and the authenticated server can supply an undismissed final screen even when the local recovery copy is missing. Closing or locking the phone is not dismissal. Clearing cookies or using a different browser loses this ownership. Expired browser values are removed when Wingman next runs.

Saved map view

The main map’s displayed center coordinates and zoom level stay in local storage so the view can be restored when you reload or return. This is the area you were viewing, which may differ from your device location or meetup point. It remains until another map view replaces it or you clear this site’s browser data.

Preferences and location cache

Your sound and haptics preferences are saved separately in this browser until changed or cleared and synchronize between same-site tabs. They are not sent to Wingman’s server. An approximate IP-based location can be reused for up to an hour within the tab’s session storage. Expiry controls reuse; it does not guarantee immediate erasure from a closed tab.

Visitor presence

A random visitor identifier and 90-second reuse deadline are stored locally so ordinary tabs can share a count. Visible homepage activity renews it. An expired identifier is replaced on a later visit; a closed browser can retain the expired marker until then or until site data is cleared.

Session cookie and offline files

The HttpOnly first-party cookie can last up to 13 hours while a request is unfinished, allowing recovery if the other person finalizes before your browser returns. It does not extend unfinished availability. A finalized response retains the cookie through the latest retained meeting deadline, with a minimum 90 seconds; without a request or retained connection it returns to 90 seconds. Clearing it loses session ownership. The installed app caches public icons and an offline page, not private match API responses.

To remove these local copies, clear Wingman’s cookies and site data in your browser or installed web app. Reset form, remove photo and clear history controls address their respective saved items. Clearing browser data alone does not send a server deletion request and cannot remove a partner’s saved copy.

Service providers and external links

These services receive information needed for the feature you use. Their own policies govern their independent processing and retention. Requests made directly by your browser can reveal your IP address, browser information and, where the browser permits it, referring-page information.

• OpenAI’s Sites hosting platform and Cloudflare: delivery of the website, database, photo storage, network security and operational records. Read the OpenAI Privacy Policy (opens in a new tab) and Cloudflare Privacy Policy (opens in a new tab).
• ipapi.is: the browser contacts this service for an approximate IP-based area when device location is unavailable. It receives your IP address. ipapi.is Privacy Policy (opens in a new tab).
• Geoapify: Wingman’s server sends partial address/business search text and the rounded proximity hint described above to provide autocomplete suggestions. Nearby business discovery also sends the search center rounded to five decimal places, the selected radius and business categories to Geoapify Places. This is more precise than the two-decimal autocomplete hint and can describe a sensitive location. These lookups do not send your profile, photo, plan or session identifier. The API credential stays on the server. Geoapify Privacy Policy (opens in a new tab).
• Photon / komoot: Wingman’s server sends coordinates for reverse address labels and city resolution. Autocomplete text is sent to Geoapify instead.
• OpenStreetMap and Overpass: your browser requests map tiles from OpenStreetMap, revealing the area viewed. Wingman’s server sends nearby search areas to Overpass endpoints operated at overpass.private.coffee, overpass-api.de or VK Maps at maps.mail.ru to prepare a business and associated entrance for Use my location, and to classify meetup coordinates. The Nearby businesses dropdown uses Geoapify instead. The fallback receives the queried point or search area, not your name, photo or request text. VK Maps is an additional provider operated in Russia. Private.coffee policies (opens in a new tab). OpenStreetMap Foundation Privacy Policy (opens in a new tab).
• UNPKG: your browser downloads the Leaflet map library and its styles from this content-delivery service.
• Links you choose: opening directions or another external link sends you to that provider. A directions link includes the selected place; a phone link passes the selected number to your device’s calling app.

Data may be processed in the United States and other countries where these providers operate. A provider link explains that provider’s practices; it does not replace Wingman’s commitments in this policy.

Your choices, rights and security

You can browse without posting, omit an optional photo or phone number, choose what to enter in public fields, change browser location permission, update or leave your live request, and clear saved browser information. Withdrawing a request stops its live availability but cannot recall information someone has already received.

Depending on where you live and which laws apply, you may have rights to access, correct or delete personal information, restrict or object to processing, receive a portable copy, withdraw consent, or complain to a privacy authority. Email todd@hendricks.cc to exercise applicable rights or appeal a decision where that right applies. Provide only enough context to locate the information; do not email passwords or government identification. We may need proportionate verification before releasing or changing information. With no account and short-lived records, we may be unable to identify a past request or retrieve information already deleted. We will not discriminate against you for exercising applicable privacy rights.

We use HTTPS, session controls and limited live availability to help protect information. No website, device or transfer is perfectly secure. Do not post sensitive information you do not want others to retain. We will address security incidents and make legally required notifications under applicable law.

Adults only: Wingman is for people 18 and older. We do not knowingly permit children to use the service. Age is self-reported and not independently verified. Please report a minor’s information or an unsafe photo through Report a concern so we can address it.

Contact and policy updates

For privacy questions, requests or concerns, contact Todd Hendricks at todd@hendricks.cc, Illinois, USA.

We will update this page and its date when our practices change. Material changes will be called out on the site or through another notice appropriate to the change, with consent obtained where required. The Terms of Service explain the rules for using Wingman.