7 ms·

> and you're trusting private.sh with your query and IP anyway. If you take a look at the javascript, the query is absolutely encrypted before private.sh can s

> and you're trusting private.sh with your query and IP anyway. If you take a look at the javascript, the query is absolutely encrypted before private.sh can see it. In other words, private.sh cannot see it. 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!

oarsinsync 6y ago
> If you take a look at the javascript 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)
- mikepurvis 6y ago
  I believe the current direction is to piggy-back off of subresource integrity: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/ 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.
- TimTheTinker 6y ago
  This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the browser. Break into their static file server or CDN/edge cache and you've effectively pwned any browser sessions started after that point. (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.)
  - giantrobot 6y ago
    Browsers support Subresource Integrity [0] checks. You provide an integrity attribute (or several) for a script or link resource and the browser will check the hash(es) before using the resource. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://w3c-test.org/subresource-integrity/subresource-integrity.html https://w3c-test.org/subresource-integrity/subresource-integ...
    - fabrice_d 6y ago
      Yes, but there is the problem of bootstrapping that chain of trust: how do you know that the SRI attribute value has not been tampered with? TLS protects transit, but not server side breaches.
      - TimTheTinker 6y ago
        Right. Subresource integrity checks eliminate the need to trust the source of the subresource, but not the main resource (the HTML response that bootstraps the app). But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
      - giantrobot 6y ago
        If you're doing an SPA where the HTML is just loading your JavaScript for the meat of your app it's straightforward to verify that file. Besides literally comparing its hash to a known good value there's the Digest header [0] which is a way to provide a resource hash to a client. From the browser side there's the Want-Digest header [1]. These replaced the Content-MD5 header. 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 [2] for signed HTTP messages. So a response can be signed and verified against a public key. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Di... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Wa... [2] https://tools.ietf.org/id/draft-cavage-http-signatures-10.html https://tools.ietf.org/id/draft-cavage-http-signatures-10.ht...
dandanua 6y ago
You assume that the proxy and the search provider follow these rules and do not cooperate in a different way (e.g. the proxy can send a query with an IP). 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).
- soperj 6y ago
  I don't think it's an assumption in this case because they are the ones running the proxy.
gwbas1c 6y ago
I think there's a lot of confusion over this topic because the general explanation is confusing. "XXX is encrypted in the browser" implies that XXX is encrypted because of TLS. 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."
- rasengan 6y ago
  You're absolutely right. This is a much better explanation, and we'll improve our language with this advice in mind. Thank you so much for your help and input!
bawolff 6y ago
> If you take a look at the javascript, the query is absolutely encrypted before private.sh can see it. In other words, private.sh cannot see it. 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.
- rasengan 6y ago
  You can use the private.sh extension [1][2] to ensure that private.sh isn't doing anything fishy. The public key of Gigablast is hardcoded in and the assets are served by a third party. [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...
  - jedberg 6y ago
    I still have to trust that Private.sh isn't working with Gigablast to de-anonimize the request.
    - rasengan 6y ago
      That's true. This is the same as Tor in the sense that if multiple parties collude, you can be de-anonymized.
      - e12e 6y ago
        It's different from TOR in that only two parties need to collude, though.
  - 6y ago
e12e 6y ago
> 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. 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) .

oarsinsync 6y ago

> If you take a look at the javascript 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)

mikepurvis 6y ago
I believe the current direction is to piggy-back off of subresource integrity: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/ 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.
TimTheTinker 6y ago
This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the browser. Break into their static file server or CDN/edge cache and you've effectively pwned any browser sessions started after that point. (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.)
- giantrobot 6y ago
  Browsers support Subresource Integrity [0] checks. You provide an integrity attribute (or several) for a script or link resource and the browser will check the hash(es) before using the resource. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://w3c-test.org/subresource-integrity/subresource-integrity.html https://w3c-test.org/subresource-integrity/subresource-integ...
  - fabrice_d 6y ago
    Yes, but there is the problem of bootstrapping that chain of trust: how do you know that the SRI attribute value has not been tampered with? TLS protects transit, but not server side breaches.
    - TimTheTinker 6y ago
      Right. Subresource integrity checks eliminate the need to trust the source of the subresource, but not the main resource (the HTML response that bootstraps the app). But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
    - giantrobot 6y ago
      If you're doing an SPA where the HTML is just loading your JavaScript for the meat of your app it's straightforward to verify that file. Besides literally comparing its hash to a known good value there's the Digest header [0] which is a way to provide a resource hash to a client. From the browser side there's the Want-Digest header [1]. These replaced the Content-MD5 header. 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 [2] for signed HTTP messages. So a response can be signed and verified against a public key. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Di... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Wa... [2] https://tools.ietf.org/id/draft-cavage-http-signatures-10.html https://tools.ietf.org/id/draft-cavage-http-signatures-10.ht...

dandanua 6y ago

You assume that the proxy and the search provider follow these rules and do not cooperate in a different way (e.g. the proxy can send a query with an IP). 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).

soperj 6y ago
I don't think it's an assumption in this case because they are the ones running the proxy.

gwbas1c 6y ago

I think there's a lot of confusion over this topic because the general explanation is confusing. "XXX is encrypted in the browser" implies that XXX is encrypted because of TLS. 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."

rasengan 6y ago
You're absolutely right. This is a much better explanation, and we'll improve our language with this advice in mind. Thank you so much for your help and input!

bawolff 6y ago

> If you take a look at the javascript, the query is absolutely encrypted before private.sh can see it. In other words, private.sh cannot see it. 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.

rasengan 6y ago
You can use the private.sh extension [1][2] to ensure that private.sh isn't doing anything fishy. The public key of Gigablast is hardcoded in and the assets are served by a third party. [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...
- jedberg 6y ago
  I still have to trust that Private.sh isn't working with Gigablast to de-anonimize the request.
  - rasengan 6y ago
    That's true. This is the same as Tor in the sense that if multiple parties collude, you can be de-anonymized.
    - e12e 6y ago
      It's different from TOR in that only two parties need to collude, though.
- 6y ago

e12e 6y ago

> 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. 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) .