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.
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.
Agreed that the conclusion is that not all parties want to increase privacy. Thus there is at least one party that does not want to increase privacy. But we already know that google does not want to increase privacy. Thus this does not show that mullvad does not want to increase privacy.
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.
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.
Not sure what this random unknown website has to do with 4chan. It's similar only insofar as both things let you post. Soj requires a sign-up so no anon posting at all, and the community structure is a pretty clear rip-off of Reddit with /p/[sub] instead of /r/[sub]
You edited your comment lol so I’m coming back to answer the new parts:
> As for the main page, you should reconsider your stance on free speech for that specific part of the site since we have a mix of crazy people from p/islam, and crazy MAGA on p/freethinkers. It's not a good advertisement for your site.
We wanted to be sure not to take an opinion on the content - only the form of the technology - so we aren’t touching the All feed.
> No single proxy can see the origins that clients interact with and the clients' original IP address.
Wait, double hop is privacy theater in this case. If you control all the proxy gateways it doesn’t matter if you hop around them.
Even Apple’s privacy is technically more so than this although that’s not saying much. There are two entities in their mix — but a simple collusion between the two entities ends that privacy too.
> A third party that is paid by the first party is not much different from a first party.
This is true from a technical trust perspective, but less true from a legal liability perspective.
If company A sells a product to users with the promise “it will be delivered by company B and we have no knowledge of what you do with it”, and then it turns out there the two companies had an agreement to share data and void that promise, company A is in for a world of hurt when the truth comes out.
Given the small number of people who are aware of and care about this stuff, it would be so much less expensive and less risky to just skip the lies in the first place.
What’s the upside of an elaborate architecture that is all window dressing, which creates a ton of liability, and which fraud likely to be discovered because it’s all written down in code and contracts?
reply