6 ms·

Thanks for taking a look, and that's a great question. The search is both end to end encrypted and private. In the sense of end to end, if you rely on TLS alo

Thanks for taking a look, and that's a great question. The search is both end to end encrypted and private. In the sense of end to end, if you rely on TLS alone and send your query directly to the search engine, your IP will be attached to said query and thus your search and identity are coupled. In private.sh, it's both end to end and private: 1. We utilize client-side javascript encryption prior to routing a search thru a proxy. 2. The proxy cannot read the query, and simply forwards it to the search engine. 3. The search engine decrypts, performs the search, and encrypts the results which are sent back thru the proxy (who, again, cannot even read the results). 4. The results are decrypted client-side. Thus, your search query and identity are decoupled.

deanclatworthy 6y ago
If you're going to rely on any client-side javascript please use subresource integrity for all your assets.
- speedgoose 6y ago
  If TLS is compromised, you cannot trust the subresource subresource integrity checksums. It's better than nothing but there is no good solution.
  - blueplanet200 6y ago
    Indeed, if TLS is compromised many security guarantees of the web break down.
  - bawolff 6y ago
    Which is why this whole exercise is a bunch of snake oil. You can't have better than TLS security when TLS is the weakest link.
    - blueplanet200 6y ago
      This is just plain false. This search engine is advertising anonymity. You don't get that when searching Google, which is encrypted with TLS...
  - rasengan 6y ago
    Our solution here is our extensions [1][2] which are hosted and served by google and mozilla (third parties). [1] https://chrome.google.com/webstore/detail/privatesh-private-search/fcehiiknopcbcdnpakbeipijiiceobnl https://chrome.google.com/webstore/detail/privatesh-private-... [2] https://addons.mozilla.org/en-US/firefox/addon/private-sh-private-search/ https://addons.mozilla.org/en-US/firefox/addon/private-sh-pr...
