Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Brendan Eich: Brave – Reinventing the Monetization of Content and Attention

Episode Date: May 30, 2017

The saying goes: if you’re not paying for it, it’s likely that you’re the product. And with the rise of targeted ads, user behavior tracking, and alike, more and more users are turning to ad blocking software to protect their privacy and improve their browsing experience. In the last 25 years, the content monetization and Internet advertising industries have evolved to become complex ecosystems with multiple intermediating layers between users, publishers, and advertisers. This has created a situation where user’s rights are constantly violated and where little accountability exists. We’re joined by Brendan Eich, Founder, and CEO of Brave. As an early Internet pioneer, Brendan created Javascript while working at Netscape in the mid 90’s, and helped found the Mozilla Foundation and Mozilla Corporation, where he served as CEO for several years. Brave is a new desktop and mobile browser which blocks ads and tracking by default. This has the advantage of drastically improves page load times while protecting users’ privacy. But Brave is much more than just a browser. Their team will launch the Basic Attention Token, which will serve as the currency of attention marketplaces between publishers, advertisers, and users. With the ambition to turn the Internet advertising industry on its head, this new attention economy marketplace will eliminate the need for unneeded intermediaries, provide publishers with new content monetization models and remunerate users when they chose to share their data with advertisers. Topics covered in this episode: Brendan’s background as an early Internet pioneer How monetization of content and attention on the Internet are broken How the Internet advertising industry works and the players involved A high-level overview of the Brave browser Brave’s features and product roadmap The Basic Attention Token and its role as a currency for attention How BAT will serve to create attention marketplaces between publishers, advertisers, and users Episode links: Brave Website Basic Attention Token This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/185

This is Epicenter, Episode 185 with guest, Brendan Ike. This episode of Epicenter is brought you by the Ledger NanoS, the hardware wallet which sets the new standard in security and usability. Get it today at LeisureWallet.com and use the offer code Epicenter to get 10% off your order. Hi, welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sibbasingwikw. And I'm Meher Roy.

Today we have an amazing distinguished guest on our show, Brendan I. Who is the inventor of JavaScript, founder of the Mozilla project, the Mozilla Foundation, Mozilla Cooperation. He's now working on Brave, which is a browser that is seeking to remake the digital advertising industry. Brendan, it's an honor to have you on the show. It's my pleasure. Good to be here.

So I thought to get started, maybe just tell us a bit about your work history as an early internet pioneer. Like, tell us about your journey in the past 20 years. Where to start. So I worked on the internet in the 80s for Silicon Graphics. I worked as a Unix kernel hacker on SGI's version of Unix called Irix. I did file system and networking kernel code. And I knew all about the IP protocol stack then. I wrote a network sniffer, sort of like a packet filter,

and some code on top of that to capture and analyze packets, let you sort of express filters over the header fields of those packets, so you can capture only some of the packets. That was a lot of fun, and that was one of the many little language projects I did that paved away ever since I got into computer science as a physics major, erstwhile, as an undergrad. So I was doing computer science from the formal languages

and automata theory side, and I love that because it was very clean, right? You can generate parsers from grammars, things like that, studying regular languages. So I had experience that when I got to Netscape, I'll skip the company between Silicon Graphics and Netscape. When I got to Netscape in the second year, the temptation from my friends who were there

and had been at Silicon Graphics before that was come and do scheme in the browser. And they loved the scheme programming language, the Guy Steele and Jerry Sussman's sort of version of LISP with lexical scope, very clean LISP variant. And it was just a pipe dream to put it in Netscape because by the time I hired, there was a deal brewing with Sun Microsystems to put Java in Netscape

and, you know, take on Windows. like Mark Andreessen would say NetsK plus Java kills Windows. So I had suddenly, first of all, the concern that maybe we don't need another language, maybe Java's enough. But Mark believes in the idea of a scripting language, a simple language, right in the HTML. And so he and I collaborated on some of the ideas and constraints on that language. One of them was it had to look like Java. Another was I had to do a prototype in 10 days to prove to everybody else that was worth having

this novel idea because Java was not easy to use in particular. It was a type language and you had to run a compiler and package up the bytecode. And so I did the demo and it got out of the lab and it spread all over the web. That was 1995 May 22 years ago. The web was quite different then, but Netscape had made it commercially viable with secure sockets layer, the H-DPS URL scheme, we now call TLS, which is quite different. And URLs were on billboards.

Suddenly, everybody was moving on to the web in the dot-com era. JavaScript was sort of a source of annoyances at first because it was directly integrated with the page so you could do things like pop-up windows and status bar, scrolling messages and things like that. But it was also even in 95 used to build what we can now call single-page application. for doing sort of, instead of a series of pages you load,

it was like a set of frames or windows that kind of update themselves constantly based on data from the server. So that vision was there from the beginning, and it really came to fruition 10 years later. In 2005, you remember when Twitter was founded, and Ruby on Rails was big, and the Ajax term was coined by Jesse James Garrett.

And that was just more efficiently, of doing this single-page application idea where the data comes from the server continuously. And JavaScript was the key language for making that possible. Flash was also in the mix, but Flash is all but dead, thanks to Steve Jobs, banning it from iOS and Android following suit. So in doing JavaScript, I realized it was going to be kind of a long shot, but if I got it done fast, It would prevent Microsoft, who was coming after Netscape, from foisting Visual Basic Script on us. So I like to say JavaScript saved us from Visual Basic Script.

And it got better. JavaScript had a good first standard. Microsoft actually contributed one of the people at Microsoft in particular. Sean Katzenberger contributed to that standard. And it evolved a little bit through the third edition in 1999. And then Microsoft felt, oh, the web is too hard. we got it convicted of using our monopoly in an antitrust case, the U.S. versus Microsoft case, where they crush Netscape. Poor us, let's go back to go to the old Windows lock-in, and they took Internet Explorer down to a skeleton crew.

