Secure connection defaults
The current Windows implementation makes explicit FTPS the default for new server profiles. FTPS is limited to TLS 1.2 and TLS 1.3 and uses standard Windows/.NET certificate-chain and hostname validation. There is no “accept any certificate” switch.
- Plain FTP requires an explicit warning before a connection is opened.
- Passive data connections are used, and PASV host redirection is not blindly trusted.
- FTP command arguments reject CR, LF and NUL characters to reduce command-injection risk.
- Connection, command and transfer timeouts are enforced.
Safer file-transfer boundaries
Transfers are designed to avoid treating incomplete data as complete. Downloads use temporary .ghostftp.part files and are promoted only after a successful transfer; uploads use a temporary remote name before the final rename.
- Deleting the FTP root directory is blocked.
- Remote filenames are sanitised before being written to Windows paths.
- Local destination paths are boundary-checked to prevent escaping the selected directory.
- Recursive local operations protect against NTFS reparse-point and junction expansion.
Local data and credential protection
Ghost FTP keeps settings, UI preferences and saved profiles local. Saving passwords is optional and, on Windows, stored passwords are protected with DPAPI rather than plain text.
- Settings and profile files are size-bounded before deserialisation.
- Profile counts are bounded.
- Settings and profiles are written through temporary files and use atomic replacement with backup recovery where supported.
- Invalid or oversized local profile data is not silently accepted as valid input.
No telemetry by design
The public project documentation states that the application contains no telemetry, analytics SDK, advertising SDK, tracking SDK, crash-report upload or automatic update checker.
- Normal application network traffic occurs when you explicitly connect to an FTP/FTPS server.
- Opening the Ghost FTP website from the application is an explicit user action.
- Demo mode does not open a network connection.
- Saved profiles and UI preferences remain local.
Installer and update boundary
The per-user Windows installer validates its embedded payload before replacement and is designed to fail visibly rather than claim success when the installed executable cannot actually be replaced.
- Installer payload checks include existence, minimum expected size and the Windows MZ executable signature.
- Updates use atomic File.Replace when replacing an existing installation.
- The installer does not request administrative privileges by default.
- Optional user-data removal is verified when requested.
Reporting security issues
Report security issues privately to hello@ghostftp.com. Include only the information necessary to understand and reproduce the problem, and never send passwords, private keys or reusable credentials.
Scope note: this page describes the security and privacy properties currently documented in the public Windows source. Planned protocols and future platforms may have different implementation details and will be documented when they are ready.