
VPN⁰: A Privacy-Preserving Distributed VPN - jlborxes
https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/
======
sdan
Great idea. Was thinking of doing something like this for a while, but
obviously the drawback is that you're suspect to being the exit node for
someone who's doing something illegal, which is a risk I'm not willing to take
for the sake of privacy.

Obviously you can start a whitelist, but as some other comment said, it's
pretty limited... and I don't want the hassle to add in every domain I go to
(given the number of different blogs posts from different domains that show up
on HN).

For now, I'll be sticking to AlgoVPN because I can't imagine how they'll
protect the safety of users too (maybe a blacklist... although that'd be hard
to given the numerous "bad" websites out there that make you suspect of
further surveillance).

~~~
mirimir
But would you be more OK sharing your AlgoVPN exit? With the same sort of
blacklist/whitelisr approach?

~~~
sdan
Probably. Given that AWS/GCP can't trace back to me then maybe. But at the
same time I'm afraid government surveillance is government surveillance and
petty tactics around hiding your identity to AWS/GCP won't cut it.

~~~
cheez
How do you know that AWS/GCP can't trace it back to you?

~~~
sdan
They probably can as I've (hopefully) implied in my comment. When I sign up
for AWS/GCP for a bit more credits for free, I use a burner phone (if
necessary), burner emails (catchall emails), and a debit card (although GCP
and AWS can detect if you're using one made by privacy.com or DoNotPay... so I
have to call my bank and get one every now and then).

Given this relatively bad information, it's somewhat hard to trace. But as
I've said: Government surveillance is government surveillance. These petty
tactics to get around AWS/GCP won't cut it. Pretty sure they'll call up my
bank using the card details and get my info real fast.

~~~
johntash
Do you still give them your real name and billing address?

~~~
mirimir
My AWS billing address was a largely abandoned factory, not far from Veliky
Novgorod.

------
johnpowell
I refuse to use a browser with a cryptocurrency attached to it.

It feels like the only reason it is being pushed so hard is so BAT holders can
make a buck. It might be a great browser but I will always think of it as
onecoin with a some chrome tossed in.

~~~
safeplanet-fesa
Exactly. I am a big hater of everything that even remotely feels like a
shitcoin. BAT is a silly useless project; I would not hate it if there was no
conflict of interests, even if it's a silly project; but there is a huge
conflict of interest - the developers want to make money out of thin air by
issuing their tokens.

I already wrote this before in another comment. Basic Attention Token is not a
secure cryptographic system. The idea to pay tokens for shown ads cannot be
cryptographically secure. There is no known way to have a cryptographically
strong "Proof-of-Watch". All that browser does is, when a user watches an ad,
it communicates to its backend and asks the backend to send a token to an
address attached to the user. It's not a cryptographic system that mines coins
by showing ads.

It's a useless gimmick that has nothing to do with cryptocurrency. The real
coins are so valuable because they are cryptographically strong. This thing is
centralized and its mechanism of payments for ad views is not
cryptographically strong. The token has some value only because of peoples'
stupidity.

~~~
jonathansampson
There seems to be some confusion here; users aren't paid for watching ads in
Brave. When an ad notification has been delivered, the user is paid. There's a
subtle difference there. Brave (because it is the browser) is able to
determine when an ad has been displayed, better than any JavaScript-based
client that exists today on the Web. Presently, ads are only shown as desktop
notifications (no publisher ads at this time). When the notification is
registered, your end-of-month payout increases.

Judging by your choice of words, I assume you're a proponent of using Bitcoin.
We did this, originally. Unfortunately, Bitcoin was at that time experiencing
serious issues with network congestion and large fees. Our users (who only
with to buy $5 or $10 at a time) would often have to pay nearly as much in
fees. That clearly isn't sustainable. Introducing BAT (on the Ethereum
blockchain) meant we had a faster, more reliable system. It also meant the
creation of the User Growth Pool, a reservoir of 300 million tokens that could
be gifted to early users to raise this novel apparatus off the ground (and it
has been working wonderfully at that).

If there are any questions I can answer for you, I'd be happy to chat further.