And meanwhile, after standardizing JavaScript, I had founded with others, Jamie Zewinsky and many others, a lot of whom departed quickly, the Mozilla project. And we were trying to make a sort of escape pod, like in Star Wars, that carried the droids to the planets. You could have a fourth episode. This was to get Mozilla's Netscape's code out as an open-source browser engine and browser front-end. And when we finally did that, it took years. We were also running out of rope at AOL, which had acquired Netscape. So in 2003, we spun Mozilla out as a nonprofit.

It had not been a separate legal entity before that. It had just been a virtual group with most of the people working for Netscape AOL. And in some ways, fighting against Netscape AOL because we were trying to have an open-source code culture that was high-quality and not corporate and not badged with AOL and ICQ and ALE and all these things you might remember from that era. And so Mazzola got better over the years, but Netscape wasn't in the good graces of AOL. And finally, everyone got laid off in 2003. accept some of us who then were set up with a foundation. So AOL had a sort of a clean ending to the story. They gave us $2 million over two years. I picked a handful of people to do the technical work. We set up a 10-person shop and we did Firefox. We knew we had to do Firefox.

We knew it had to be a browser. If you remember, Netscape in the 90s was a suite of communication tools, a browser, an email program, a newsreader, an address book, and an editor. We said, let's just make the browser great. And we also had Thunderbird as the mail program, but we separated concerns. We made each app do one thing well. We had an extension model, which has now become common among all the browsers. Though the APIs differ, there's some now convergence around Chrome's extension model. But at the time, we were the first, and we did a very rich extension model for Firefox for add-on, so-called. And Firefox retook market share from Microsoft. This was unheard of, right? People said the browser is dead. The browser wars are over. No one will

ever get any market share away from an Internet Explorer because it's bundled with Windows. And yet, because Microsoft had taken it down to a skeleton crew and sort of forsworn it and tried to go back to Windows-only technologies.net and so on, Windows Vista stuff, there was an opportunity, and we knew there was an opportunity because users were suffering. They had Internet Explorer with ActiveX-based malware, pop-ups were not blocked by default. There were lots of problems. It was considered slow because it would get congested with malware, and it wasn't being maintained, so it definitely was slow with the newer kinds of web content that were still

emerging, even in the 2003-4 era. So Firefox really did restart the browser market, and that allowed us to restart the web standards process, because that also shut down when Microsoft monopolized the web and sort of stopped working on the browser on IE. There was a sort of conflict in the W3C because people who were enthusiastic about XML and the semantic web thought, well, this is our chance to clean up that messy 90s HTML nonsense. We're going to just rewrite the web as XML, and everyone will run a syntax checker and make sure, it's perfect before they deploy their code. Never happened. It wasn't going to happen.

So we knew that. And with friends at Opera and Apple, we set up the What Working Group to do HTML5. We said, let's do HTML5. It's been a while since HTML4, which was 97, I think. Microsoft really invested in an HTML4 and did well. It's part of their Kill Natscape plan. But they, you know, they did some good stuff. Let's do HTML5. And that finally happened, even got back into the W3C in 2008 or so. We also at Firefox had a search deal with Google, so we were partnered nicely and making good money off that deal at first. But I think over time it became clear that Google could do its own browser, and they did. And that was Chrome.

Safari was out, I think 2003, based on an open source engine called KHtml. They eventually forked that as WebKit. In some ways, they wanted to make a mini-Mozilla that was an open-source project for it. WebKit became popular, and the Google folks used that for Chrome's engine, eventually forked it in 2013. So you can see there sort of, once we restarted the browser market, innovation came back, and there were successive waves of forking and building new browsers. And that never stopped.

People now kind of say, oh, Chrome's, you know, the new King browser, and how can you ever do anything about that? But Chrome is not going to reach the 95% share that I, did. It's also, you know, it's not blocking ads by default because I think that goes against Google's business interests directly. So with Brave, I wanted to take on a problem that bothers me personally, and I know a lot of people agree. It's not just the ads, it's the trackers which we block. It's the fingerprinting methods, which are very subtle, but the common ones can be blocked too. We're trying to defend your data on your device because it belongs to you first. And if you're not getting paid for

then you're the chump, right? In the poker game, you look around the table if you can't spot the chump, it's you. If you're getting a free service, you're giving out a lot of data and someone's making a lot of money off it. This led pretty directly to Bitcoin and to cryptocurrencies.

Because if you're, you know, money isn't everything. It's not the measure of all things. But if you're not valued enough to get a share of the revenue, for instance, for ads that you see, then something's wrong. And if you are to get a share of that, it has to be frictionless. It has to be as low cost as possible.

And there are nice things about cryptocurrencies like multi-signature wallets. There are things coming to cryptocurrency blockchains like anonymity and lower transaction costs. And so it's attractive if you're going to solve this user data problem where users are not paid for their attention properly. and you have a new browser that can clear the deck of ads to use cryptocurrencies. You just took me back throughout my entire teenage years there from, you know, like the, because I started coding, I started doing web development, you know, when I was about 12, which would have been around like 97. And, you know, going back and like, I mean, we kind of take web standards for granted now,

although there are still a lot of things that can be done to improve web standards, but when you look back just that, you know, the things you mentioned, like Flash that were competing with Java and like this little period there with XHTML or whatever that was. Yes. Yeah, it's incredible, you know, this progression that has taken us here where, you know, even I remember what, like seven or eight years ago, you know, back in the IE6 days, you know, web standard,

we were just praying for web standards. And now, you know, now they're pretty much here with regards to how browsers, browsers interpret HTML and CSS. Of course, like the stacks have got more complex now, you know, with with SaaS and these sort of layers on top, these pre-compilers, but it feels now like web standards are pretty, pretty solid right, across the board,

at least from where I'm standing now. I'm not doing as much development as I was prior, but it does feel like we've gotten to a point now where browser manufacturers, at least on that side, are agreeing on what standards should be, what standards should adhere to, et cetera. It's better. I mean, web standards take too long.

I'm used to this because I still work on them. I was just at a JavaScript standards meeting hosted by Google in New York this week. But the web is slower to evolve, and it's going to not have all the shiniest features that the latest iOS release has necessarily. On the other hand, the web has the greatest reach. There's just no way to get around that.

