Legal

Privacy Policy

FlyGD Wingman · Last updated 4 September 2026

1. Overview

FlyGD Wingman (“Wingman”, “the application”) is a free, open-source EVE Online multiboxing toolkit for wormhole space that also uploads your fight footage to YouTube. It runs on your own Windows PC. It mirrors running EVE clients in preview windows, provides wormhole mapping and rolling keybinds, watches gamelogs for combat alerts, helps with profiles, skills and fittings preparation, and reviews and uploads the recordings you select.

This policy describes what the application does with information on your computer and with the accounts you connect to it. It is written to describe the application as it actually behaves; where the behaviour has a sharp edge, this policy says so rather than smoothing it over.

The most important thing to understand is structural: there is no FlyGD backend. The project does not operate a server, a database, an API, or a hosted account system for the application. Wingman talks directly to the services you connect it to: Google, CCP, GitHub, and, if you set one up, your own Discord webhook. The maintainers do not receive your recordings, your credentials, your YouTube data, your EVE data, your combat logs, or any usage events, because there is no system in place that could receive them.

2. This website and Cloudflare

This website, wingman.zoolanders.vip, is a set of static pages. It sets no cookies, runs no client-side analytics, embeds no third-party scripts or fonts, and ships no runtime JavaScript. Nothing on these pages tracks you across sites.

The site is hosted on Cloudflare. As the hosting provider, Cloudflare processes ordinary web request information, including your IP address, request headers and timing, in order to route, serve and protect the site. That processing is a normal part of hosting and is governed by Cloudflare's own terms and privacy documentation, not by anything this site adds to your browser.

Two details are worth stating precisely, because they are easy to overstate in either direction:

Cloudflare documents that a request matching a static asset in this project is served from its asset storage without invoking Worker code. There is no server-side code of ours in the path of a normal page view.
The project's configuration enables Workers observability (observability.enabled). That setting governs whether Cloudflare persists logs of Worker invocations for the account's own operational review. It is infrastructure logging, and it does not add analytics, cookies or any script to your browser.

In other words: the pages themselves carry no tracking, while the provider that serves them still sees the requests, as any host would.

3. Local files and application access

On your computer, the application reads and writes what its features need:

Your OBS recording folder. Wingman lists video files in the folder you configure, or the one it reads from your OBS Studio configuration, and records each file's path, size and modification time so it can tell new recordings from ones it has already seen.
Your OBS Studio configuration files, read to discover where OBS saves recordings so you do not have to tell it.
The video files you select, read when you play, rename, stitch or upload them. Wingman can also rename a selected recording on disk, and can permanently delete selected recordings when you confirm a delete; deletion removes the files outright rather than sending them to the Recycle Bin.
Your EVE Online Gamelogs folder, read for combat alerts, for the fleet combat bar, and for the combat-log posting described in section 6. Your gamelog files are only ever read, never modified, moved or deleted.
Your EVE Online settings files, when you use Profiles to copy a character's or account's settings onto others, to take a backup first, or to restore one.
Running EVE client windows, which Wingman mirrors into preview windows, activates when you ask it to, and sends your configured bookmark keystrokes to. Wingman responds to your explicit input; it does not automate gameplay.
Its own data folder, described in section 8.

Wingman does not scan your disk generally, does not read your documents, and does not index anything outside the folders named above.

4. Google and YouTube

FlyGD Wingman uses YouTube API Services to upload videos on your behalf. By using the upload feature you also agree to the YouTube Terms of Service, and your data is additionally handled in accordance with the Google Privacy Policy.

The single scope

FlyGD Wingman requests exactly one OAuth scope:

https://www.googleapis.com/auth/youtube.upload

This is the narrowest scope Google offers that permits uploading a video, and it is the only permission the application asks for. Using it, Wingman calls a single YouTube Data API v3 method, videos.insert, and calls it only when you press an upload button. The application is verified by Google, so its consent screen is Google's ordinary one.