~~~
bogomipz
I applaud all of the privacy efforts by Brave so far. Can you say what the
long term business plan is for Brave? At some point you have to monetize it to
make it sustainable. Is this where the crypto coin mentioned here comes into
play? If so will there be an alternative subscription-based model?

------
dimator
The whitelist based approach seems pretty limiting, doesn't it? If every exit
node is expected to enumerate the domains it will carry traffic to, what
happens if a client needs to connect to a new site? Are exit nodes intended to
keep massive, curated whitelists?

Something isn't adding up, to me. If the assumption is that all "good" sites
_can_ be enumerated, then wouldn't Tor (or other systems) exit nodes already
be capable of blocking CP?

Someone connect the dots for me....

~~~
luckylion
The CP, Drug markets etc on Tor is typically on hidden services, not on the
clearweb.

The whitelist approach may work similarly to adblocker lists, where you say "I
trust Jim's List Of Friendly Websites". I don't know how good it is for
performance though.

~~~
sdan
Obviously you can do a block for *.onion. But suppose someone searches up "how
to make a [insert bad thing]" or something else inappropriate on something as
simple as Google. It'd be somewhat hard to block all urls from Google or DDG
that contain some text (not to mention that I've heard that people who are in
this business use acronyms or other slang... which to the general user (like
me) probably won't know.

Don't want to take that risk.

~~~
luckylion
I believe the blocking is done on a domain/host level, so you'd block
google.com in that case. That's likely not required, because google.com is
generally thought to be okay, but you are correct that even that may be
problematic. If your IP has searched for "$governmentBuilding blueprints" and
there's a bomb planted at that building a week later, you could become a
person of interest (provided that Google saves the ip for queries).

Blocking *.onion on the other hand wouldn't be necessary from a "legal
protection" standpoint: hidden services don't see the original IP of the
client.

~~~
swinglock
Google knows IPs are shared and track on L7, they know Tor, NAT, CGNAT. So I'd
wager if you share access to Google via Tor you'd get issues with Google quite
quickly if not logged in and easily L7 traceable, in form of captchas and
blocks everywhere.

------
randaouser
One step further that Ive prototyped is Encrypted and Distributed Search. The
VPN relays willing to take the traffic can also double as Web crawlers. The
vpn clients encrypt their search terms and vpn relays encrypt their search
indexes, and perform ElGamal Homomorphic private set intersection with MINHASH
in Elliptic Curve Field. This leads to better then key word, worse then
current age context search from google but with Strong Elliptic Curve privacy
guarantees.

~~~
bubersson
To make this type of search higher precision&recall you would have to focus
especially on the indexing part (e.g. improve NLU of concepts in the pages),
right? The training of such ML models could be federated across the nodes in a
private way.

~~~
randaouser
Indexing is important for sure. The problem is to preserve privacy and not
falling back to heavy weight general purpose Multi-party computation we have
to give up a bit on the precision and recall of modern search engines.
Minhash, more specifically Locality Sensitive Hashing (LSH) is a good first
approximation (Better then Term Freqency, worse them ML based search). Right
now much of the web is unqueryable, my first goal was to allow the deep web
and TOR services to be searched even at just a rudimentary level.

------
phs318u
Using zero-knowledge proofs to get around the "I don't want to carry <content-
I-dont-like>" barrier to entry of distributed relay tech, is really very
clever. The performance sounds like it might suck though.

------
snagglegaggle
Why not Tor? Providing more bandwidth to that network seems the most
advantageous option. You also get stronger privacy guarantees.

~~~
ViViDboarder
They explain that in the first paragraph or so.

This allows edit nodes to decide what types of content will be routed to their
node.

~~~
snagglegaggle
And opens the network to abuses Tor was meant to protect against. If proof-of-
destination is built into the network then that is a huge step towards
invalidating the main benefit of using a VPN -- you don't want someone (your
local authority) knowing where you've been. Current VPNs sort-of work by not
being in your local jurisdiction. Decentralizing it makes it easier to attack.

~~~
mlyle
It uses zero knowledge proofs, so it doesn't really give anyone on the way
proof-of-destination.