This is a trade-off. And so I think it's incumbent on browser vendors to keep rolling up all the great new innovations from the device makers or the OS vendors into the web standards. And there have been pauses there for sure due to monopolies and sort of conflicts of interest, business interests between the browser

and the other business that pays the browser vendor vendors, you know, bills. So my goal still with web standards is to just keep people working together in a harmonious way so that we roll up these innovations. The web will never be, you know, like better than iOS or better than the latest Android in one particular dimension or other, but it'll have the widest reach. And if you can roll up all the common innovations, it'll be good enough. That's the web. What you're saying they're so telling because when you say that the, the web has more reach and it takes longer to get to standards.

If you look at the last, what the iPhone came out in 2007, there was, I remember at that time, it was believed that any user interface would be an app, basically, you know, that you would build an app rather than a mobile website. And that, I mean, it hasn't totally shifted, but, you know, we're seeing the web now on mobile become, sort of regain its place as one of the dominant ways by which people access information. That's greatly due to web standards, I think. Yeah, it's funny. When the iPhone first launched, Jobs held up the iPhone 1 and said the web finally works on a phone.

And they didn't have the App Store model. They did that like eight or nine months later. And I think they did it because of games. Games wanted to have a native SDK. They wanted to use C++ and run it down to the metal. And so they made the App Store possible, and they made the app model possible. And then the next year, I think it was 2008, there's an app for that, right? And certainly you could do well by jumping in on that new frontier.

I remember Evernote, which had been a PC app, suddenly became an iOS app, and that was really good for them. They lowercase the N in their name. But you're right, the pendulum sort of swings. If the web is competent enough, people don't want to install yet another app. All the kids these days are uninstalling apps. There's sort of an equilibrium, depending on screen size and the competence of the web standards, between getting another app and just using the mobile website. And if that equilibrium, you know, is stable, I think the web endures.

We're seeing a lot of native apps now being developed with web standards, right? I mean, if you look at what is it called, not Electrum, but this platform with which you can build React Native is an example. You use JavaScript for the business logic of the app, but you compile to native widgets. There's still a sort of interplay, co-evolution between native and web, as there should be, because that's what drives, I think, standards innovation. The standards bodies, if they go off and try to innovate on their own, it's usually a disaster, right? It's like that XHtml that never happened. I think Electron was what I was referring to, and Ionic and all these platforms. We could I spend two hours talking about this, but I think we'll, because I'm super excited about all this stuff,

but I think we'll move on to the core of the discussion today, which is brave and sort of monetization on the internet and how Brave is planning to prove that. So let's take a few minutes before we get into Brave and the further topics. Explain how you feel today as it stands in 2017. When you look at the state of monetization on the internet, the way that companies monetize content, the options available for companies to monetize content. I mean, we monetize our content in one way, which is to embed adds directly into the content that we negotiate with advertisers.

But, you know, there's all kinds of other models. Explain, in your view, sort of what's broken, what might work, or what is the, so the, the core problem with monetization on the internet today. So there's been a lot of talk about the cost of fraud in ad tech or online digital advertising, and I don't think it's a surprise that it's there because the system evolved pretty haphazardly, opportunistically. The cross-site image actually came in 1993 from Mark Andreas and Eric Bina when, before Netscape, they were at NCSA University of Illinois, Urbana-Champaign, and Mark just does his typical post saying,

hey, we should probably add images to HTML, here's how we want to do it. think at that point, Eric Bean had already written the code, so it was a done deal. And with an image in HTML in 93, you could hotlink, right? You could make the image source be a different domain from the page the image was embedded in. You know, your friend has cat pictures. You want to link to them from your site. It's all good. It was called hot linking because if 10,000 people did it, could melt your friend's server. Not so good. And some sites discourage this, but that's just part of the web now. You can load images cross sites. One of the reasons when I did JavaScript And in 96, I made the script source-equal attribute work.

I made cross-site scripting possible on the same principle. You should be able to share scripts, have them on a common edge cache. They could be like library code. There's security implications. I'm not going to get into them. But, you know, we've sort of evolved our way to understanding of how to deal with that securely. Cross-site scripting is still a problem. In between images and cross-site scripts was the cookie.

Lou Montulli at NetSafe in 1994, NetSafe 1. And the cookie was there. So when you logged into a website over the stateless HTTP protocol, if you went back or if you restarted your browser or closed your window and reopened it and it remembered the page you were on, you didn't have to log in again because after all, the protocol stateless, the site wouldn't remember anything about you without a cookie. So Lou came up with this idea of a little bit of storage, local storage to the browser, indexed by the name of the domain, sent on every request, and the server can respond with

an update to that cookie in the response in a header. And so you can keep login information, like authentication credentials that are fresh, cache that way. Great idea. Don't want to log in every time I go back. Unfortunately, just between the cross-side image and the cookie, third-party cookies were accidentally invented and became a tracking. mechanism. Because if you think about the cookie, it's sent on every request. Well, what's a third party request? It's that embedded cat picture that's on your friend's server. It goes to a different domain. If that cat picture is embedded on two sites, the cat server can now see through the cookie that you went to both sites. It can give you an identifier, just a made-up number when it sees you

on the first site. You go to the second site, because the cookies indexed by the cat server's domain, it sees the first value in the cookie and it says, hey, I know that a user already. I have a database that says they loaded my cat picture embedded within a larger page. You can tell what you're embedded in. Generally, there's ways to do it like the way the cat picture is spelled.

So in the second page it embeds the cat picture, now they know you've been there too. They can surveil you. They can build a dossier on you. This is used for behavioral targeted advertising, online behavioral advertising. it's pretty out of hand, frankly, and this is one of the reasons why there's fraud in the system.

There's also a lot of sort of conflicts and arbitrage games played that have to do with the data that's tracked this way. So when people go to make money with ads, they have this model as publishers that's sort of like the old days of newspapers, ink-on-paper ads. I'm going to give up from space. Maybe I can even have some editorial control, so the ad is nicely matched to the first-party content.

