Hacker News Reader

Comment by rasengan | Hacker News Reader

This isn't really privacy or security focused unless 'trust' is a component of security architecture.

Make no mistake, Mullvad Leta knows what you searched for and who you are.

/Theater/ has no place in privacy.

The right way to do it, short of FHE, is to encrypt the query client side, pass this to the proxy which does not pass the source IP, which passes this to the search engine for decryption. Search results are encrypted and pass thru in the reverse:

Client (encrypts) -> Proxy (passes thru no IP) -> Search engine (receives, decrypts, performs, and encrypts results) -> Proxy passes encrypted blob of results back to user -> Client privately reviews private search results.

Edit: private.sh tried this in the past but unfortunately was shuttered with the end of gigablast.

View on HN

Mullvad has built trust over many years. There is always someone who knows what you are searching for. The search engine will not accept an opaque blob of encrypted data as a search term, after all.

The trust comes from them being a small player. The moment they get big, govt will come knocking, and they'll be just like anyone else.

The govt already knocked and Mullvad had nothing to give them.

Because it is small. When you get big, laws get written targeted at you.

If the encryption library is loaded over the web, then it provides no added security. You are still trusting them. Web client side encryption is theater.

Agreed, it requires something more significant like an auditable (non obfuscated code) extension or better.

This is a bit of an aside, but I see this take a lot and I think it's subtly wrong.

Web client side encryption eliminates fully passive snooping on the server side, but of course does nothing for actively subverting the served encryption code. This makes things a bit more dangerous for the snooping party as it's possible that the backdoored encryption code will be noticed by someone, and it's at least possibly a legal defense - the government might have the power to compel you to hand over data on your server but not to backdoor your code.

This isn't a huge technical difference, but it is a difference, and especially with the legal angle I think it's an important one.

What if browsers supported a property like <script hash=64192876> ? They would store the hash on first connection then verify on subsequent ones.

I know this should be refined and hardened but you get the idea.

I'd rather have some people in Sweden know what I've searched for than whatever I'd find abroad.

Reply on news.ycombinator.com