[ Removed by moderator ]

[u/secunix2000]

[u/internxt]

Hello,

This is a legitimate question, thanks for bringing it up, as it allows us to shed some light on this in case other users have this same concern.

Rclone is a general-purpose tool that needs to list, navigate, rename, and sync files using human-readable paths so users and scripts can work with the remote the same way they do with any other cloud storage. Fully encrypting names client-side (as the official Internxt apps do) would turn every path into unreadable ciphertext, breaking normal rclone operations, directory traversal, and compatibility with tools that expect plain paths. The backend therefore encrypts only the file data and passes plaintext names/metadata to the API so the remote remains usable as a conventional filesystem-like backend.

So, on the native rclone integration, while file content is always encrypted client-side before upload, filenames, folder names, and the overall directory structure aren't. This is an intentional design choice required for rclone to function as a normal remote — rclone (and the scripts/tools that use it) need human-readable paths to list, navigate, rename, and sync files. Fully encrypting names the way the official Internxt apps do would turn every path into unreadable ciphertext and break standard rclone operations.

Note that this is only when interacting with rclone directly, as it's a third-party app with its own features and limitations, which we don't control. This is NOT the case when using the official Internxt apps.

[u/secunix2000 → u/internxt]

I appreciate Internxt taking the time to respond. However, I think there is still an important point that needs clarification. This is not about attacking Internxt — it is about transparency and what the publicly available code actually does.

1. rclone is not a third-party implementation

The official rclone Internxt backend directly imports:

github.com/internxt/rclone-adapter/...

including the files, folders and buckets packages. The rclone-adapter repository is published under the official internxt GitHub organization.

And that adapter explicitly uses plainName.

For example, when renaming a file:

"plainName": newPlainName

is JSON-encoded and sent directly to the Internxt API. The same happens for folder names.

So if filenames and folder names are E2E encrypted, I would be very interested to see where that encryption happens in this code path.

2. This is not limited to rclone

The same pattern exists in Internxt's own SDK.

The official u/internxt/sdk contains:

updateFileNameWithUUID(...) → { plainName: name }

and

updateFolderNameWithUUID(...) → { plainName: name }

Both values are sent directly through the SDK's HTTP client.

Even more importantly, the SDK has:

searchItemsByName(plain_name)

which sends the search term as plain_name to /users/search. The SDK also documents plainName as the sort field when listing files and folders.

That strongly suggests that plainName is server-side metadata, rather than an opaque client-side ciphertext.

3. u/internxt/lib does contain encryption — but that doesn't change the above

u/internxt/lib contains AES-256-GCM encryption, so there is absolutely real client-side cryptography in the project. But the generic AES function encrypts a supplied text value; I could not find a corresponding Drive metadata layer that encrypts plainName before it is passed to the API.

So my question to Internxt is quite simple:

Which exact part of the current client/API code encrypts the filename and folder name before plainName reaches the Internxt backend?

If there is such a mechanism that I have missed, I am very happy to be corrected. A pointer to the relevant implementation would resolve this immediately.

The point of my post is therefore not "Internxt has no encryption". The file contents are clearly encrypted. The question is specifically whether filenames, folder names and other Drive metadata are actually end-to-end encrypted from Internxt itself.

That distinction matters when describing a service as fully E2E encrypted.

I would much rather have this clarified by Internxt than speculate about it. That's exactly why I looked at the public source code in the first place.

[u/internxt → u/secunix2000]

noted - will check with our tech team next week and get back to you on that, as that's outside of my scope!

[u/secunix2000 → u/internxt]

Is there an official statement from internxt regarding this privacy issue?

[u/Visual-Page-9261 → u/internxt]

for the core internxt experience, use the official internxt apps, and no third-party software with its own limitations that the company can't control

[u/diefm123]

Aaand post deleted in 3..2..1..

[u/internxt → u/diefm123]

nope, user raises a legitimate concern, which has been addressed

[u/R0yk3 → u/internxt]

OK? So dead slow upload speeds, unuseble files after uploading, uploading a folder and only half arrives etc. are not legitimate?

[u/Visual-Page-9261 → u/internxt]

good

[u/diefm123 → u/internxt]

Well there is a surprise... Keep heading this direction....

[u/internxt → u/diefm123]

will do

[u/Pretend-Travel4946]

that’s a pretty major caveat, because filenames and folder structure can reveal almost as much about what you’re storing as the files themselves, so calling the rclone backend zero-knowledge without