but what inevitably happens, even with big publishers, is they can't do direct deals with the brands, the best brands. They have to go through ad exchange. You have to go through what's called programmatic advertising, which really just means automated advertising. It's a matchmaking process because there are too many websites and, frankly, too many advertisers to have direct deals all the time negotiated between every pair of advertiser and publisher. So the ad exchange has evolved. The programmatic evolved since 2009 in particular, and we've got a world now with incredible indirection and sort of accidental delegation. There's no strictly binding contract between the publisher and the actual ad provider who gets a match, wins a bid in a real-time bidding process. And that's

why you can have malware placed on top sites, like happened last March, in New York Times, BBC Online, AOL, all had the Angler Exploitkit ransomware sneak into their programmatic ad supply. And it wasn't something where the New York Times could say, those are my ads, I'm responsible for, they didn't want the liability. Of course, it was accident. It only was through an ad exchange. The ad exchange took a fee when that malware placed. So what does it know?

It's happy, got a fee. It wasn't its fault. You know, the malware vendors are tricky. They set up fake ad agencies. They set up fake LinkedIn profiles for the CMO of their ad agency. They really try to pull one over. So, you know, no one knew any better. It's not our fault.

Too bad. Some users got their PCs poned by ransomware. That's just one of the worst case effects here. But the other side of it is you get real ads that are placed in fake sites in order to, and these fake sites are very convincing. And their ads are clicked on by fake users to steal ad revenue. So the legitimate marketers say, hey, my ad. My video ads really popular on these sites, and it looks like real users are clicking on them.

My anti-fraud pixels that I ship, my scripts that I ship to make sure those are real users are satisfied. They have the right IP address. It looks like it belongs to a Verizon South ISP in the U.S. Well, it turns out the bad guys here went to some Internet service provider and said, I need a block of residential IP addresses. I'm with Verizon South, and they spelled it V-E-R-I-S-O-N. And nobody noticed it wasn't. Verizon with a Z, and they assigned the IP numbers, and they were used by a fraudulent robot

browser against a fraudulent publisher page that embedded a real ad, and the advertiser actually paid. Like 30 days later, they said, I like those impressions. It looks good to me. I'm going to pay you. Three to five million a day, according to a white paper that White Ops security did on this particular attack called MethBot. So you get fraud and you get malware.

You get incredible, like nobody's to blame. It's seven degrees of Kevin Bacon, you know, who knew, not our fault. And that is wasting billions of dollars a year. They estimate this year $16 billion in fraud. Not to mention the bang with costs. Oh, I could tell you. Yeah. Just to put a point on that, there's a study from the New York Times that our friend Rob Leather

now at Facebook picked up on, you spend half your data plan costs. loading trackers and ads. Not just the ads you see, but the tracking scripts and the programmatic scripts that load before them. You're not getting free internet. The ads are not part of the value exchange. You're actually getting it coming and going. Your data plan, half of it's wasted on tracking

and scripts and ads. And then because they take your data out, they make money on you on the backside too. Let's take a break to talk about the Ledger NanoS, the new flagship hardware wallet by Ledger. I'll let Ledger's CEO, Eric Larchavec, tell you all about how simple the nano-s makes it to securely store all your private keys. The ledger nano-s is our latest generation hardware wallet.

This is a multi-currency hardware wallet. It has a screen and buttons to manage everything on screen. You can generate a new seed, restore a seed, or set up your pin on the device. Your seed will never be exposed to the host computer. On the nano-s, you have different apps. You have the Bitcoin app. You have the Ethereum. app and you have the Fido U2F app for strong authentication for instance with Google Dropbox or GitHub.

You can manage your cryptocurrencies with the ledger wallet Bitcoin Chrome app or the ledger wallet Ethereum Chrome app. With the nanoS, all your Bitcoin and Ethereum addresses are derived from one unique seed. With one seed you can have in the same time Bitcoin, Ethereum, ECUM classic balances and Also, if you restore your seed, you will also recover all the keys associated to other apps such as FidoU2F, SSH, GPG. So it's very simple, just one seed and multiple applications. The NanoS sets the new standard in hardware wallet security and usability. You can get yours today at ledgerwallat.com.

And when you do, be sure to use the offer code Epicenter to get 10% off your first order. We'd like to thank Ledger for their support of Epicenter. So what do you think could have been, I mean, because you've been around the internet for a while, needless to say, what do you think could have been done differently maybe in the beginning, apart from like not inventing cookies and cross-side scripting? What happened differently for us to have sort of a more, you know, privacy respecting internet today? Can you point it to like specific things that say, oh, this was kind of a thing like bad idea? I could. You know, the 2020 hindsight, and there are people I know who have a very, strong security philosophy, like I'm friends with people who are object capability security pioneers. And their system is attractive. And if people use it with discipline and care and with some

tools to verify it, it can be very, very powerful. I like it. I'm technically on board with object capability security. And JavaScript has some of that in its bones, has a few loopholes that are notoriously not object capability security. But the plain fact is, I don't want to play Monday morning quarterback. The web would not have evolved without this rush to commercialize it, without these unintended consequences. Like nobody thought, hey, images plus first party cookies equals third party cookies, equals tracking. Nobody figured that out in time. It was unintended consequence. It was accidental evolution, very much like sort of biological life. And if you had a do-over and you tried to control the change and make it slow and careful, it wouldn't have taken off. Like Dorothy Denning,

a famous security researcher, I've forgiven her for her clipper chip support, invented information flow of security in the 70s. She gave a speech in 99 or 2000 where she said, you know, security will never be done. For one thing, it's an economic scarcity problem. Bad guys attack where you aren't defending. You go there to defend and they attack the other place. You left behind that you didn't have the money to defend. But she said also people rush to commercialize things and they never will design, you know,

