[1] https://www.voxmarkets.co.uk/articles/kape-technologies-to-a...
In this case, your query is encrypted on the client side, passed through a proxy, decrypted at the engine, search is performed, and then results are encrypted, passed through the proxy, and the client side decrypts and displays the results.
USER Encrypted Search --- Proxy --- Search Engine Decrypts Search, Searches, Encrypts Search --- Proxy --- USER decrypts results and displays.
The search engine does not know your IP, and Private.SH does not know what you searched for.
but
"your query is encrypted on the client side"
and then
"the client side decrypts and displays the results"
So all this encryption/decryption code, where does it come from?
If the answer is Private.SH, then Private.SH can in fact know what the user searched for and the results they got by feeding the user code that sends that information (or even just the encryption keys) back to Private.SH
Also, I'm not clear on how the search engines are supposed to be able to decrypt something encrypted by the client. What actually happens there?
So you're using the search engine's public key to encrypt it, meaning the proxies can't decrypt it. But yes, you have to trust the client-side code, which is an insurmountable problem.
On the plus-side, the code is really short and easy to read. Perhaps a standalone app with reproducible builds could solve this, but that's much more of a pain than simply entering your query straight from the browser.
Edit: I was also going to mention that you can download the chrome/firefox extension by themselves, but the download link has an expired certificate which doesn't instill much confidence.
That depends on what you're trying to achieve, who you're willing to trust, and what you're willing to do.
If your goal is to do searches without having to trust client-side code from a search engine or Private.SH, then you could (assuming they have support for such a workflow) do your own encryption using a tool you do trust, such as gpg, then submit the encrypted query to Private.SH, which would hand it off to the search engine.
The search engine could then decrypt it, perform the query, and re-encrypt it to your public key (which would be contained in the encrypted query they got) and pass it back to Private.SH, which would then pass the encrypted query back to the user.
This way no code from Private.SH nor the search engine has to be trusted.
Of course, this does not help if Private.SH is secretly owned by, compromised by, or has a data-sharing agreement with some entity you don't want your data to be seen by (such as the search engine, hostile agency, data harvesting/reselling organization, etc).
This latter possibility is what I really don't see an easy way to mitigate.
For all we know any/all of these "privacy respecting" services might be owned by Google, Palantir, some other data harvesting corporation, government agency, intelligence service, etc.
If both are untrusted parties in cahoots with each other, then there's no getting around private.sh and gigablast sharing both the IP (courtesy of private.sh) and query (courtesy of gigablast) to each other.