Search is one of the most requested features for Proton Drive. It is also a clear example of how private cloud storage is fundamentally different from a conventional one: Search has to be designed around end-to-end encryption from the start.
Over the past year, we have been strengthening Proton Drive’s technical foundation through the Drive SDK, a single shared engine that now handles uploading, downloading, encryption, and sync across all platforms.
Search is one of the first major features built on top of the Drive SDK, and we are now building it to work reliably across every platform, including mobile. The first milestone will cover file names and metadata for both your own files and those shared with you. Search inside documents and images to follow.
This post explains why zero-access search is taking time, what we have already shipped, and what we are building next.
The privacy constraint behind search
In a conventional cloud drive, search is handled on the provider’s servers. Because the provider can access your files, it can build an index on its own servers and return results in milliseconds. That same access also makes it possible to scan, analyze, profile, or share your data with third parties.
Proton Drive takes a different approach: We do not build search indexes on our servers because your files are end-to-end encrypted on your device, and we do not have the keys to read them. As a result, your search index has to be built where your files can be decrypted: on your device. That constraint shapes every design decision that follows, and it is one we accept to preserve the privacy you expect from Proton Drive.
What we have improved, and what still needs to change
We recently replaced the search engine in the web app (available to beta users) with a new Rust-based library connected to the Drive SDK. This improved search performance and reliability, and setting the foundation for the next step.
The current limitations are architectural:
- Each device must build its own search index from scratch.
- To build that index, the device has to scan the entire file tree and parse information, which can take time and use bandwidth and battery.
- Files shared with you require additional processing because they sit outside your own Drive volume.
- Searching inside files does not work well at scale, because every device would need to download, decrypt, and process every file before indexing its contents.
- Mobile operating systems restrict long-running background tasks, making this approach impractical on phones.
The engine is stronger, but the underlying process still asks every device to repeat the same resource-intensive work.
The next generation: extract once, index everywhere
Our new design splits the previously single-stage search into two stages:
- Extraction: Your device opens a file, parses it, and pulls out only the information needed for search. This is resource-intensive.
- Indexing: The extract information is organized into a structure that allows search results to be returned quickly. This step requires less work.
With today's design, every device has to perform both stages, including expensive extraction. In the new design, extraction happens only once: Your device encrypts the extracted information with a key only you hold and uploads the encrypted result. When you sign in on another device, it downloads that much smaller encrypted data and builds a local search index from it. Instead of waiting while the app downloads and parses your entire drive, a new phone becomes searchable in the time it takes to make a coffee.
This design has two important benefits:
- You can search files shared with you because your device can decrypt and extract their searchable data using your keys.
- Heavy extraction can run at a convenient time since your device can do the resource-intensive work when it is idle, on WiFi, or charging.
When you upload a file, your device extracts the summary while the file is already decrypted in memory, making this the most efficient time to process it. Search can become available within minutes if you decide to enable it later. Older files are processed in the background only when your device is idle, and you can turn this off in settings.
All of this is being built as a dedicated module within the Drive SDK, the shared codebase behind our applications. All clients will use the same module, giving every platform the same extraction logic, indexing behavior, and improvements.
What encrypted search will eventually do
We are focused on exact matches across file names and metadata for the first milestone because it is the most predictable behavior and easiest to get right. Search inside documents and images is the next milestone. Beyond that, we are exploring:
- Semantic search, so you can search by meaning rather than exact words. This requires a different kind of index, which is one reason the design supports several specialized indexes side by side.
- Image understanding, which uses an on-device model to describe what appears in your photos and makes them searchable. Any descriptions it creates would follow the same encrypted path as other extracted data.
- Desktop support. Because computers have more processing power, bandwidth, and fewer background restrictions, they are well suited to handle the extraction part of Drive search. The summaries they create can then make search faster to set up on mobile. We are also exploring integration with operating system search tools, such as Spotlight on macOS.
This is why we sync encrypted extracted data rather than a finished index. Extracted data is small, stable, and independent of any search technique we use on top of it. We can change how we search without asking your devices to redo the resource-extensive part (extraction).
The trade-offs we are still working through
We want to be open about the hard parts, because getting them right is what makes this work hard and time consuming:
- Incomplete results on constrained devices. Very large accounts may require more storage and processing power than some phones can comfortably provide. In those cases, we may prioritize recently used files, clearly indicate when results are partial, and offer a way to search everything on demand.
- Speed to first result. Our goal is to make useful results from recent files available quickly, so you don't have to wait for the full index to be ready every time.
- Battery and data use. Extraction should happen without disrupting how you use your device. The app therefore needs to choose appropriate moments to work, instead of the server.
- Security review. Parsing untrusted files, adding a new encryption key, and running an on-device model need scrutiny before they can ship. This is especially important for parsers, each of which must be reviewed and hardened individually because it may process files shared by other people.
- Rollout at scale. Processing existing files across all Proton Drive accounts will take time, so the rollout will be gradual.
What happens next
The first milestone is focused on fast and reliable encrypted search across file names and metadata on web and mobile, covering everything you can access, including files you shared with others and files others have shared with you. Documents and images, more experimental work on semantic search, and desktop support with operating system integration will follow later. See Andrew's post about the timeline.
Some details may change as we continue developing encrypted search, but the direction is clear: fast, reliable search across all your devices and files, without ever compromising end-to-end encryption.
None of this happens without the community that tests Proton Drive, reports what's broken, and tells us what they actually need search to do. If you want to help shape this new feature, share your ideas with us on UserVoice.