some platonic ideal of security by construction. They will dive in and commercialize. And that's what happened with Netscape and the United States. the web. So to me, the job, again, is sort of this diligent standards process of iteratively improving the standards based on what we learn. And that stopped. For advertising, in particular, that stopped. The cookie and image and script were the low-level building blocks. No one ever made an ad element in HTML, like a tag for advertising. No one made a first-class tracker tag. You know, there's lots of always track you, so maybe this wouldn't have been bulletproof,

but it would have formalized it in a way that would have allowed more accessible. explicit user control of these things. And, you know, ads are recognizable. We block them. Others block them. But it's kind of a heuristic process based on domain names and sort of syntax patterns. Yeah. So you've really sketched out what the problem with today's exchange, like today's ad market.

And it seems that it's a problem that affects everyone from the person who's reading, malware, the person who's publishing, not being able to get accurate. value for their money and it seems that all of the parties have had this problem. So, like, just catch out a vision for how you think the future could be different and how, like, brave would want the future to be. Sure. So one of the consequences of this accidental evolved system is too many middle middlemen. This is what you see in the way ads are delegated through exchanges. You get alphabet soup of acronyms, the demand side, the DSP, the supply side platform, the SSP, the data management platform, the DMP, there's a lot of P's,

you get private marketplaces, PMPs, you get, you know, optimization specialists who claim to add a little bit of yield, a little bit more revenue per unit of area that the publisher gives up. And at the end of the day, they may not deliver, but the publishers are not technically the smartest always. They're often beholden to their vendors and they're always chasing yield that is better revenue for, you know, an area. And they get a horn swaddle. They get stuck. They marry last year's vendor. Then if they get out of that marriage, they leave the integration behind. And it all piles up into a big, slow mess. Like we see, like media sites with 70 calls out when you try to load the page. Some of these never finished loading on mobile. I mentioned Rob Leatherin's piece based on New York

time study of half your data plan, $23 a month, is covering the cost of all these signaling scripts and tracking scripts and the ads finally when they come, if they come. It's actually worse than that because when you get into this programmatic world, now you're seeing people having multiple what are called header bidders, different sort of tags early in the page racing to measure the user and find the best ads, the best winning bid. And this is just clogging your network. It's costing you data plan. It's meaning pages never finish loading on mobile.

And people abandon pages on mobile. So what we think is a better world cuts out the middle players. When you have this system, it's already happening. A lot of these middle players are going out of business or they're rushing to be acquired by IT companies like Oracle, CRM companies like Salesforce. You're seeing consolidation in the industry and M&A action as venture-funded startups in ad tech, which is out of favor with venture, for sure,

are now trying to find a buyer. And there's too many of them, so it has to shake out. A more efficient system, just as an engineer looking at, it could be done. And in fact, Brave proposes a more efficient approach where instead of all the middle players that take 55% of the revenue, and that's on a good day, sometimes they take 60%, sometimes they put back fraud costs on the publishers, the publishers making 25 cents on the dollar gross ad spend. Take out all those middle players

and replace them with the browser, the user agent, putting the user's data where it already has to be on your device, not taking it out and surveilling it. Doing the ad matching in kind of an inverted sense,

take a catalog or manifest of ad URLs and tags or keywords, segment identifiers for each ad. Think of it as a table with an ad URL and a bunch of keywords for each ad. That's a table that can be loaded,

it can be compressed, it can be differentially updated efficiently. It's different for each region and language in the world anyway. Ad deals don't roll out every millisecond. The brave model is to use that downloaded ad catalog to match your intent measured locally using machine learning that only runs on your device, using your data that's kept in the clear only on your device. We don't see it in our servers. Find the best ad at the right time. And don't jam it into a publisher slot.

put it in a user private slot. This is how quality advertising works on other media. This is how, you know, time-shifted television can still do good ads. Joe Marchesey at Truex, now at Fox, talks about this a lot. Ads, shotgunning your attention, trying to hit you at a website, the ads for the thing you just bought on Amazon that now retarget you after you have checked out, when you don't want to buy it again for a week or a month or a year, that's nonsense, right? Find the right, in the right place for the right beautiful ad, maybe even a long form ad, put it in a user private slot, share revenue with the user. That's a key point with Brave, so that the user's is getting the lion's share if it's in a user private slot. And we'll partner with publishers

who want us as an alternative to their indirect ads because by baseline behavior, Brave is just a blocker. That's the default. We're not going to ever insert ads by surprise. So if users opt-in, we'd be happy to partner with publishers who want a better third-party ad vendor because we can do it all on device and privately. I mentioned how the private matching works, but the other side of it is when ads are viewed or if there's an action-based model, cost-per-action model, you have to attribute the action. You have to have a confirmation signal. This, too, is done with nasty tracking scripts and tracking pixels and anti-fraud pixels and analytics pixels in today's world. We propose using zero-knowledge-proof protocol. We already have this prototyped and brave so that there's no

user identifier, but there's an authentic attestation of an impression. And the only value of the impression is in the aggregate, millions of impressions across an ad campaign where the user identifier doesn't matter unless somebody's running a data rating business on the side. So we think we can build a better world with private matching, zero knowledge proof for confirmation, ultimately move it onto the blockchain, as the blockchain, and there are several blockchains working on this, innovates to absorb anonymity through zero knowledge proof protocols and, you know, find in transaction scale, so there's not a big fee. So the brave vision appears to be like build a default browser that doesn't have ads, right?

And then give an opt-in option to the user that they could opt in and actually see ads. When they see these ads, these users get monetarily compensated for opting into this option. So that incentivizes them to switch from the non-ad version to the ad version if they so-worn. And in this particular ad version, Brave is developing the tool sets to monitor user attention anonymously and also serve as an ad exchange. In some ways, yes, it's such an unusual model because ad exchanges today, the advertiser puts in the size of the ad and some keywords around the ad and some restrictions. And then the supply side, that's the publisher who's supplying the ad slot puts in its dimensions for the ad slot and its constraints on keywords or segmented

