Security and data handling

Written for whoever has to approve this.

MFCommander runs on your Mac and talks directly to the servers, buckets, engines, and clusters you point it at. This page says how it connects, what it keeps on your machine, and what it sends us.

The binding documents are the End User License Agreement and the Privacy Policy. Where this page and those disagree, they win and this page is wrong.

Nothing is proxied through MFSoft.

Every connection is made by the application on your machine, to the endpoint you configured, over that protocol's own transport. MFSoft operates no relay, no gateway, and no cache in that path, and there is nothing for us to intercept because your traffic never reaches us.

Servers and storage

SMB and NFS use in-app clients, so no Finder mount is required and no system-wide credential is involved. S3, OneDrive, and Dropbox reach their API endpoints over HTTPS. SFTP verifies the host key on first connection and refuses a later mismatch, the way OpenSSH's accept-new does, against the same ~/.ssh/known_hosts your shell uses.

FTP is the exception and is exactly as unencrypted here as it is everywhere else. MFCommander speaks plain FTP with no TLS, so treat it as a protocol for a trusted network and use SFTP where the credentials matter.

Kubernetes

MFCommander does not embed a Kubernetes client. It runs the kubectl already installed on your Mac, and passes your kubeconfig and chosen context explicitly on every invocation. Exec credential plugins, including the EKS and GKE helpers, work because kubectl runs them, not because we reimplemented them. What the browser actually does.

Docker

The same arrangement: your installed docker command, your current context, and any host or TLS configuration it already has. MFCommander does not open the engine socket itself.

What actually runs in your cluster.

There is no MFCommander operator, agent, DaemonSet, webhook, or custom resource. Nothing is installed, and uninstalling MFCommander means deleting an application from your Mac. One thing does run, though, and it would be dishonest to leave it out of a page like this.

The exception, in full

Browsing the files on a persistent volume means reading them from inside the cluster. MFCommander prefers to do that through a pod you are already running that mounts the volume and has a usable shell. When there is no such pod, it creates its own: a single small container named mfcommander-pvc-browser-* and labelled app=mfcommander-pvc-browser, mounting that one volume at /mnt/pvc, read-only unless you are copying files in.

Every helper pod carries an activeDeadlineSeconds deadline, so Kubernetes terminates it on its own schedule no matter what happens on your Mac, including a force quit, a lost network, or a crash. MFCommander also deletes its helpers when the application quits and when you remove or change the connection in Settings. It does not delete them the moment you close a tab, because the connection is still registered and probably about to be used again, so the deadline is the mechanism to rely on and the one to set to taste.

The helper image is yours to change if busybox is not allowed in your registry policy.

Docker volumes work the same way and clean up differently. The helper container is started with --rm, so the engine removes it as soon as it exits, with no deadline to configure.

Your RBAC is the only authorization.

MFCommander has no permission model of its own and grants nothing your kubeconfig does not already grant. Every action is a kubectl invocation running as you, so the cluster decides, exactly as it would at a terminal. A read-only service account sees a read-only application without anything being configured here.

Read-only mode is on before you ask for it.

Both the Kubernetes and the Docker browser are read-only by default, on a fresh install, with nothing to configure. Until you turn the guard off in Settings, editing, deleting, scaling, restarting, applying YAML, starting or stopping containers, and writing files into a volume are all refused. Listing resources, describing them, reading logs, and collecting metrics still reach the cluster, because that is the part you wanted.

Where your secrets sit.

Passwords, private keys, and the OAuth tokens for cloud connectors are encrypted with AES-GCM into a single file, credentials.vault, in your Application Support folder, written with owner-only permissions. The key that decrypts it is one item in your login Keychain and is the only thing MFCommander keeps there.

What MFSoft receives, in full.

Three destinations, none of them carrying file contents, file names, paths, connection details, or credentials. The Privacy Policy is the complete description and this is a summary of it.

License validation

Your license ID and a SHA-256 fingerprint of the key, periodically. Losing network access does not disable the application you paid for.

Usage statistics

On by default, with a permanent off switch in Settings under Privacy. An install identifier, the application version, your macOS major version and architecture, your edition, and bucketed counts of which features were used.

Update checks

The version you are running and your platform, to a static appcast feed hosted on GitHub Pages. No license key, no entitlement, no identifier. Updates are signed, and you can turn the check off in Settings.

What you are actually installing.

Signed and notarized

Every published build is signed with an Apple Developer ID, built with the hardened runtime, and notarized by Apple. The notarization ticket is stapled to both the application and the disk image, so Gatekeeper can verify it without network access.

Not sandboxed

Direct SMB and NFS clients, a kubectl subprocess, and arbitrary filesystem access do not fit the App Store sandbox, which is why MFCommander is not in the App Store. It is a normal signed application under the usual macOS permission prompts for files, folders, and the local network.

One entitlement

The shipped build requests exactly one: com.apple.security.cs.disable-library-validation, required so the LGPL components can be relinked as their licenses oblige us to permit. The instructions for doing that are on the notices page.

No third-party code loads in

There is no plugin SDK and no extension mechanism, so nothing outside the signed bundle is ever loaded. Every connector and viewer is compiled in and covered by the same signature. It is a real limitation on extensibility and a real reduction in supply-chain surface.

Something here unanswered?

Email [email protected] if your review needs an answer this page does not give.

Download