What Mountit protects, what it contacts, and what we do not know
An app that holds the keys to your storage owes you more than the word
“secure”. This page is the threat model, the complete list of hosts the
app can connect to, a no-telemetry claim written so you can prove it
wrong, and — because a security page that admits nothing is not a
security page — the gaps in our own audit.
Audited against the app source on 1 September 2026.
Static analysis: source read, packets not captured. That limit is on the list below.
Threat model
What stands between a given attack and your data, and where that control
stops. The second column is the one worth reading.
Someone reads your traffic between the Mac and the server
Each protocol uses the transport security it has: TLS for S3, WebDAV and the provider APIs, the SSH transport for SFTP, and packet signing for SMB — the SMB client is a pure-Rust implementation, live-tested against a Samba server configured to make signing mandatory. Every preset endpoint the app ships carries the scheme its protocol secures under: https:// for all 35 S3 and WebDAV presets, sftp:// for the five NAS SFTP presets, smb:// for the seven SMB ones. Those counts are read off the app’s own compiled table when this page is built, and the build fails if a preset’s scheme and its protocol ever disagree.
Where it stops Two of the services have no transport security of their own, and this page will not pretend otherwise. HTTP is a read-only browse of whatever a web server publishes, in the clear if the server is; FTP is encrypted only when you turn FTPS on — transfer mode, port and TLS are all yours to set. Point a connection at a plaintext endpoint and the traffic is plaintext.
Someone impersonates your SFTP server
The host key is shown on first connect, as a fingerprint and as randomart, and pinned once you accept it. A key that changes afterwards stops the connection rather than warning and continuing. Your existing known_hosts files are read as well — including @revoked and @cert-authority markers — so a key you have already rejected elsewhere is not offered to you as new.
Where it stops Trust on first use is still trust on first use. If the very first connection is intercepted, pinning pins the attacker. Compare the fingerprint against the server the first time; the page shows you exactly what to compare.
Someone with your unlocked Mac reads your credentials
Connections and credentials live in one AES-GCM-sealed record whose key is a Keychain item marked device-only and “after first unlock”. Server names and usernames are inside the sealed record too, not only the passwords. An optional biometric gate can be switched on.
Where it stops The gate is off by default, and once the app has unlocked the record it serves it from memory. This defends a stolen disk, not a session you left open.
Someone reads the offline cache off the disk
Cached file content is sealed with AES-256-GCM under a per-connection key, with the content hash bound in as associated data so a block cannot be moved from one file to another.
Where it stops The cache’s metadata database is not encrypted: file names, sizes and modification times are readable on disk. If that matters for your threat model, that is the honest answer, and it is on the list to change.
Your storage provider reads your files
Switch on the encryption layer for that connection. Data is encrypted on your Mac before it leaves, in rclone’s crypt format; file and folder names can be encrypted too. The provider holds ciphertext and nothing else.
Where it stops Object sizes, counts and access times remain visible to the provider. Encryption hides content, not the shape of your usage.
We read your files
We cannot. Mountit connects your Mac to your server directly. There is no relay, no proxy, no bucket of ours in the path, and no code path that uploads file content or file names anywhere except to the server you configured.
A bad update, or a compromised us
The Mac App Store edition is signed and reviewed by Apple and updates through the App Store. The Mountit Pro edition is Developer-ID signed and notarized. Neither edition can update itself from a server of ours today, because neither contacts one.
Where it stops When the Mountit Pro licence service ships, that changes, and this page changes with it — see “What we will contact, later”.
Every host the app can contact
Grouped by who chose the host, because that is the distinction that
matters. A connection to a server you typed in is not the same kind of
fact as a connection to a server we compiled in.
Hosts we operate
We chose it
None. In the app as it stands today there is no connection to any server we operate: no update check, no catalogue fetch, no activation call and no telemetry endpoint, because none of them is wired to a caller. The mountit.app links in the app — Help, Terms, Privacy — hand a URL to your browser; the app does not fetch them, and if you never click one, nothing here is contacted.
Apple
Apple2 hosts
The Mac App Store edition is entitled through StoreKit 2, which means Apple’s own daemons talk to Apple about your purchase. That traffic does not originate in Mountit’s process and will not appear against it in a per-process network monitor — but it is real, and a reader auditing “does this app talk to Apple?” deserves to be told rather than to find out.
Host
Reached when
Apple’s App Store and StoreKit endpoints
Purchases, restores and subscription status, in the Mac App Store edition
Apple’s notarization and Gatekeeper checks
macOS verifying the Mountit Pro app on first launch, as it does for every notarized app
Hosts you configure
You chose it
The overwhelming majority of Mountit’s network traffic goes to a host you typed in. SFTP, SMB, FTP, WebDAV, HTTP, self-hosted S3, Seafile, DRACOON, Egnyte, Databricks, Snowflake, iSCSI and NVMe-oF have no default host at all: the address is yours, and so is everything the app does with it.
Preset endpoints we ship
We chose it9 hosts
The connection picker pre-fills the endpoint for well-known providers so you do not have to look it up. These are the fixed hostnames among the presets the app compiles in — nothing is contacted until you create a connection that uses one, and every other preset (every SFTP and SMB one included) addresses a host you supply. The list is generated from the app’s own preset table, and the build fails if the two disagree.
Host
Reached when
app.koofr.net
Koofr (WebDAV)
gateway.storjshare.io
Storj
s3.filebase.com
Filebase
s3.us-east-005.dream.io
DreamHost Objects
webdav.cloud.mail.ru
Mail.ru Cloud
webdav.fastmail.com
Fastmail Files
webdav.hidrive.strato.com
STRATO HiDrive
webdav.pcloud.com
pCloud (WebDAV)
webdav.yandex.ru
Yandex Disk
Sign-in hosts
Your provider21 hosts
Signing in to a provider opens that provider’s consent page in the system browser — ASWebAuthenticationSession, not a window of ours — and exchanges the result for a token. Your provider password is never typed into Mountit. These are the hosts involved.
Once a consumer-cloud or hosted-provider connection is mounted, the provider’s own API is the endpoint. Where you leave an endpoint blank, the service’s documented default applies — those are here too.
Host
Reached when
api.backblazeb2.com
Backblaze B2, native API
api.box.com, upload.box.com
Box
api.dropboxapi.com, content.dropboxapi.com
Dropbox — metadata and content
api.koofr.net
Koofr
api.pcloud.com or eapi.pcloud.com
pCloud — the US or EU region your account is in
cloud-api.yandex.net
Yandex Disk
g.api.mega.co.nz
MEGA
graph.microsoft.com
OneDrive and SharePoint
huggingface.co
Hugging Face datasets and models
ipfs.io
IPFS — the public gateway the app fills in when you leave the endpoint blank. Point it at your own node and it goes there instead.
s3.amazonaws.com
Amazon S3 when you leave the endpoint blank
storage.googleapis.com
Google Cloud Storage
www.googleapis.com
Google Drive — metadata, upload and quota
Requests nothing in the interface asks for
Three cases where a request happens as a side effect of something else.
They are all to a provider you already mounted, and they are here
because a host list that omitted them would be technically complete and
practically misleading.
Filling in the free and used space Finder shows for the volume. One call per volume-info request, to the provider you already mounted.
A request to {endpoint}/{bucket} before the first real S3 call
S3 region detection. Same host as the bucket, but it happens before anything you asked for.
apis.google.com/js/api.js
The Google Drive folder picker, which is a Google-hosted page. It loads only after a Google sign-in and only if you open the picker.
What we will contact, later
Two things are designed and not yet wired to anything that calls them.
Publishing them before they ship is the only way this page can be
checked against the app rather than the other way round. When they do
ship, the hostname appears above and this section shrinks.
Mountit Pro licence activation and the 30-day lease renewal
The licence key, a device identifier derived on your Mac, a display name so you can recognise the machine, the app version and a headless flag — and nothing about what you mount. The entitlement endpoint as written today accepts three fields: the licence token, the app version and the platform. It rejects outright any request that carries a query string or a cookie, and the server holds no signing keys of its own.
The signed announcement and offer catalogue
Nothing. It is a signed file fetched over HTTPS with redirect following switched off, and links inside it are restricted to <code>mountit.app</code> at parse time, so a signed-but-wrong entry cannot send you elsewhere.
No telemetry, stated so you can disprove it
“We respect your privacy” is not a claim; it cannot be false. These are
claims. Each one is a specific, checkable statement about the binary, and
any of them being wrong would be a bug we would want reported.
Mountit links no analytics, attribution or crash-reporting SDK. Not Sentry, Firebase, Crashlytics, Amplitude, Mixpanel, PostHog, TelemetryDeck, AppCenter, Bugsnag or Datadog.
The Swift side of the app opens no connection to any server: no URLSession, no URLRequest, no HTTP of any kind. Every socket that carries your data is opened by the Rust core, for a server you configured.
There is exactly one exception, and it is named here rather than left for you to find: MountitKit/BonjourDiscovery.swift browses your local network for NAS boxes advertising themselves over Bonjour, so you can pick one instead of typing a hostname you have never seen written down. Resolving an advertisement to an address is done the only way Network.framework offers — open a TCP connection, and cancel it the moment it is ready. No bytes are sent, nothing authenticates, and nothing off your own network link is reached. It runs when you ask to look for servers, and macOS puts it behind the local-network permission prompt. The build fails if any other Swift file opens a socket, and it fails if that file stops being named on this page.
The Xcode project references no third-party Swift package. There is nothing in the binary we did not write or vendor deliberately.
There is no App Transport Security exception of any kind — no NSAllowsArbitraryLoads, no exception domains.
There are no push notifications: no aps-environment entitlement, no remote-notification registration. Notifications the app shows are generated on your Mac.
Diagnostic logging goes to the system log on your Mac, off unless you switch it on, and is never uploaded. The diagnostic export is a file you choose to attach to a support message; it carries no credentials and no file contents.
What we have not verified
The list above was produced by reading the app’s source. That method has
limits, and a security page that hid them would be doing the opposite of
its job. Each gap names what would close it.
This audit read the source, not the wire
Every claim above comes from reading the app’s own source: greps for SDKs and for network calls, the endpoint constants, the entitlements files. Nobody put a proxy in front of a shipping build and diffed the result against this page.
Closed by A published packet capture of a fresh install and of one mount per protocol, repeated per release.
A pushed catalogue could add a preset this list does not name
The preset list above is generated from the table compiled into the app, and the build fails if it drifts — that much is now mechanical. What it cannot cover is the catalogue update the app is built to accept: an endpoint that turns out to be wrong is meant to be correctable by publishing a signed catalogue rather than by shipping a release, and such a catalogue could name a host this page does not. No build contacts that endpoint today, and the build asserts as much, so the list is complete for the app as it stands.
Closed by Publishing every pushed catalogue at a stable URL alongside this page, so the list a reader sees is the list their app resolved — and saying, on this page, when the first one ships.
Redirects can lead somewhere this list does not name
The catalogue fetcher and the OAuth token client refuse redirects outright. The provider clients — Box, MEGA, pCloud, the quota calls, the connection prober — use the HTTP library’s default, which follows them. Box and MEGA in particular hand you off to a download host that appears nowhere above, by design.
Closed by Either pinning the redirect policy per client and publishing it, or enumerating each provider’s documented content hosts.
The AWS credential chain can reach for cloud metadata
If you leave an S3 access key blank, the underlying signer falls back to the usual AWS chain: environment variables, ~/.aws/config, and — on a machine that has one — the link-local instance metadata address 169.254.169.254. On a Mac this normally fails, but it is attempted traffic and it is not a host we chose.
Closed by Disabling the config-file and instance-metadata loaders explicitly, then publishing the flags.
Proxies and DNS are the operating system’s, not ours
The HTTP stack honours the HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables, so a proxy configured that way becomes the actual peer. Name resolution uses the system resolver — there is no DNS-over-HTTPS and no resolver of ours — so your DNS goes wherever your Mac, your VPN or your network sends it.
Closed by Nothing to fix; it is disclosure. Both are documented here because a published host list that ignored them would be wrong.
The lower-level protocol stacks were not swept for discovery traffic
The audit covered the HTTP-based services in detail. The SFTP, SMB, FTP, iSCSI and NVMe-oF stacks were not checked for bootstrap or discovery traffic — SMB name resolution in particular can involve multicast on the local network. The one piece of local-network traffic that is accounted for is the Bonjour browse described above; the rest of what those stacks may emit before their first real request has not been captured.
Closed by A capture of one SMB mount to a NAS by hostname, and one by address, published alongside the rest.
Software bill of materials
Nothing to publish yet: no release has shipped. Rather than leave an
empty promise here, this is what a release will carry the day it does.
A CycloneDX document per shipped build, one for the Rust core and one for the Apple app, listing every dependency with its version and licence.
The SHA-256 of the artefact it describes, so a document cannot be quietly swapped for a different build’s.
A stable URL per release that keeps working after the release is superseded.
The changelog is where a shipped release
appears first, and every entry with a security consequence is tagged
and sorted to the top of its release rather than buried in “bug fixes
and improvements”.
Write to security@mountit.app. Tell us what you found and how to reproduce it; you do not need a proof of concept and you do not need to be certain. We will confirm within three working days and tell you what we think, including when we think you are wrong.
We will not threaten you with a lawyer for looking, we will credit you if you want credit, and a fix ships as a tagged security entry in the changelog rather than as an unlabelled line in “bug fixes and improvements”.
Does Mountit see my files?
No. There is no relay and no storage of ours in the path: the app connects your Mac to the server you configured, directly. We hold no copy of your data, which is also why we cannot recover anything for you when a server loses it.
Is the encryption something you invented?
No, and deliberately so. The optional encryption layer is rclone’s crypt format — scrypt key derivation, XSalsa20-Poly1305 content, EME-encrypted names — implemented to be byte-for-byte compatible and tested against a real rclone binary. That choice costs us nothing and buys you the ability to read your own data without us, which is what /exit is about.
Is Mountit Pro sandboxed?
No, and that is a deliberate trade. Mountit Pro is Developer-ID signed, notarized and unsandboxed, because attaching block devices is not something the App Store sandbox permits. The Mac App Store edition is sandboxed, and so is the File Provider extension that serves the mount in both editions. If an unsandboxed app is outside what you are willing to run, the Standard edition is the right one for you and we would rather say so here than in a support thread.
Where exactly are my passwords?
In one sealed record in Mountit’s own container, encrypted with AES-GCM, whose key is a Keychain item marked device-only and after first unlock and shared with the app’s extensions through a Keychain access group. Server names and usernames are inside the sealed record too, not just the secrets. It is not backed by the Secure Enclave — we would rather name the mechanism than dress it up.
Do you have a bug bounty?
Not yet — there is no revenue to fund one. The report path above is real and answered by the person who wrote the code, which is worth more at this size than a payout table we could not honour.