Wingman makes no request that reads your YouTube account data. It does not retrieve your subscriber counts, existing videos, playlists, subscriptions, watch history, comments or analytics, and it does not request your name, email address or profile picture, because it does not hold a scope that would permit it to.

Sign-in uses Google's standard installed-application flow. Your browser opens Google's own consent screen, you authenticate with Google directly, and the response returns to a temporary listener on your own machine. The application never sees, asks for, or handles your Google password. The OAuth client the application identifies itself with is compiled into the released Windows build, which is the ordinary way desktop applications ship. One practical consequence is that everyone using the application shares the project's YouTube API quota, so heavy use by others can exhaust it for a time.

What each upload sends

With each upload, the application sends the video file you selected plus the title you typed (or “Untitled” if you left it blank, with a counter such as My title (2/3) appended when several files go up separately), the description you typed, the YouTube category from your settings, and the privacy status from your settings: private, unlisted or public. The application ships defaulting to unlisted. No tags, thumbnails, location data or playlist assignments are sent, and nothing is uploaded unless you selected it and started the upload.

What Google data stays on your PC

token.json: Your Google OAuth access and refresh tokens, stored as plain JSON in the application data folder, together with the application's client identifiers.
settings.json: The channel ID and channel title of the last successful upload, learned from the videos.insert response so the application can show you where uploads land and point out when the destination changes.
links.json: A local history mapping each uploaded recording's path (with its size and modification time) to the YouTube URL the upload produced, so the Link column still answers “did I already upload this fight?” after a restart.

Nothing prunes links.json automatically. Entries stay until you delete the file or the whole data folder yourself. That is deliberate: the link is the only record the application keeps of an upload, and it cannot be recomputed.

Limited Use disclosure

FlyGD Wingman's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In practice, information received from Google APIs never leaves your computer other than in the request that produced it: it is not transferred to the maintainers, not transferred to any third party, not used for advertising, not used to build a profile of you, not used to train machine-learning models, and not read by any human.

Three separate actions

Revoking, deleting locally, and deleting on YouTube are three different things, and doing one does not do the others:

Revoking the application's Google access (section 11) invalidates the credentials held on your PC. It does not delete token.json, the stored channel ID and title, or the links.json history from your computer, and it does not remove any video from YouTube.
Deleting the local files (section 12) removes the stored credentials, channel metadata and upload-link history from your PC. It does not revoke the application's access to your Google Account, and it does not delete uploaded videos.
Deleting a video on YouTube is done in YouTube Studio, under your own account. It affects neither the local files nor the grant of access.

5. EVE SSO and ESI

The EVE features are independent of Google: no Google or YouTube data is used by them, and no EVE data is sent to Google. Authorizing a character is optional, and only the Skills and Fittings features need it.

Wingman asks CCP for exactly four ESI scopes:

esi-skills.read_skills.v1 esi-skills.read_skillqueue.v1 esi-fittings.read_fittings.v1 esi-fittings.write_fittings.v1

Skills asks only for the two read scopes; Fittings asks only for the two fitting scopes. Authorizing a character for everything the application offers grants the union of the four.

Sign-in uses EVE SSO as a public client with PKCE. Your browser opens CCP's own login page, and the authorization response returns to a temporary listener on the loopback address http://127.0.0.1:51779/callback/ on your own machine. There is no EVE client secret in the application: the flow's protection comes from PKCE and from your own consent at CCP, not from a secret embedded in a desktop build. Wingman never sees or handles your EVE account password.

Through ESI, Wingman reads the trained skills and current training queue of characters you authorized, reads their fittings, and resolves character and type names for display. The only write is an explicit, additive fitting copy: when you select fittings and target characters and confirm the copy, Wingman creates those fits on the target characters. It does not modify or delete fits that are already there, and it makes no other write to your EVE account.

Locally, the application stores these categories of EVE data in its own data folder:

