4 ms·

Most of it's answered here https://private.sh/how-it-works.html https://private.sh/how-it-works.html So you're using the search engine's public key to encrypt

Most of it's answered here https://private.sh/how-it-works.html https://private.sh/how-it-works.html 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.

pmoriarty 6y ago
"you have to trust the client-side code, which is an insurmountable problem" 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.
- prophesi 6y ago
  Hm, I think your idea of letting the search engine decrypt with your public key would solve the issue of private.sh being the untrusted party. The search engine would be able to send back the encrypted results which private.sh wouldn't be able to see. 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.

pmoriarty 6y ago

"you have to trust the client-side code, which is an insurmountable problem" 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.

prophesi 6y ago
Hm, I think your idea of letting the search engine decrypt with your public key would solve the issue of private.sh being the untrusted party. The search engine would be able to send back the encrypted results which private.sh wouldn't be able to see. 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.