So in case you don’t know Version 5 launched last week and brought with it a few notable main features:
Space Inspector - an easy way to scan any remote at any level and build a recursive index of where all your storage space is being used up and provide a way to preview files and select files and folders for deletion allowing you to cleanup large amounts of space quickly and easily
Doppel Duplicate Scanner - a tool that lets you scan any remote at any level recursively for exact and visually or audibly similar media item matches and groups them and supports custom rules to auto select the items you want to keep in each group by different metadata and content details as well as support for custom overrides in bulk and per group. You can also preview any media item as you make your selections.
Adds git support to the Code editor as well as tabs in the code editor.
Then following the release of v5 I decided to continue work on improving the overall performance and efficiency of Enter Space making it feel super nice to use all the many features and that’s what the focus of v5.0.1 That updates the Rclone library version to 1.74.0 and utilizes a new memory and cpu efficient engine for numerous scanning based patterns used in things like the Photos Library Backups, Doppel and Space Inspector.
The latest v5.0.1 also implanted an automatic rolling SSL certificate in app that allows the entire app to fully utilize HTTPS for all internal communication bringing just another layer of security to Enter Space. What this means is the app no longer listens on plaintext HTTP and now conforms fully to Apples Strict Application Transport Security guidelines without an exception!
And the last things was adding support for Rclone Config Encryption following Rclone’s standard approach making it Backwards compatible with an existing Rclone Configuration Password. Set the password in Settings of Enter Space and it will be securely stored in Keychain and it has the added feature of decrypt on the fly if you use the Edit Text feature on the App Documents rclone.conf
V5.0.1 is live on tvOS, iOS and macOS!
Thank You for your continued support and questions and I hope these features will be useful to the mighty few users of Enter Space now and to any future Enter Space Navigator!
First off, congrats on the recent launch of Version 5!
Because Enter Space handles critical cloud credentials, infrastructure access tokens, and SSH keys in a closed-source ecosystem, I'm sure a few of us would like to better understand the threat model and security boundaries to comfortably deploy it for more sensitive workflows.
I noticed in the recent documentation updates that a comprehensive security audit was completed in April 2026, which is fantastic peace of mind. To help us better understand those results and how the app functions under the hood, I was hoping you could shed some light on a few quick questions:
The April 2026 Security Audit: Could you share a bit more detail regarding the scope of this recent audit? Was it a full source-code review, and do you plan on publishing a redacted public summary or letter of assessment from the auditing firm for users to review?
Credential Isolation & Keychain Boundaries: With features like the integrated Git client and code editor sitting in the same app bundle, how are the rclone.conf credentials isolated internally? Are OAuth tokens and sensitive configuration data completely extracted into the native iOS/macOS Apple Keychain to prevent potential cross-feature vulnerabilities, or are they partially held in a local app-specific database?
Internal Server Security: It’s great that v5.0.1 forces HTTPS via rolling SSL certificates to meet Apple's Strict Application Transport Security guidelines. How does the local app-side server ensure that other local processes or malicious apps running on the same machine cannot attempt to intercept or issue commands to this internal API? Is the rolling passphrase randomized per session?
Upstream Updates & Binaries: How do you approach tracking and compiling upstream rclone releases/CVEs into the app? Are the compiled binaries completely unmodified from the official open-source rclone Go core, and does the entire File Provider extension strictly obey the standard macOS/iOS App Store sandboxing rules?
Crash Reporting and Logging: You've emphasized that the app collects zero usage data. To confirm, does this include crash logging? Does Enter Space completely bypass third-party logging frameworks (like Firebase, Sentry, or Crashlytics) that might accidentally leak environmental variables, remote names, or path structures in a crash dump, relying solely on standard, anonymized App Store Connect logs?
Thanks again for all your hard work on this project!
The audit was done through use of popular ai based auditing tools with full code level access. It was not conducted from a specific firm. It was iterated on until the ai was unable to find any security issue.
The rclone.conf and all secrets are kept inside Keychain on the device either through iCloud or not if disabled and only pulled when used for a specific secret as needed. Which for the rclone library is almost immediately for all features of the app. The rclone.conf data can be kept encrypted to follow Rclone's encypted config approach that is all open source already. As for the code editor it is open source under my own public repository "KeyStone" similarly the media gallery is open source under "MediaStream" as for the boundaries everything is encrypted if it is stored on disk and some pieces need to be for it to work within apples strict memory limitations for some platforms so even if a snapshot was taken the data would be fully encrypted with a rolling passphrase located in the users keychain. When the passphrase is rolled the encrypted datasets on disk are re encrypted with the new passphrase. The app uses encryption in the SQLite db files it stores on disk for some performance features so that no information is leaked from those as well even being a cache. The passphrase rolls on average once every hour but is subject to change in a variety of situations.
The app uses Rclone's rc server with authentication that is randomized on a rolling basis with an htpasswd file leveraging bcrypt hashes. The file will also include the users manually entered credentials when set so while out of the box it will be really secure it is dependent on the user not using a weak password in settings if they want to use that feature. The TLS is just for the rc server and is pinned within the app. If there is a malicious software on the same machine I can't guarantee the app is impervious to all attacks but the attack vectors I can control pertaining to other non privileged apps messing with or compromising Enter Space are rather mitigated with all the encryption in place and standard practices and inherent benefits from Apple Sandboxing Apps. Nothing is ever foolproof but I've done everything I can think of to harden it as best as I can. I don't have a budget or make enough to entertain a security bounty at this time.
I have a fork of Rclone on my GitHub it has a couple small changes that allow enter space to facilitate its level of integration. It gets brought into a custom go mobile xcframework build that is updated regularly with Rclone.org upstream changes. I update it and bring in upstream to the latest stable release and it depends on apples app review times on when exactly I can get it deployed. If it is critical I can always have Apple expedite the review. And yeah it uses Apples strict sandbox requirements for any App Store release that's kind of the point.
The app has its own local logging it has some general redacting it can apply automatically nothing is ever sent automatically anywhere. I have general info that App Store Connect provides. If the user shares crashes with third party developers it will show up in Xcode. Nothing outside of what Apple already provides based on what users opt in for and enable themselves or what the user supplies me directly via email by manually attaching logs or in natural conversation. I do not use third parties for monitoring or logging or debugging the app.
Overall you'll find that I try to do things as secure as possible because it's important to me too. I understand with a closed source software to be entrusted with users secrets is a tall ask. It's why I don't hide who I am and I'm not planning on going anywhere. I built this app to fulfill my own needs and other people have found some utility with it. Not everyone will want to use it and it may not be what they need but I have found it to be quite useful myself. I take peace in knowing I'm using standardized rclone methods for most things and I keep everything encrypted wherever possible so hopefully an on machine attack vector would be effectively mitigated. As someone who has thought a lot about how to do this securely and setup a ton of tooling on top of Rclone to enable these extra security layers I don't think someone would take on that effort without considerable care for the final product. I can't make everyone trust me and I'm not trying to at the end of the day if you use my app and like it that's great. I won't lose sleep over the people who don't find my app useful. Again it works great for my needs and that's why I built it and maintain it.
and welcome to the forum!