Character identity and authorization metadata: character ID, character name, the owner hash CCP returns, and the scopes each character granted.
EVE refresh credentials, protected with Windows DPAPI before they are written (see section 8).
Skill and queue state: skill snapshots, the training queue, character attributes, cached skill name lookups, and per-request cache validators.
Plans and groups: your skill plan files, plan selections, and the character groups you organise readiness by.
Fittings and collections: the curated fitting library, per-character fitting snapshots, collection membership, names and descriptions, and the record of which fits were copied where.
Profile, preview, bookmark and EVE-settings state: your preview and keybind configuration, formation and profile choices, and the EVE settings backups the application takes before a copy or restore.

6. Discord and combat logs

This feature is entirely separate from Google and YouTube. No Google user data, no YouTube data and no video file is ever sent to Discord. It is off until you configure it: in Settings you may paste a Discord webhook URL you created in your own server.

There are two ways combat logs get posted:

After a successful upload. If a webhook is configured and you confirmed the upload with combat logs included, Wingman posts the logs matching that footage once the video upload has succeeded.
Post the last hour. A separate, explicit button that posts the logs from the hour ending at the click. No video and no Google account are involved.

A post is one HTTPS request to your webhook containing a ZIP archive of the matching EVE combat logs and a small manifest, plus a short summary message stating the time window covered, the number of log files, the EVE character names read from those logs, and how many older files were omitted if the cap applied. Log selection widens the window by five minutes at each end and keeps at most the 64 most recent matching files.

The webhook URL is stored in plain text in the application's settings file. A Discord webhook URL is a bearer credential: anyone who holds it can post to that channel, it does not expire, and the only way to revoke it is to delete the webhook in Discord. The application accepts only https webhook addresses on Discord's own domains, refuses to follow redirects so an archive cannot be diverted elsewhere, and strips the URL out of its own log file. The URL remains visible in the Settings field you pasted it into, so treat that screen as sensitive when sharing a screenshot.

7. GitHub and updates

Wingman contacts GitHub in two circumstances:

One automatic release check per startup. When the application window is ready, it requests the latest Wingman release metadata from GitHub's API to tell you whether a newer version exists. It is a plain read of public release data: no account information, no identifiers of yours, and nothing about your recordings or characters is sent. The request identifies itself with the application name and version, and GitHub sees it as it would any web request, including your IP address.
Downloads and checks you start. Checking again from the update screen, downloading the Wingman installer, and checking for or installing the optional FightRecorder OBS plugin each contact GitHub only when you ask for them.

Separately, during installation, if the Microsoft Edge WebView2 runtime is absent, the installer runs Microsoft's bundled bootstrapper, which downloads the runtime from Microsoft. That happens at install time only, and only when the runtime is missing.

8. Local storage and credential protection

Everything Wingman stores is stored on your own PC, in the application's per-user data folder:

%LOCALAPPDATA%\FlyGD Wingman\

Earlier releases used %LOCALAPPDATA%\OBSYouTubeUploader\. Migration is automatic and silent: at startup, if the old folder exists and the new one does not, Wingman renames it. There is no prompt and no choice to decline. If the rename fails with an operating-system error, for example because a file is locked, Wingman keeps using the legacy folder for that session and retries the migration at the next launch. That is why the clean-slate instructions in section 12 cover both locations.

Rather than list every file, here is what lives there by category:

Settings: settings.json: recording folder, YouTube privacy and category, notification style, Gamelogs folder, last upload channel ID and title, your Discord webhook URL if you set one, and the preview, bookmark, alert and EVE tool sections.
Google credentials: token.json: access and refresh tokens as plain JSON.
Recording records: seen.json (which recordings were already announced), durations.json (a cache of probed lengths) and links.json (the upload-link history).
EVE authorization: eve_authority.json: character identity, granted scopes, and DPAPI-protected refresh credentials.
EVE feature state: Skills, queue and group state; fittings, collections and copy records; cached name lookups; your skill plan files; and EVE settings backups taken before a profile copy or restore.
Bookmark engine files: The generated configuration, status and process files the bookmark engine reads and writes.
Logs and temporary files: A rotating diagnostic log, and working files such as stitched videos awaiting upload and combat-log archives awaiting posting.

