It's hard to see what value this adds over something like Duck Duck Go. Yes, it means the search provider can't see your IP... but there are other ways to do that, and you're trusting private.sh with your query and IP anyway.
Instead, what private.sh provides is a decoupling of your identity from your search query.
Private.sh can see your IP, but cannot see your search query.
The search engine can see your search query, but cannot see your IP.
Hope this helps clarify and thanks for the input! The search provider is constantly improving search results -- we'll be seeing significantly improved results over time!
Perhaps start with a statement like: "Private.sh sends all of your searches to a 3rd party search engine. These searches are private because we prevent the 3rd party search engine from knowing your IP or fingerprinting your browser. Private.sh can't see your searches because they are encrypted in your browser and can only be decrypted at the 3rd party search engine."
"Thus, the 3rd party search engine only sees your search, not your IP or browser finger print."
Thank you so much for your help and input!
And if private.sh can unilaterally modify the js, that doesn't mean much.
Also at some point the request has to be decrypted to send it on to the real search engine. You're also trusting private.sh to do that without deanonoymizing you. [Edit: appearently this step is done by gigablast, which is a separate company. That's at least a good thing. You're still trusting that both parties are acting honestly and competently]
In other words. If you trust private.sh not to be evil, then sure it works. But if we're just blindly assuming providers are good, we might as well just use google.
But can you actually prove it? The search provider isn't disclosed, we don't even know if it exists at all (as a separate entity).
How do I automatically validate that the JS hasn't changed between visits on my mobile?
(This is the problem with zero-knowledge-via-JS-delivery platforms that I've been unable to solve to date)
(This also applies to builds of client software, but for most operating systems those builds have to be signed with a private key, which makes them more difficult to compromise. On Linux, SHA256 checksums are usually provided alongside binaries - which are especially important to use against security-related client software.)
Note that one still must fully trust the root resource (the HTML response that bootstraps the web app). Whatever generates or stores that response up until it is wrapped in TLS is just as vulnerable.
While browsers support these headers I don't think any currently reject a page or resource if a digest doesn't match. But at least the mechanism is there.
There's also the draft  for signed HTTP messages. So a response can be signed and verified against a public key.
If the file itself that's being served was compromised, the web server will serve it with a new digest that matches.
But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
Looks like it works on (mobile) Safari as well, which is fantastic.
As written, it's more about a page validating the asset from a CDN, but it wouldn't be hard to also have a browser extension which pops up an SSL-like badge when all script resources on a page are marked as trusted by some validating third party.
> The search engine can see your search query, but cannot see your IP.
Should add: this will hold true until both are acquired, or one sell their part of the logs to a data broker - the party acquiring both, can correlate the data after - and if one party sell its half of the data the other half can acquire it...
(supplement with: we promise not to log data... Until ownership changes) .
With a normal proxy, a passive attack on the proxy is enough (since it will have both the request IP and search term in memory together at some point).
Whether this is indeed a meaningfully different threat model for most users is an interesting question.
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:
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.
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!
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"
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).
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.
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.)
Normally that term is used in messaging between two people to identify a system that puts the identity management and the control of the cryptographic keys under the exclusive control of those users. That is certainly not true in this case.
The client encrypts the search query with the public key of gigablast. The proxy proxies the encrypted payload to gigablast. Gigablast decrypts the payload, performs the search and encrypts the results with the client's public key which is included in the encrypted payload. Then, Gigablast passes the encrypted results payload back through the proxy to the end user who is able to decrypt the payload and display the results.
In conclusion, the proxy (private.sh) knows your IP, but not your search query. The search provider (gigablast) knows your search query but not your IP.
Edit: this was addressed in the comments. The end-to-end is between the client and Gigablast. Private.sh is the Signal server and it cannot see the request or response.
Wether the actual privacy as in is it possible to correlate queries to attribute a search to a given user is always preserved it’s hard to tell without looking at the implementation in depth but it provides some level of additional privacy at least to the level of a VPN.
[Client] ---> [Private.sh] ---> [Gigablast]
Your browser encrypts the query, clientside, before sending it to private.sh. All private.sh does is strips the IP away before sending it to gigablast.
Hope this is more clear!
I said it about Brave's purcahse of the defunct Clickz, and I will say it here:
Privacy is a feature, not a platform.
Building a business on this feature is not enough. It actually has to be better.
Competing with Google's 20+ year and 500 billion dollar head-start on broad search seem foolish unless you are willing to buy up the talent and resources to go head-to-head.
I'm not here to poo-poo effort, but I do think there is a better way.
One based on niches and human curation.
We can get around the problem of head-to-head competition with general search by focusing on better facets and data sets curated by subject matter experts.
At least, that is one hypothesis.
That's a problem to solve as well, but I think it could be solved if those subject matter experts were part of your business model and they were paid in some meaningful way.
I tried looking on the site, didn't find any mention of it, and the language used in the comments here seems somewhat evasive.
Edit: okay this is an initiative by PrivateInternetAccess and they are using https://www.gigablast.com/ as the search provider
The search provider is constantly working to improve its search results, and I believe that feedback like this is of great importance to catabolize this.
Thanks again for the feedback, it's well noted.
The FF add-on specifies "Custom License" without specifying which one.
That being said, with the private.sh offering, it requires two entities to collude to identify users.
Thus, it does provide more guarantees than DDG.
You only need 2 entities to collude if private.sh is acting honestly. If they are colluding you have already assumed they are not acting honestly.
I trust DDG not to track me.
I trust Private.sh to not give Gigablast my IP to track me.
It's cool that it's private, but I could pipe my searches to /dev/null and that'd be pretty private too. If I can't get a useable result, who cares?
that being said, i think 90% of the bad search results come from the index being too small (straight up lacking the best web page), or not having good enough synonyms.
In other words, if "Search Engine Company" wants to deanonymize and link your search with your query, they can.
If Private.sh or Gigablast want to, the two separate entities will have to collude. This isn't zero-trust, but it's absolutely 'lesser trust' than the current offerings outside of Private.sh.
In what way? How do I know the two owners of the companies aren't the same person? Heck, how do I know that Private.sh isn't just a Google spinoff?
There's absolutely nothing that guarantees that Private.sh and Gigablast aren't the same person or the same company.
I'd say it's the same level of trust as DDG or Google.