firefighters. And the matchmaking process also tries to optimize, you know, the price, the bid versus the ass, because the marketer is buying the ad slot and the publishers making money after all the middle players have taken their slices out of the pie. Sometimes there's not much left in the pie tin. We want to have a much more efficient system, but we still see the money coming in from the so-called demand side, the advertising side, $72 billion last year on digital ads in the U.S., that's not going away. It crossed over television and ad spending this year.

We don't think ads can be counted out. Now, we do offer in Brave, and we continue to plan to offer the ability to anonymously donate to your top sites, even pin a donation irrespective of your browsing, so you can always give 10% of your monthly budget, which is a voluntary budget you set, anonymously to your top sites.

We don't see the list of sites. We again use zero knowledge protocols. So we think donations could matter. We just can't count on them replacing ad revenue. Suppose Brave got to 100 million users. Would enough of those users donate to make up for our baseline blocking? Probably not. I'd like that world to be true.

I just can't count on it, given the dynamics of the web, how people have been conditioned to expect free content. But when you have a micro paywall in the browser, which is what we've built, and it's anonymous, now you don't have to sign up at the New York Times and FT, and I support Ft.com. subscriber and WSJ.com and you don't have to give your credit card out and actually pay a large annual subscription you can start doing it by the art so you have this model where the user is is somehow being paid right in when they opt into the ad like ad enabled version of a brave right and some of this money is being is actually coming in from the ad revenue itself.

So the ad revenue comes in, so you can think of it as like one stream of money, going in two directions. One is towards the user, and one is towards the publisher whose website was served. And you are basically creating this structure where this money can be partitioned

into these two kind of constituencies fairly. Money from the advertiser gets partitioned here. If the publisher wants to work with us and provide the ad slot, Again, we can do user private ad slots. The WeChat messaging app from Tencent has a sort of private chat bot-based ad model. And so we're not going to wait for publishers to partner. We'd love to, and there's some that will work with us.

We're already working with CoinDesk. That's well-known. We have a bunch of publishers already taking donations from us. They've fully verified at publishers.brave.com with our donation system that's in beta. But if we can do ads and user-private slots, we can stand those up very. quickly and give the user the lion's share of the revenue, like 85%. And we don't have to worry about publishers because we're not taking up their space. We're just an ad blocker.

And the ad slot is a private pinned tab in your browser. Could be a full screen video channel. Could be a push notifications channel. That's HTML content now. It could be a chat bot. Maybe even some people want one email a day. Some people still like email. We're going to explore all of these.

We have some user research to do on this, but I feel the user private ad slot model is very attractive and can kind of rescue advertising, even give long form ads they're due, whereas jamming in these, you know, one second of a quarter of the video was visible, and that's considered an impression by Facebook among others. That just doesn't seem like a viable thing to me, and it certainly is not paying publishers enough to make ends meet. That's the super interesting. So my question is, has this ever been attempted before?

There are some precedents. They are lost in the midst of time. you can read about All Advantage in Wikipedia. All Advantage was a PC app from the PC app era kind of like native apps before smartphones because it did things like used your email

contacts with your consent to promote itself to your friends and family and that got in sort of spam trouble. But it wasn't technically spam. I think its founders even helped reform federal anti-spam law so that they weren't wrongly accused of that. But All Advantage went up like a rocket during the dot-com era and crashed

with the dot-com crash. But it did pay users, a share of the revenue. It put ads in a strip, I think it was along the bottom of this PC app, and it had publisher content, like news content, to read independent of those ads. So we seek inspiration from All Advantage. It's controversial because of this Amway like Friends and Family mail promotion that was mislabeled spam. But I think it didn't get a fair epitaph.

I think All Advantage was doing some things right, and it just suffered the dot-com crash and the sort of anti- I don't like being mailed by my relatives too often either, so I understand, even if it's not spam, it might be annoying. There are, you know, ad-inserting toolbars that are generally considered scumware or actually worse. They're trying to put

malware on your system. Those are a bad precedent. That's why Brave has steered a course to be a baseline blocker and anything we do with ads will not only be opted, it will involve a separate open-source code module download, a component model. So we're not trying to bundle any of

ad stuff with baseline brave. We want to keep a very clean bright line between, you know, opt-in ads, open source auditability, zero knowledge proof, ad matching in private on your device. All that aside, we understand people are nervous about ads, so we're going to keep that as a separate opt-in bundle. So the fundamental problem is you have to invent a new ecosystem for digital advertising, and the tool by which you have chosen to attack this problem is a browser, right? It's you're coming in from the browser side. Was there any other option available? Like not to come from the broader side,

comes from some other side. What else was possible? People think, oh, he's just doing browsers again because I do browsers. I'd like to do something that was easier to deploy. It could be a network proxy, like Opera Mini is a proxy that actually can do some of the things we talk about doing,

doesn't use open source or blockchain. But the problem with doing something in the middle of the network is TLS, the secure connections we take for granted with our banks. The so-called secure socket layer of the 90s is now called transport layer security, TLS. And that's the H-GPS URL scheme. It's the lock icon or whatever the browsers do that the banks copied into their own pages to mislead people. But it's important, and it's rising. With let's encrypt the free certificate authority, the number of connections that are not secure is just dropping and will continue to drop to a

under 10% and as this happens in order to do anything interesting with the data that's in flight you have to do something pretty evil called man in the middle the connection you have to decrypt the connection in the cloud or in a proxy on the path between the client and the server the browser and the the TLS using server and you have to put it back together encrypt it again and forge a certificate on behalf of that server that you you could then fool the the browser into thinking is the real server. This is a nightmare, even if the person doing it is trying to do it for good reason, like antivirus companies try to do this. They try to do this even locally on your machine, and they botch it all the time. Tavis Ormandy at Google's Project

Zero found, I think Kasperski was doing something where they were matching only the first 32 bits of a public key when they were doing a hash qualification. And so they would alias different certificates. And he actually found a site in Rochester, New York, that alias the same public key prefixes, Hacker News, and he showed this a live demo of this certificate confusion caused by this man in the middle bug. And that's like the best case. It's kind of comical.

