3 ms·

That's very similar to what Tor does. And since both parts are under control of the same actor, it's not very different from, well, not doing it. But too often

by lucb1e 6y ago

That's very similar to what Tor does. And since both parts are under control of the same actor, it's not very different from, well, not doing it. 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!

dwohnitmok 6y ago
> Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage 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.
- lucb1e 6y ago
  I mean, there's a reason we're not commonly doing this: a setup where the relaying and the back-end component are from the same organisation make it fairly useless. You need to find an established partner that wants to work with you to have some claim to not be colluding. And even if so, the front-end can always deliver another piece of javascript that carries off a copy of the plaintext to a server of their own. This setup has some clear disadvantages over Tor. But to repeat what I said before: I shouldn't be too critical when all I'm really saying is "it might not help enough to be worth the effort". If there are no downsides either (well, the effort, but that's up to the dev and consequently the user who pays the dev indirectly) then it's better to do it.
- bawolff 6y ago
  This is not tor like anonoyminity. At best this is like vpn-level anonoyminity.
rasengan 6y ago
> And since both parts are under control of the same actor, it's not very different from, well, not doing it. 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!
- lucb1e 6y ago
  > Both parts are not in control of the same entity. 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!
  - rasengan 6y ago
    > 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!
    - 6y ago

by lucb1e 6y ago

dwohnitmok 6y ago

> Having tor-like anonymity without needing to use a special browser and slow network is definitely an advantage 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.

lucb1e 6y ago
I mean, there's a reason we're not commonly doing this: a setup where the relaying and the back-end component are from the same organisation make it fairly useless. You need to find an established partner that wants to work with you to have some claim to not be colluding. And even if so, the front-end can always deliver another piece of javascript that carries off a copy of the plaintext to a server of their own. This setup has some clear disadvantages over Tor. But to repeat what I said before: I shouldn't be too critical when all I'm really saying is "it might not help enough to be worth the effort". If there are no downsides either (well, the effort, but that's up to the dev and consequently the user who pays the dev indirectly) then it's better to do it.
bawolff 6y ago
This is not tor like anonoyminity. At best this is like vpn-level anonoyminity.

rasengan 6y ago

> And since both parts are under control of the same actor, it's not very different from, well, not doing it. 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!

lucb1e 6y ago
> Both parts are not in control of the same entity. 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!
- rasengan 6y ago
  > 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!
  - 6y ago