Credential protection differs by credential, and the difference matters:

EVE refresh credentials are protected with Windows DPAPI before being written, using the Windows data protection API scoped to your Windows user account. A copy of the file taken to another machine or another user account cannot be unwrapped.
Your Google tokens and your Discord webhook URL are stored as plain JSON that the application does not encrypt. They are ordinary files in your Windows user profile, protected by your operating system's file permissions and by whatever disk encryption you have enabled yourself. Treat them as you would treat saved passwords: anyone who can read your user profile, or who obtains a copy of it, can use them.

The diagnostic log can contain local file paths, which typically include your Windows username, along with the names of your recordings, log files and characters. Any Discord webhook URL is actively stripped from it by a redaction filter attached to the log handler, so even third-party libraries cannot write it through. Google and EVE tokens are not written to it. The log is written for your own troubleshooting and is never uploaded anywhere.

9. Network destinations and sharing

The application connects only to the services its features need, and only in the circumstances described above:

Google: Sign-in, token refresh, and the uploads you start. Video data travels directly from your PC to Google over HTTPS.
CCP: EVE SSO authorization at CCP's login service, ESI reads for skills, queues, fittings and names, and explicit additive fitting writes.
Discord: Posts to the webhook you configured, and nothing else.
GitHub: One release check per startup, plus the checks and downloads you start, including the optional FightRecorder plugin.
Microsoft: The WebView2 runtime download during installation, only when that runtime is absent.
FlyGD: Nothing. There is no FlyGD backend to receive credentials, videos, EVE data or usage events.

The application contains no usage analytics, no crash or error reporting, no advertising identifiers, and no licence or activation check. The update check described in section 7 is a read of public release metadata, not usage measurement. The combat alerts and the fleet combat bar read your EVE gamelogs continuously while they are enabled, but that processing happens entirely on your PC; nothing from it is transmitted anywhere unless you post combat logs to your own Discord webhook.

The maintainers do not receive your data and therefore do not share, sell, rent, license or disclose it. The only parties that receive anything are the ones you chose to involve, and what you send them is thereafter governed by their own policies: Google Privacy Policy and Discord Privacy Policy, together with CCP's and GitHub's own published policies. Cloudflare's processing applies to this website, as described in section 2, not to the application.

10. Retention

Because the project holds none of your data, there is nothing for the project to retain and no retention schedule to operate.

On your own machine, data persists until you remove it, in the folder described in section 8, or in the legacy folder if an automatic migration was deferred by an operating-system error. Settings, credentials, EVE state, skill plans and the links.json upload history persist indefinitely; nothing prunes the link history. Diagnostic logs rotate automatically, keeping a small, bounded amount of recent history. EVE settings backups accumulate until pruned or removed. Temporary stitched videos are deleted once used, and strays are cleared at startup. Combat-log archives are deleted after a successful post and kept only when a post failed, so that you can send them manually.

Uninstalling the application deliberately leaves the data folder in place, so uninstalling and reinstalling does not lose your settings. Section 12 describes how to remove it yourself.

Videos you upload to YouTube are stored by Google under your own account, subject to your control and to Google's retention practices. Fittings copied to your EVE characters live on CCP's servers and are managed in game.

11. Revoking connected accounts

Google and EVE are revoked separately, at the provider, and neither revocation deletes anything from your PC.

Google

Open your Google Account's third-party access settings at myaccount.google.com/permissions.
Find FlyGD Wingman in the list of apps with access to your account. If you granted access before the project was renamed, it may still appear under its original name, OBS YouTube Uploader.
Select it and choose Remove access.