It's not good, but there are worse things that can happen. You can be totally open to attack. The man in the middle can see all your data, it can leak. It could be a bad actor. It could be that by forging the certificate on the leg that goes between the man in the middle proxy and the browser, you're actually opening the browser up to more attacks because other certificates can be forged. This was an issue with Lenovo's Superfish and Dell's Superfish, too.

Yeah, it seems pretty clear that the browser is the right way to address this problem. I mean, because otherwise you just introduce other layers that can be compromised. The browser is where TLS terminates, and TLS gives you message integrity and confidentiality. These are important end-to-in properties. If you break that, you're opening up security holes. And so, yeah, I ended up back in the browser. I do acknowledge that the tradeoff equally we talked about on mobile between apps and browsers doesn't exclude web views that are in apps, but the web views are always embedded by each app on its own.

So we haven't got a brave web view on offer yet. But if we get our revenue model going, we can probably fund and maybe even share revenue with the apps to start getting them to say, instead of using the native web view, which we use too, we'll wrap it with brave behavior and we'll share revenue with you. So it's possible it would take years to conquer the long tail of apps that embed web views and have a better story. I don't know if you use web views and apps. I do. And it's always annoying because it's kind of a mini browser. It's not good.

It doesn't have the same cookies as my main browser. It doesn't remember me. It doesn't have all the affordances I want. So I think there's an ongoing problem on mobile, but we can conquer it because the browser still matters, especially for lead users. So people also say, while you're doing a browser, good luck against Chrome. but actually because you're spending $23 a month on trackers and signaling and ads, people have figured this out and they're kind of annoyed. And if they use Chrome, they have to get an ad blocker. And then there are ad blockers that actually let ads through.

They say they do it, you know, just playing Robin Hood, just to take a fee from the rich and help sustain themselves. But it's never clear that they aren't doing it just to get the money and the ads themselves are unacceptable to you. So getting a good ad blocker like Ublock origin, which we had. on Chrome is challenging. Not every user is going to do it. UBlock's done well in the last year, but will it go mainstream? And it's always kind of captive by its host browser. Is UBlock getting all the APIs it needs on Chrome to block everything efficiently? Is UBlock actually unable to do things because it's a JavaScript extension running in a sort of sandbox that web extensions run in on Chrome, Chrome extensions run in? We do native code. We go full-staffirm.

on the client side. So we can do very detailed blocking very efficiently. We can avoid the memory head of JavaScript, which is a garbage collective language. So we've talked about the brave browser and so the key problem that it's addressing. So you mentioned that the ideal way to solve this problem would be to have exchanges. And so where publishers can have ads be displayed on browsers directly in the user's browser and there are no middleman in this in this operation. So moving on to the next topic before we wrap up because we know we have, we know that you have to get going because you're in New York and heading to the token summit pretty soon. Talk about the basic attention token.

What is the model there and how do you how does, how do you plan to break this, this toxic model as you've described it with this new exchange platform? We're doing a token launch on Ethereum, and we're trying to reboot the sort of ad exchange onto the blockchain. It'll take multiple iterations where we use some combination of our own zero knowledge proofs and sort of accounting servers. Eventually, you put it on the chain when the zero knowledge tech is ready, and the transaction cost is low. So I like to use a space program metaphor. We're going to do the Mercury Redstone that goes suborbital. we're going to do the Mercury Atlas that orbits the Earth.

We're going to do Gemini, where you learned to dock spacecrafts, then we'll go to the moon. If you try to build the Saturn 5 rocket in 1969, it's going to blow up. You're not going to make it to the moon or even to lower Earth orbit. So in our first iteration with this new token, we will be working on those user-private ads to share revenue with the user, and we will be staking users who opt into this program with some tokens. This is hard to do with existing cryptocurrencies because somebody has to, out of the grace of their charity, give away those tokens to the user. And I haven't found my rich Bitcoin friends eager to give away millions of dollars of tokens to fund our user growth

pool. So by doing a token launch, we can just, you know, by Fiat, stake a user growth pool with, in this case, 300 million tokens. We're selling a billion tokens, and there's 200 million more in a six-month lock-up for development team and reserve. So that's a novel thing. That's sort of a social credit currency idea or a little bit like a basic income grant. We think users should have some tokens out of the gate if they opt into the system. They've been abused for years by advertising. We want them to have some change jingling in their pocket. We want them to feel like they could donate it.

They could keep it if they want. And then if they've opted into this ad program, the token flow will allow us to share revenue with them. And that also will be transacted initially through Brave in a way that's anonymous. and efficient. And as we iterate on it, we'll try to get it to the moon, which is the ideal of decentralized on-chain real-time flows with revenue sharing. What's the basic utility of token to the user? So the utility is for the advertiser to buy an ad slot. Let's say it's this user private ad slots, so we don't have to partner with publishers. We can do that too and share revenue

with the publishers, and that will be a better share because we cut out the middle players. We're only going to take 15%. We're trying to make a viable business here. not take too much money out. But with the, and with the donations, by the way, Braves prototype that we take 5%. We'd like to take less. We just don't know what it's going to cost us because we've been developing the servers.

We have to do some K-YC on the publishers because that's where the money flows out of the system. You know, there's some costs there to cover, but we're not taking a huge amount of money out. And so whether it's a user-private ad slot or a publisher ad slot, we're going to share most of the revenue with somebody else, user and publisher.

So the utility of a token is to buy ad slots. And the only way to do that in this system is to have tokens. So that's, you know, I'm happy to hear from one of my friends in AdTech that his friends at a big agency actually are looking to purchase tokens in the crowd sale. So I'm hopeful that that will help us get to trial with that agency sooner. And they will do trials. Even though we're up-and-coming browser, we have enough of an interesting audience. an ad blocking audience, it's cut off from normal ad tech, is generally a smart set who does do a lot of e-commerce online,