lucb1e 6y ago
That's very similar to what Tor does. And since both parts are under control of the same actor, it's not very different from, well, not doing it. But too often ideas are shot down because they're not "helpful enough" or something. I shouldn't be too critical! It's great to see someone working privacy in the search space beyond tech that is already there. Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage, perhaps we can iterate upon the design later (somehow introduce user-run proxies so that the search server really cannot know who sent the request? Somehow make the javascript reload only every once in a while, so you can't silently change it for everyone at once as an attacker? People monitoring the subresource integrity tags for unexpected changes? I don't know). I'll be curious to see where this takes us!
- dwohnitmok 6y ago
  > Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage This is potentially huge. Maybe for a resource-light webpage (in terms of content downloaded by the user) the overhead of a Tor onion architecture is negligible and combined with being able to use your regular old browser with no special configuration, that could mean just having specialized onion architectures for certain websites could make privacy a lot easier to realize for the end user. The barriers of slow load times for every webpage and the need for end user configuration are pretty big barriers.
  - lucb1e 6y ago
    I mean, there's a reason we're not commonly doing this: a setup where the relaying and the back-end component are from the same organisation make it fairly useless. You need to find an established partner that wants to work with you to have some claim to not be colluding. And even if so, the front-end can always deliver another piece of javascript that carries off a copy of the plaintext to a server of their own. This setup has some clear disadvantages over Tor. But to repeat what I said before: I shouldn't be too critical when all I'm really saying is "it might not help enough to be worth the effort". If there are no downsides either (well, the effort, but that's up to the dev and consequently the user who pays the dev indirectly) then it's better to do it.
yikesshescute 6y ago
How do I verify that my query is being encrypted in the browser? And is the proxy a service under your control?
- rasengan 6y ago
  The javascript source should show you that it's being encrypted -- and the proxy is under our control, the search engine is not.
  - yikesshescute 6y ago
    Then every time I want to make a query I must re-audit the JavaScript source? And, do you have any ideas about setting up the proxy so that I don’t have to trust that it is being operated as advertised?
judge2020 6y ago
Given that no external domain is contacted to pull the public key to encrypt with, how do we know the proxy won't send its own public key to the browser then forward the query to the search engine via a different encrypted payload?
- rasengan 6y ago
  In this case, the only way to be sure of this is to use the private.sh extension[1] which has the public key hardcoded in and is being served by google and mozilla. [1] https://private.sh/extension.html https://private.sh/extension.html

deanclatworthy 6y ago

If you're going to rely on any client-side javascript please use subresource integrity for all your assets.

speedgoose 6y ago
If TLS is compromised, you cannot trust the subresource subresource integrity checksums. It's better than nothing but there is no good solution.
- blueplanet200 6y ago
  Indeed, if TLS is compromised many security guarantees of the web break down.
- bawolff 6y ago
  Which is why this whole exercise is a bunch of snake oil. You can't have better than TLS security when TLS is the weakest link.
  - blueplanet200 6y ago
    This is just plain false. This search engine is advertising anonymity. You don't get that when searching Google, which is encrypted with TLS...
- rasengan 6y ago
  Our solution here is our extensions [1][2] which are hosted and served by google and mozilla (third parties). [1] https://chrome.google.com/webstore/detail/privatesh-private-search/fcehiiknopcbcdnpakbeipijiiceobnl https://chrome.google.com/webstore/detail/privatesh-private-... [2] https://addons.mozilla.org/en-US/firefox/addon/private-sh-private-search/ https://addons.mozilla.org/en-US/firefox/addon/private-sh-pr...

lucb1e 6y ago

That's very similar to what Tor does. And since both parts are under control of the same actor, it's not very different from, well, not doing it. But too often ideas are shot down because they're not "helpful enough" or something. I shouldn't be too critical! It's great to see someone working privacy in the search space beyond tech that is already there. Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage, perhaps we can iterate upon the design later (somehow introduce user-run proxies so that the search server really cannot know who sent the request? Somehow make the javascript reload only every once in a while, so you can't silently change it for everyone at once as an attacker? People monitoring the subresource integrity tags for unexpected changes? I don't know). I'll be curious to see where this takes us!

dwohnitmok 6y ago
> Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage This is potentially huge. Maybe for a resource-light webpage (in terms of content downloaded by the user) the overhead of a Tor onion architecture is negligible and combined with being able to use your regular old browser with no special configuration, that could mean just having specialized onion architectures for certain websites could make privacy a lot easier to realize for the end user. The barriers of slow load times for every webpage and the need for end user configuration are pretty big barriers.
- lucb1e 6y ago
  I mean, there's a reason we're not commonly doing this: a setup where the relaying and the back-end component are from the same organisation make it fairly useless. You need to find an established partner that wants to work with you to have some claim to not be colluding. And even if so, the front-end can always deliver another piece of javascript that carries off a copy of the plaintext to a server of their own. This setup has some clear disadvantages over Tor. But to repeat what I said before: I shouldn't be too critical when all I'm really saying is "it might not help enough to be worth the effort". If there are no downsides either (well, the effort, but that's up to the dev and consequently the user who pays the dev indirectly) then it's better to do it.

yikesshescute 6y ago

How do I verify that my query is being encrypted in the browser? And is the proxy a service under your control?

rasengan 6y ago
The javascript source should show you that it's being encrypted -- and the proxy is under our control, the search engine is not.
- yikesshescute 6y ago
  Then every time I want to make a query I must re-audit the JavaScript source? And, do you have any ideas about setting up the proxy so that I don’t have to trust that it is being operated as advertised?

judge2020 6y ago

Given that no external domain is contacted to pull the public key to encrypt with, how do we know the proxy won't send its own public key to the browser then forward the query to the search engine via a different encrypted payload?

rasengan 6y ago
In this case, the only way to be sure of this is to use the private.sh extension[1] which has the public key hardcoded in and is being served by google and mozilla. [1] https://private.sh/extension.html https://private.sh/extension.html