u/secunix2000

I recently looked into the Internxt rclone backend and found an important distinction regarding Internxt's E2E/zero-knowledge claims.

The file contents are encrypted client-side, but the native Internxt rclone backend does not encrypt filenames or folder names before sending them to Internxt.

The Internxt server therefore receives the actual plaintext names and directory structure as part of the API requests.

For example:

Private/
└── Tax/
    └── 2025_Tax_Return.pdf

Internxt receives Private, Tax and 2025_Tax_Return.pdf in plaintext, even though the contents of 2025_Tax_Return.pdf are encrypted.

This means that not all file-related information is end-to-end encrypted. The provider has direct access to filenames, folder names and the directory structure, as well as other metadata such as file sizes and timestamps.

I originally posted this finding in the r/Internxt subreddit, but a moderator deleted the thread. I was not given an explanation for the removal.

I'm therefore posting it here because I think this is an important distinction that users should be aware of and that can be independently verified by looking at the rclone/Internxt implementation.

To be clear: I'm not saying Internxt can decrypt the file contents. I'm saying that the filenames and folder structure themselves are transmitted to the Internxt server in plaintext.

I recently looked into how the Internxt rclone backend actually handles encryption, and I found an important distinction that isn't obvious from Internxt's E2E/zero-knowledge claims.

File contents are encrypted client-side, but filenames and folder names are not encrypted by the native Internxt rclone backend. They are sent to the Internxt servers in plaintext as part of the API requests.

This means Internxt can potentially see things like:

• filenames
• folder names
• directory structure
• file sizes
• timestamps and other metadata

For example, if you upload:

Private/
├── Tax/
│   └── 2025_Tax_Return.pdf
└── Medical/
    └── Medical_Report.pdf

Internxt can still see the names and structure, even though it cannot decrypt the actual file contents.

So in my view, saying simply "Internxt is end-to-end encrypted" is misleading if this is meant to imply that all information about your files is E2E encrypted.

The more accurate statement would be:

>Internxt encrypts your file contents end-to-end, but filenames, folder names and certain metadata are not end-to-end encrypted.

I'd be interested to hear if anyone has looked into the Internxt API/client implementation in more detail and can confirm exactly which metadata is stored and whether any of it is additionally encrypted server-side.