does spend money on things, but just doesn't like ads. If some of them opt into these anonymous ads and get a revenue share, we think that'll be a productive use of marketing dollars. And that's what we want to build into an advertising business at scale. I'll say one more thing that should be canalyzing about this business. If we're studying with machine learning you opt into your behavior and your browser, and that data and the results of the studies stay on your browser, we can study things like your search queries, super hot, intense signal,

something that search engines take for granted. Those queries belong to you. We're not going to scrape the result page from Google. That's their business. We're not going to do anything with their ads. We leave those alone because they're first-party ads. And actually, the Google search ads are still pretty good. It's the Google links, the organic links,

that actually track you off the search page. So we have a pretty bright line between first-party ads and third-party ads. But your search query log belongs to you, and that goes into the machine learning for this new ad system. So I'll try to sort of describe it in my way. So what I'm trying to describe is sort of brave attention token. When you're buying a brave attention token, what are you really buying? I'm trying to put that thought into words. So disclaimer, first of all, all tokens, in my opinion.

are speculative, but I'm trying to explain what the way I think of Brave attention token. Sure. In some respect, like Brave is a, is a very, could be a very unique browser play because unlike normal browsers, there seem to be some kind of network effects around a Brave browser. Right. So when you have a normal browser, it's like when I download the browser and I use it to browse the internet, my usage of that normal browser does not improve. does not impact Sebastian's usage of that browser.

So there isn't a natural network here. But what you're doing with Brave is because you have this ad exchange, right? So the more the number of users that use Brave, the more valuable it is for publishers and for advertisers to be part of that Brave browser plus ad exchange network, right? Right.

So it's like Brave is a browser system in the beginning, but it's like an ecosystem of browsers that has a network effect. I'm glad you mentioned that because, by the way, we call it the basic attention token. We would like other apps to use it too. If the crowd sale goes well enough, if it goes to the max, we will fund and try to get IRS approval for a nonprofit trade association. We will try to bring in other browsers, games. Games have a lot of in-app ads, attention-based ads, and messaging also.

involves ad opportunities. So we think attention economics has been badly done through this parasitic system that evolved. And we'd love to bring in other apps and share the token with them. So we think the token can become quite valuable. And of course, it can be divided into micro tokens over time, you know, down to the precision that Ethereum allows. So we think it could go the distance. It's not just about brave. If it is attractive to Firefox, I'd love to get them using it, they'd have to block, if people opt into it, they have to block things to avoid arbitrage and Gresham's law of problems. If Microsoft Edge, which is also not really growing in the market, even though they're forcing it on people in Windows, can, if that is of interest in Microsoft,

I'd love to have them join this trade association. And games, we're already talking to some of the big game advertisers. I won't mention whom. So there's just a lot to do here. If the crowds goes well, it's going to be bigger than brave. We'll get scale with the advertisers, that way. But we can start with Brave and Brave will be the way we prototype and start the engineering and as the Trade Association comes up I hope we'll then be able to sort of build standards that become go from de facto to Dejore they can go into the W3C. We can get those standards I mentioned we lost when the web stagnated after IE monopolized it where you have standards for things like it's not

just ads or payments or anonymous payments and you can have anonymous intent signals. You can have third-party cookie blocks that are not gammable. You can have a higher level of discourse on the web standards about user retention. So given the monolith that is the online advertising agency, I don't know how to put numbers on it, but it's a massive industry with a lot of layers, a lot of players, a lot of incumbents. You know, immediately I think of companies like Google that have a massive footprint on just about any web page that you visit in terms of ad space. What do you think makes Brave and the basic attention token a viable solution? And what you think can help take Brave and the basic attention token to massive adoption

and basically just turning the model on its head? Great question. So one of the things we're trying to do, we've only prototyped the donation to publishers who can use a challenge response protocol to prove they own their domain. But we designed the system to go into the path part of the URL so we can actually help Twitch.tv and YouTube account holders get donations or get brave anonymous ad revenue shares. And that's a powerful idea because you may have seen a lot of YouTubers

are unhappy that they're not getting the ad revenue they used to. Some of them are being censored or cut out completely. You may have noticed the advertisers, I think there was a purestableness, Pure negotiating tactic made a big stink about their ads being placed next to objectionable videos on YouTube. Definitely part of a negotiating tactic. It could be a brand problem too, but, you know, it wasn't just brand safety. They were also trying to get some leverage with Google.

So we can go to those brands and give them an interesting audience growing from hundreds of thousands of users to millions of users, especially if we band together in this trade association and I guarantee you these brands that advertise will be interested they're always looking for a new way to reach interesting audience it isn't just about they only do Facebook or they only do google and that's it they try multiple ways they're always flexible I think they're the most flexible part of the system the publishers unfortunately in my experience are slower to change are less technically savvy and are going to be late to the party but we will we will get the buy side the demand side so called the advertisers the brands uh going to

And we will try to do it with things where the other side, the supply side, like the publishers who are really YouTube account holders, just individuals living in the domain of YouTube, but doing their own thing can be reached and try to make a match there. So there was a crowd sale starting, I think, in a couple days after this airs. 531, May 31, May 31st. May 31st. Okay, so anybody interested in that? Of course, we're not giving investment advice. you should always do your own due diligence before investing in the ICO or crowd sale. So, Brendan, I think you have to go.

We don't want to overimpose here. So appreciate it. Again, thank you very much for coming on. It's been a pleasure. We could probably go on for another couple hours. I mean, I wish I could have picked your brain on all that work stuff at the beginning. But hopefully we can have you on again at some point and maybe with a bit more time. So thank you so much.

And have a good time at Token Summit. Thanks. Thanks. Appreciate it. Thank you both. And to our listeners, thank you for once again for tuning in. We are part of the Let's Talk Bitcoin Network. You can find this show and lots of other great shows at let's talk Bitcoin.com. If you want to support the show, there's multiple ways you can do that. I mean, of course, you can watch our ads and maybe buy the products of our advertisers, but that's totally up to you.

You can also leave us a tip. That's a more direct way of supporting the show. The tipping address will be in the show's description. And also you leave some iTunes review. or leave a review wherever you get the podcast. So thanks so much, and we look for us being back next week.