If encryption is just through TLS how is this different than just sending your normal https based searches through a VPN or TOR?
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.
[1] https://chrome.google.com/webstore/detail/privatesh-private-...
[2] https://addons.mozilla.org/en-US/firefox/addon/private-sh-pr...
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!
Both parts are not in control of the same entity.
That said, thanks for the input and comments!
Edit: If you have any more input on how it can be approved, I would love to hear it! :-) My email is in my profile!
How does that work? Do you or a subcontractor of yours not host the javascript responsible for the encryption?
Edit: okay so this piqued my interest and the site has this to say: "Public IP is stripped away by the Private.sh proxy" (so you run the proxy) and "Search Provider decrypts the query". So the point is that Privacysh != Search Provider I guess? That begs the question whether one is a subcontractor or side project of the other, or hosted in the same physical space, or something else that make this effectively the same as not proxying it. Also because you need to coordinate on what JS is being delivered to some extent: if Privacysh doesn't use the right pubkey, the SP can't decrypt it.
It feels a bit like Telegram who says "all our chats are encrypted, really! We can't read your messages!" but is still somehow able to deliver the plaintext messages to your client at a very fast rate. The trick being that "the key is stored in another datacenter as the message" but of course Telegram owns both and that's how they combine it for intercepting, ahem, for delivering messages to your phone. This isn't the same, but without more background info it seems similar. Then again, it can't be worse than the status quo, so still good that you're working on this one way or another!
Thank you. To clarify, private.sh != search provider (gigablast). Thus, it would take collusion between both to couple the identity of the searcher to the search query.
private.sh does not have access to the private key associated with the public key that's used to encrypt the search query!
That seems doubtful. Which party is in control of the end where decryption takes place if not private.sh?
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.
And is the proxy a service under your control?
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?
This is vague. It seems like it just means: "we have a TLS certificate and will be a proxy between you and Google"
That said, I agree, you could absolutely do the same with an onion router. This simply provides the benefit without having to do so.
As someone who uses tor everyday, you basically can't get any higher quality general purpose search than duckduckgo or searx to actually load over onion routing. If you position yourself in such a way that your results engine returns queries on par with those two (or preferably better) you will have a rock solid product in your hands.
It's a bit more than that -- the search query is encrypted client-side. This means that the private.sh search proxy cannot see what the query is. Then, the query is delivered to the search engine. The search engine does not know the IP origin of the search query.
This means that the search query and the identity of the searcher is decoupled, providing significantly more privacy.
Hope this is clear!
Is this client side encryption the same regular TLS encryption that I would normally (no proxy involved) send to the search engine or is there some kind of buy-in from the search engine to handle it a different way?
It requires the search provider to utilize NaCl to decrypt (requires buy-in from the engine).
What the heck is a search provider though?
EDIT: looks like it’s “gigablast”. I don’t understand why I just wouldn’t use that search engine directly?
The point is that Gigablast doesn't know details about the user (though I'm not sure why private.sh's servers can't just forward the IP), and private.sh doesn't know what search query was sent (which, if you're using the extension and disable auto-updates, you can verify that this is actually the case. The code is short and readable.)