Revoking immediately invalidates the tokens held on your PC; the next upload attempt fails with a sign-in error rather than silently continuing. It has no effect on videos you already uploaded, and it does not remove the token file, the stored channel ID and title, or the links.json history from your computer.

EVE Online

To withdraw a character's authorization at CCP, sign in to EVE Online's account or developer account management and remove FlyGD Wingman from the list of authorized third-party applications. CCP moves those pages from time to time, so use the third-party application access section of your EVE account rather than a bookmarked link.

Within Wingman, Settings then Characters lets you remove a character, which deletes that character's stored identity and DPAPI-protected credentials from your PC. Removing a character locally does not withdraw the grant at CCP, and withdrawing the grant at CCP does not remove the local record; do both if you want a clean break. Neither action alters fittings already copied to your characters.

12. Deleting local data

To remove your Google credentials only, delete token.json from the application data folder. Wingman asks you to sign in again the next time you upload. To remove only the record of which recordings were uploaded and to which URL, delete links.json; the Link column empties and the videos on YouTube are unaffected.

For a clean slate:

Exit Wingman, including from the tray icon, so nothing rewrites its files while you work.
Revoke Google and EVE access separately if you want to, as described in section 11. Deleting local files does not revoke either grant.
Delete %LOCALAPPDATA%\FlyGD Wingman\. Paste that path into File Explorer's address bar to open it.
If you are not sure which location is active, or migration failed, also delete %LOCALAPPDATA%\OBSYouTubeUploader\. Removing both locations is the safe instruction when the active one is unknown.
Understand what is not affected. Recordings stored outside those folders remain where they are, videos already uploaded remain on your YouTube channel, fittings already copied remain on your EVE characters, and archives already posted remain in your Discord channel.

Uninstalling the application does not perform any of these steps for you.

13. Security

We would rather describe the actual protections than imply stronger ones.

All network communication with Google, CCP, Discord, GitHub and Microsoft uses HTTPS.
Your Google and EVE passwords are never seen or handled by the application; authentication happens on the providers' own pages.
The Google scope is the narrowest one that can upload, so a compromised Google token permits uploading to your channel, not reading or deleting your existing content, and not access to anything else in your Google Account.
The EVE scopes cover skills, the skill queue and fittings only. The single write path creates fittings; it cannot remove them, and it reaches no other part of your EVE account.
EVE refresh credentials are wrapped with Windows DPAPI under your Windows user account before they are stored.
Google tokens and the Discord webhook URL are stored as plain JSON, so their security rests on your Windows account and on any full-disk encryption you have enabled. If your PC is shared or compromised, treat those credentials as exposed and revoke them as described in section 11.
The Discord webhook URL is redacted from the diagnostic log, and redirects are refused when posting to it.
The EVE loopback listener accepts the authorization response only on 127.0.0.1, and the authorization is bound to the PKCE verifier generated for that attempt.
Released builds are not code-signed, which is why Windows may show a “Windows protected your PC” warning on first run. Downloading only from the project's official GitHub releases page is the way to be sure of what you are installing.

No software is perfectly secure. If you believe you have found a security problem, please contact us as described in section 15 rather than filing a public issue.

14. Changes

This policy may be updated as the application changes, for example if a feature is added that touches data in a new way. When it is, the “last updated” date at the top of this page will change, and the current version will always be published here at wingman.zoolanders.vip/privacy. Material changes affecting how Google user data is handled will also be noted in the release notes for the version that introduces them.

15. Contact

For privacy questions, Google Account or EVE authorization questions, data deletion requests, and security reports, email technical@zoolanders.vip. Please use that address rather than a public issue for anything sensitive.

For public bug reports and feature requests, use the project's issue tracker at github.com/elboaf/FlyGD-Wingman/issues. It is a volunteer project; issues are read, though no response time is guaranteed.

← Back to the FlyGD Wingman homepage