~~~
snagglegaggle
You have proof that someone visited a specific site because it uses a value
derived from that site's SSL cert. You just don't have any more knowledge than
that.

~~~
mlyle
No.. You wouldn't need a ZKP for that.

From the paper:

> Note that such a proof is not straightforward. We firstly prove that a
> ciphertext, CS N I , is the result of an encryption without disclosing the
> public key nor the plaintext. This causes the highest overhead in our
> construction. We use the construction presented in [7] for this purpose.

> Then we need to link the public key encrypted in clause two, with the one
> used in clause one. For this we use a proof that two commitments hide the
> same secret [5].

> Finally the third clause can be openly computed by A given that it received
> the public key from R.

> _Using this, S can convince A that the tunnel created is to a domain that
> the latter considers valid, without disclosing which one._

------
olah_1
>we noted that existing dVPN designs fail to provide strong privacy
guarantees...their decentralized nature requires strong guarantees on the
traffic a dVPN node carries without violating a user's privacy, at any time.

I suggest looking into the Loki project
[https://loki.network/](https://loki.network/)

I'm not completely sure how these two efforts compare, but Lokinet is
essentially a more privacy protecting version of Tor.

------
ackbar03
Is there an open source version or something of this? I had similar ideas and
this is something I would have liked to contribute to.

I was thinking of approaching the white listing problem by whitelisting users,
I. E. I share my node with friends I trust, and that gets propagated through
the network depending on trust levels.

~~~
colordrops
Isn't Brave open source?

------
bArray
This is the sort of feature that could get me using Brave instead of Firefox.
Great job by those guys, I've been wanting something like this for a while
now!

~~~
cbluth
Same here, now I'm interested in brave. I wonder what kind of cool thing
they'll come out with next.

------
mirimir
This is not a new idea. Hola has been around for years.

Trying to protect users through access control is foolish. It's like running a
Tor exit from home.

~~~
dewey
I guess it's a bit different for two reasons:

1) Here users are using the bandwidth and it's not resold to companies like
Hola does is with [https://luminati.io](https://luminati.io). At least for
now.

2) They whitelist domains, so they could only whitelist example.com and you
know it's not like Tor where everything goes or Hola where someone is web
scraping things through your IP.

~~~
mirimir
True, nothing like Luminati, I gather.

But the very idea of sharing my uplink is anathema. Maybe if everyone curated
their own whitelists. But once people rely on whitelists from "trusted" peers,
all bets are off.

A safer alternative would have users sharing access to each others VPN service
connections. That would at least insulate users somewhat from
malicious/illegal traffic routed through them.

Indeed, I routinely route traffic through nested chains of 3-5 VPN services. A
common criticism is the cost of multiple accounts. And I typically have even
more accounts at any given time, for variety.

But if a bunch of people pooled access to their VPN services, or to VPNs that
they ran privately on anonymously leased VPS, each one could have a much
larger variety of VPN paths and exit IPs. And you could multiplex and split
traffic through the VPN network, to increase anonymity. Or aggregate links,
using MPTCP, to increase throughput. And you could even implement something
like Tor's process of switching circuits every 10 minutes.

I bet that I could implement a simple version of that with routing tables and
iptables rules. And some shell scripts. Perhaps with network namespaces, for a
little more security. Even Docker, maybe.

But not just sharing ISP uplinks. That will end in tears.

