Client-side search is secure if the client downloads all the metadata, and then nothing else based on the result. The access pattern is simply which and how man

Client-side search is secure if the client downloads all the metadata, and then nothing else based on the result. The access pattern is simply which and how many encrypted chunks are selected. If they are selected based on a search result there could be a statistical correlation. Not that every leakage is critical, for example if you write chunks when the user uploads a file the client just leaked that an upload happened, it also leaked how much data was written. Depending on the use case this might not lead to sensitive information leakage. It however might, for example if a hospital has an app that let's you download information about your disease an adversary could leak which disease you have without compromising the encryption. The most advanced technique of hiding which chunks are accessed, or whether they are written or read is called ORAM. ORAM makes chunk accesses indistinguishable, however this technique has a logarithmic overhead, it fails to hide how many chunks are accessed, and it is also hard to design a search protocol on top of it that does not create patterns in the ORAM accesses, which can be also analyzed. A practical solution is a search protocol that tries to decouple the results from the accesses. https://www.researchgate.net/publication/356077294_Access_Pattern_Hiding_in_Searchable_Encryption https://www.researchgate.net/publication/356077294_Access_Pa... This paper is just an idea, I'm designing a different protocol that is more efficient, but requires persistent client cache, which is just becoming a reality for web clients.