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.
Unfortunately, the ad-system that has become infested with malicious tracking and more is also a means by which creators across the Web find support. This is why Brave introduced the Brave Rewards component. So that we can create not only a safer Web, but a sustainable Web.
Opting-in to Brave Rewards means you're able to earn tokens for your attention. By default, these tokens are then donated to the sites and properties you visit throughout the month. The more you visit a property, the higher their end-of-month contribution will be.
All of this works without violating your privacy, thanks to on-device matching of ads and machine-learning. The token integration is a minimal component, but with a massive impact on the long-term sustainability of the Web. I'm happy to answer any other questions you may have.
All the best!
I could use cURL to perform all web browsing, but my IP Address + User Agent could still be tracked by the website I visit.
With time, what seems to be occurring is a game of cat-and-mouse where trackers develop more powerful heuristics for creating fingerprints.
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.
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.
* BAT is a non-financial utility token, not a currency.
* The Brave Referral Program specifically prohibited participants from making statements that BAT is a currency, a store of value, or an investment.
Examples of real-world non-financial utility tokens are amusement-park ride tickets and beer-garden food-and-drink tickets.
It should also be noted that the law determines what qualifies as a currency, not the issuer. If it looks like a duck, quacks like a duck - you know the rest.
In something like Lokinet, the whole thing is distributed and the people that run the service nodes get rewarded with coins. But normal end users don't have to think about the coin at all.
The optional rewards program that happens to use a distributed ledger for settlement?
Lets see how that sounds when it is rephrased
“I refuse to use an airline with a rewards program attached to it”
“I refuse to use a credit card with a rewards program attached to it”
But since nobody says that, you lose your mind when a blockchain based one is used? Which is also as entirely optional as the above programs? Which you use as an ad hominem attack to add non-sequiturs to any contribution under the “Brave” brand such as this ZK VPN system which doesn't even use the digital currency? Fascinating, lets revisit this “taboo” next year to see!
“I refuse to use a credit card with a digital currency attached to it”
But since nobody says that, you lose your mind when a blockchain based one is used? Which is also as entirely optional as the above programs? Which you use as an ad hominem attack to add non-sequiturs to any contribution under the “Brave” brand such as this ZK VPN system which doesn't even use the digital currency? Fascinating, lets revisit this “taboo” next year to see if it is one at all!
This allows edit nodes to decide what types of content will be routed to their node.
Trying to protect users through access control is foolish. It's like running a Tor exit from home.
1) Here users are using the bandwidth and it's not resold to companies like Hola does is with 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.
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.
That's not a bad idea, actually. Who maintains those whitelists and how do they get updated? If you want to make the web somewhat usable for others, is it enough to whitelist "google.com"/"youtube.com" only (for example)?
As far as I remember, in France, you can get the same status as an ISP (don't remember the name though) to be able to run an exit node without being held responsible. But you will have to respect certain rules.
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....
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.
Don't want to take that risk.
They can't do this to onion services
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).
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.
I suggest looking into the Loki project https://loki.network/
I'm not completely sure how these two efforts compare, but Lokinet is essentially a more privacy protecting version of Tor.
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
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.