------
saurik
(I am technically involved in a project called Orchid that would be considered
a direct competitor to this idea, were this idea a product; but I would like
to think my cynicism isn't related to that ;P.)

So, a more complete--and somewhat more balanced--description of this is in the
actual paper, for which this is just a blog post summary; I would think the
paper is way more valuable than this blog post, and maybe should even be the
Hacker News post target.

[https://arxiv.org/abs/1910.00159](https://arxiv.org/abs/1910.00159)

First off, the DHT here is unlikely to scale well to large whitelists; yet,
for small whitelists, you will (of course) end up knowing the target domain to
high probability--which, even for large whitelists, is going to be possible
given just the target IP address almost all of the time anyway: even with a
CDN, the set of websites you get overlapped with tends to not be extremely
large; and, even when it is, it is almost always with a bunch of niche
websites that are unlikely to be on your whitelist--so, the premise that this
is all hiding from the exit node who you are connecting to is extremely weak.

Oh: and when it _does_ even sort of work with the CDN (due to having the
shared endpoint), the user can usually then use domain fronting to trick the
SNI, which would bypass this proof and let you connect to any other website
behind that IP address; so, really, the way they are doing whitelists is just
wrong: the IP address you are connecting to and the totality of what is behind
it is way more important than the SNI. Essentially, while you _can_ do this
(prove, in zero knowledge, the SNI of an HTTPS connection), it doesn't seem
like it really helps a real-world problem (as the situations where the
technique works correlate with situations where you failed to hide anything).

Meanwhile, this paper admits to taking 10-30 seconds _per HTTPS connection_
(not per VPN tunnel!) as the DHT lookups and zero knowledge proofs are both
slow operations. Somehow, before that completes, it sounds like you just get
to use a different node to send "unauthorized traffic"? Why can't I just sit
in that regime forever? I am hoping I just don't understand this part, but
they say it multiple times as if it isn't such a big deal, and have a bunch of
space dedicated to trying to make it sound like the unauthorized traffic would
be a small portion of the total traffic (which doesn't exactly sound
comforting).

And finally, domain whitelists don't work in the first place: I can post
horrible things that get you in trouble to the comments section of a news site
(their best example of a kind of website you might whitelist) quite easily;
and, for their example of Facebook, it is actively dangerous: Facebook is an
entire Internet unto itself that proactively scans for evil things, and so if
you whitelist that you are essentially admitting "I would be willing to let
you do anything". I could see a URL-based whitelist potentially having value,
but not a domain-based one. We shouldn't be making users feel safer with
systems that don't even slightly help :(.

(It is maybe also worth reminding that before the advent of encrypted SNI,
this data could easily have been used to filter and whitelist traffic... and
yet people working on projects like Tor still don't use it for filtering, as
it just isn't enough, as you still don't know what the user is _doing_. It
frankly just feels likely to me that the two goals that people want to
simultaneously achieve here--"I don't know exactly what you are doing" and "I
_do_ know, to some reasonably high certainty, that you aren't doing something
that would harm me"\--are simply philosophically incompatible without some
form of reputation/trust... which then makes achieving a third goal that
people want--"I don't know who you are"\--much harder.)

Regardless, back to the paper itself, I would argue that this is a single
maybe-novel idea--that you can do a zero knowledge proof over the SNI packet
of a TLS 1.3 connection with encrypted SNI--that is, as is common in academic
papers, trying to be described in the context of a full-scale solution by
surrounding it with the minimally-viable wrapper required to turn it into a
product for an under-specified use case and then trying to type quickly past
the serious downsides (such as the latency), all without being extremely
critical of whether the idea itself is useful.

------
spassbold
This idea of a dVPN based on cryptocurrency is not new, see for example
sentinel, mysterium or privatix.

------
buboard
How about sharing blacklists instead? Whitelisting sounds like a performance
bottleneck

------
yalooze
How do you say VPN⁰ out loud? Would be good to clarify that in the opening
paragraph.

~~~
OJFord
'one'

~~~
notduncansmith
Why?

~~~
superkuh
I came here to make this joke. Basically, any number taken to the zeroth power
is 1.

~~~
notduncansmith
Thanks for taking the time to explain!

------
pl3w5y
subscribing to shared lists like we do now with adblock but for exit
capabilties would work very well. I think an auto meshing VPN system like Tinc
or N2N would be better for the network too

------
godelmachine
Does it support OpenVPN?

------
vasanthv
How is it different from Cloudflares 1.1.1.1?

~~~
progval
They have nothing in common. Cloudflare's 1.1.1.1 is a DNS resolver.

~~~
dewey
It's a VPN now: [https://blog.cloudflare.com/1111-warp-better-
vpn/](https://blog.cloudflare.com/1111-warp-better-vpn/)

~~~
kzrdude
It's like a half VPN, [https://blog.cloudflare.com/announcing-warp-
plus/](https://blog.cloudflare.com/announcing-warp-plus/) see "What WARP Is
Not"

