Kent C. Dodds
TYLER: That's a tough one. I messed that one up last episode.
All right, so for this show, it is the last show for the foreseeable future. If you're interested in learning why and that kind of stuff, I have a blog post if you go to jsair.io/sunset, that'll explain why I'm sunsetting the show. But yeah, we have this show today, and it's gonna be great. If you do have questions while you're watching live, use the hashtag #jsAirQuestion on Twitter and I have that open and I'm watching, so feel free to ask questions. We'll answer those toward the end. And yeah, still follow us on Twitter. Even though the show is sort of ending, if I do start it up again, I will start tweeting, so that'll be the best way for you to know that the show has started up again. And yeah, that's pretty much it. So let's go ahead and get an intro. We might have a panelist or two show up part way through the show, but we do have Tyler McGinnis for our panel.
KENT: And again, I'm your host, Kent C. Dodds. And for our guest we have Brendan Eich.
KENT: So Brendan, why don't we give a quick intro to you, who you are, what you're doing, especially for people who may be new in the community who don't know who you are yet.
KENT: Awesome. So already so many questions that I wanna ask. That last little bit you said, "With your help." I'm curious, can you talk a little bit more about the Brave browser, what its goals are, and how people can get involved in helping?
What's really different about Brave is that we're trying to solve a problem that was an accident of history when-- and I said this at a talk in Vienna last week, when Marc Andreessen and Eric Bina added the IMG element to HTML in 1993 in Mosaic before Netscape, you can find Marc's post about this that said, "Hey, we wanted to add images to HTML, so we did it." The IMG element. You just can embed an image. You can link to your image even from another site. Why not, right? Everybody loves cat pictures. Your friend has cat pictures. You want to hot link them from your site. It's hot linking because if 10,000 friends do that and they all reload their page at once, your server melts down. But anyway, it seemed like a good idea at the time. So images were born, and they could be embedded in HTML but located on a different server.
Then in 1994 at Netscape, Lou Montulli created the cookie. And I think the reason he did this, I wasn't there yet but from going there soon after I heard and saw the code, the idea was to prevent you from having to login every time you went back or restarted your browser and you had a session with a site that knew about you that you authenticated with. Because HTTP was stateless, there was really no way for the site to remember you again. And so cookies were invented to sort of cache your authentication credentials. And it's a little bit of storage for that site in your computer on your resistance storage, your hard disk in those days. And it's sent with every request, and the server can send back an update to the cookie, so it's this little bit of state that can sort of track the site. And in the sense of keeping your login credentials, that tracking is good. That's keeping track of you so you don't have to keep typing your username and password over and over, which kind of gets to be a drag.
So suddenly, just between images and first party cookies, tracking via third party cookies was created, because if you think about it, you can put that cat image on NewYorkTimes.com and on ESPN.com loaded from MyCatTracker.com. And when you go to New York Times, if you haven't been there before, you load that cat picture, it can set a cookie. It can see that there wasn't a cookie already remembered for you, and it can say, "Hey, this looks like a new user. I'm gonna give them number 1234," and that cookie is associated with MyCatTracker.com. Images get cookies, everybody gets cookies, all requested cookies. Now you go to ESPN.com. My Cat Tracker's cat image is embedded there, too. It's maybe embedded with a different URL path name or query, so you can sort of tell if you're My Cat Tracker that it's embedded in ESPN and not New York Times. That's the way that the Cat Tracker site can tell which embedding it was answering that image request for. But now it can see, "Hey, there's a cookie, my cookie, my third party cookie, that has user ID 1234. So I know that user ID 1234 was at New York Times first, 'cause I saw that request and I remembered it in my database. And I gave that user that number 1234. And now, I see the ESPN URL loading that same image, and therefore the same cookie is being returned, is being sent over with the request by the browser, 'cause the cookie is associated with MyCatTracker.org." And sure enough, tracking was invented. And this was not intended as far as I can tell. It was used right away though, because everything on the web gets used. Every single thing -- unintended APIs, accidental serendipitous wonderful discoveries that are useful or dangerous or both, they all get used.
And the point of the story is is not that tracking is all bad or all good. I think it's generally kind of bad, it's kind of shady. It wasn't intended, and therefore there's no control over it. There's no way to, as a user or a web developer, to really express it as a clearly intended thing. It just kind of falls out of the image's cookies and scripts that we have as basic building blocks. So there's this problem that the primitives are too low level, and they let... they're tools that allow good or bad to happen. The trackers also could say they're doing good because they're trying to build up a better idea of who you are, so that a small or medium publisher can go to what's called the buy side, the marketing side of ad ecosystem and say, "Hey, I need good ads. I need to make some money so I can pay my server bills, pay my editors and writers. Can you get me good ads?" And the buy side will say, "Here, put this script in your page and it will help track your audience, your users. And because that script comes from a third party that's embedded in a lot of other sites, we'll know a lot about them. We'll have a dossier on them compiled from ESPN, New York Times, and all the other sites they went to."
Okay, well that helps the publisher maybe get better ads, maybe not. I mean, we've all seen how advertising tends to go in these sort of boom bust cycles, where at the end of it you have too many ads and they're bothering you, they're retargeting you or they're showing you parasite pictures or around the web pictures or pictures where you see something that you wanna see and you click on it and you get a listicle with 20 pictures and none of them is the one you saw that you clicked on. That's annoying. And the retargeting is kind of creepy. It can like ruin your children's birthday present if you're shopping after hours when they're in bed and then the next day you're going somewhere and you get retargeted for the ad for the gift you got for them, even though you already bought it.
BRIAN: That happens too in the opposite way, like some random ad will come up and my family will be like, "What have you been looking at?" I'm like, "Whoa!" (laughter)
BRENDAN: Yeah, it's not very precise. The claim that the trackers can build a dossier on you, it sounds very fancy like a spy novel. They often don't have more than a few bits to rub together. You can go to Autotrader.com, and suddenly your cookie does an auto intender, and you go to any site after that and you're starting to get these Ford ads and it's like, "Am I buying a Ford? I don't think so." But worse than these annoyances and the sort of clutter that happens as the annoyances don't generate the payments, the performance, the revenue that the publisher wants, so that the temptation is to add more ads. The really big problem here is that you lose all your data to these third parties, and they take advantage of that. They do things like pairing your online dossier with your offline identity.
I heard about this recently, there's something called Circulate. You put it in your website, it's this third party tracking thingy script. And it looks for email addresses in form submissions and it hashes them, does a cryptographic hash of them, and tries to remember them. And eventually, I think it can match make you with real email identity. And there are similar things that will sync you with your Facebook identity, your credit card identity. I don't know if you've had this experience, you go to a brick and mortar store, you buy something and then you go home and you get ads for it. (laughs) It's like, "Whoa, how did they know that?" There's a little credit card ad tech module at the point of sale, and it sends a signal to some server and there's some back channel where this is all synced up.
That's getting out of hand because it starts to identify you individually. So now not only are they deciding that you like sports or news, they're deciding who you are down to your home address. And that can be abused not only for marketing, it can be abused by criminals and governments. And it is. So the final straw for me was when I realized that malware was getting in through what are called ad exchanges, because as this ecosystem evolves between the marketers who spend money to advertise brands and consumer goods and services, things like that and the publishers who provide the space for the ads, in between those two sides of the ecosystem, a bunch of algae and shrimp and all sorts of snails and other things you get taking over your aquarium, your child's aquarium, happen to come along and fill in and try to take advantage of the money flowing through. And that enabled some predators to come in. And they, I kid you not, this is part of my talk in Vienna, they set up fake ad agencies and they buy cheap ad space, like 40 cents per thousand impression ad space, which gets onto the top sites, like The New York Times had this March, BBC Online had this in March, and these cheap ads actually have malware payloads in them. Sometimes they're very cleverly disguised, like AdGholas, which is think gholas from Dune.
There was a great analysis of AdGholas malware malvertising by Proof Point, and I used an image from that, with permission, in my talk, because it showed that there was the publishers and their happy websites and behind them were the ad exchanges from OpenX, AOL, Yahoo and others. The ad exchanges are like auctions for real time placement of ads. When somebody has got the dossier on you through third party tracking and the publisher has embedded their script, a call goes out to the ad exchange and says, "Here's the cookie. Can you find me the best ad for this person at this moment in the context of this publisher's site?" And then the ad exchange says, "Okay, I've got some ads. I've got some space. Can I get a deal? Do I hear 40? Do I hear 45? Do I hear 50?" They try to get the best pennies per thousand impression rate, or whatever the measure of performance for the ad is. And the criminal gangs are willing to throw money at this, like 40 cents per thousand impressions and they sometimes win that bid. And when they win that bid, the payload comes in. It looks like an ad, maybe it feels like an ad, there's nothing overtly obviously wrong with it.
So that's what happened. Malware came into this very permissive, deep, kind of fraud-prone ecosystem. And I say fraud-prone because there's another problem besides the criminal gangs, and the annoyances, and the clutter and the money going out and your data getting identified down to where you live, and that's there's fraud in the system. When I showed them the picture of how the ad exchanges provide real time ads, try to find the best ad for the space for the publishers, I pointed out that the exchanges take a fee when the ads come in. And they take a fee whether the ad is fake or real, whether it's malware or even just an ad that is intended to get somebody to click on a fake site, a phishing site or a click bait site. So there's a conflict of interest. The exchange owners want those fees. And they kind of don't care if they're good or bad. So they're gonna take fees whether the ads are good, bad or dangerous. And that kind of conflict arises when you have this deep, layered system with too many middle players, too many agents of agents of agents in between each other, milking the principles who are the marketers and the publishers.
So anyway, long story short, this was all accidental. It's kind of turned toxic and parasitic, and I think it's a concern for citizens around the world, citizens of the web, citizens of nations who worry about this because there's criminality, there's fraud, there's privacy, there's data ex-filtration at a large scale. And it's not good for anybody except (laughs) those middle players arguably who are taking their fees.
KENT: So Brendan, that's like a whole bunch of really cool stuff you just said. One thing you mentioned that Flash has so many vulnerabilities that if you got a dollar every time you'd be a billionaire. (laughs) So I'm curious why that is. What is it about Flash that makes it so consistently vulnerable, and is there any chance like, the web keeps adding more APIs, giving you more power as a web developer, is there any chance that we could see our browsers being just as vulnerable and dangerous as Flash was?
BRENDAN: You know, I don't wanna pick on Flash. Browsers have vulnerabilities. Any significant code base is going to have vulnerabilities. It's kind of a truism. It's a scientific fact, really, mathematical. I was watching a talk by Sergey Bratus, and he said this is a consequence of, you know, sort of undecideability, the Turing and Church developed David Hilbert's 10th problem, which was, Hilbert said, I think it was, "Can you make a mathematical system for solving certain kinds of equations?" and this led to the general idea of "Can you make a computer that can look at a program and decide whether it halts?" The halting problem. And Turing proved you cannot. And this has serious consequences, including we cannot statically analyze our code and find all the bugs. So we have to test it at run time. Stack analyses is good. It's additive and complementary. I still find fuzz testing where you generate travesty inputs and feed them to programs is more productive than static analysis, but you want both. When people learn this sometimes they're, if they are far seen they realize this means security will be a job forever. (laughs) It means you cannot hope for a day that comes when we suddenly fix the last remote code execution vulnerability and we're done. Because living code always changes, and changing code needs testing, because you cannot statically find all the bugs.
So I don't wanna pick on Flash too much, except now I'm gonna pick on it, because it really has gone sour, too. And the reason I think, Steve Jobs killed Flash but he did it with some fist of the North Star super punch that caused Flash to become a zombie that's been lurching around, eating people's brains ever since, and eating my computer's brain until I turned it off the other year. (Kent laughs) Steve Jobs, two of his greatest contributions in my opinion are thoughts on music, where he said no to DRM and thoughts on Flash, where he said basically, "Flash is like this other runtime, and we already have our own web browser. We already have Safari Webkit. We don't need Flash, and Flash is just gonna suck power and be a second class citizen." And I think he was right. I mean people said he was unfair and there were things he said in the blog post that weren't true, like he said, "Flash is based on older code." It's like wait a minute, iOS, Mac OS are based on BSD Unix and the Mach Project from CNU from the early '90s or whenever. There's a lot of old code in Apple software, but the age isn't the thing. It's whether it's living code that's been brought forward. And the problem with Flash, I think, it was a single vendor that had its day and did really innovate with Flash, truly innovated ahead of the web, because the web was being monopolized by Microsoft.
I'll tell a story about this. When I was at Mozilla, we were still facing this hard problem of getting Flash working right on mobile. And the only way I think that at that point Adobe was doing Flash on mobile was on Android. Android was not like Lollipop or (mumbles) or whatever. It was pretty old, and it had this terrible Webkit version. This was like Gingerbread or even earlier. But they had Flash. And Google had thrown engineers at Adobe doing things like the Pepper API plugin version of Flash. This was like a better plugin API. And so there was a meeting, it was a very weird meeting. It was like we were stuck at Mozilla thinking, "How are we gonna get Flash working on mobile? If we're trying to get on Android and there's still a lot of Flash content," which there was then, this was 2011 I believe, "how are we gonna do it?" And we went to Adobe, and we said, "Can we get a really good Flash embedding going for the Mozilla engine, Gecko?" And they said, "Why don't you just use Pepper?" And we said, "We can't really use Pepper because that's like using Chromium, so we'd have to get rid of Gecko or do some kind of a mash up between the two and it would be a lot of work. And we'd rather just take the Flash that we have in Gecko and make it better. Why don't we do that?" And the Adobe people were like, "We feel like we're children whose parents are fighting, and we don't like it. Why can't you just get along with Google? I'll help you get on the phone with somebody at Google," who I happened to know already. And I said, "Look, I'm here to meet with you, not with Google. Why are you talking about Google all the time?" And they were doing this sort of, "Why can't Mom and Dad get along?" And Mozilla is a lot smaller than Google. It was a very strange meeting.
What followed in two days, I kid you not, was they said, "Oh, never mind. We're dropping Flash on mobile," and by mobile, they meant Android, because Steve Jobs had already killed it on iOS, which means it's not gonna be on mobile. If it's not on the shiny, best mobile device, it's not worth putting Android. And Adobe threw in the towel. And that was 2011. But, Flash still on the web, especially on what you see on your big screens, your laptop and desktop. It's still used for ads that were created within the last six years, sometimes five years ago but they're still being sold. In New York, there's somebody, a media buyer is out there looking for space to fill with ads and they have some Flash ads that promote some product that's still on the market. Flash ads are still trending up last I heard from a friend at Microsoft. I think this might be out of date now, I hope it is, but two years ago and then a year ago I heard that they were seeing in Microsoft Edge a rising tide of Flash ads. My solution with Brave is to block those. And I think nobody really needs Flash ads, but this is why Flash lives. It's like a zombie. The reason it's lingering is sort of bad legacy. And since Adobe kind of walked from it and did Creative Cloud and went to a subscription model and said, "We're a services company and software as a service, and then platform as a service or omniture," whatever, there's no incentive for them to really lean into Flash and do all that fuzz testing and all that hard work figuring out deep in the actual virtual machine or in the C++ code why there's a memory safety bug that can allow remote code execution. So Flash is just a sort of toxic, (laughs) brain-eating, vomiting zombie.
BRIAN: It's been forsaken. (laughs) Well, plus it sucks to update. Nobody wants to update Flash. You have to close all your browser tabs.
BRENDAN: It's a pain. Jobs was right. Jobs didn't like extra layers of stuff. And I used to own Apple Mac IICI back in the old, old days. I never got an Apple II in the really old days 'cause I was a high school student or a college student and I couldn't justify it to my parents, 'cause they were sure I'd play games, and they were right. (laughs) I was like, "No, I'll make language flash cards." And they were like, "You'll play games." (laughter) So I never got an Apple II, but I did have a Mac IICI later. It was just a tight little machine, I think it was System 6. And say what you will about Apple, I think they always liked to have a tight hardware software integration. They have IOKit. They have AppKit, WebKit. Some of these are better than others in my opinion, as pieces of software in terms of design and implementation quality, but they don't have a lot of extra fat. They don't have two of everything or three of everything. And so Flash would have definitely been one too many compared to WebKit, especially since the original iPhone was supposed to be about the web. They said, "The web works." Jobs said, he held up the phone, he said, "The web finally works," and that was their app model for the first 10 months.
Plugins are a problem. Browsers are a problem. Browsers will have bugs, too. That's why it's important to keep up to date. That's why Chrome, Firefox, and Safari all update very often, and IE updates often now in the modern era. They used not to, but Microsoft learned the hard way and did a good job reforming itself on security, patching over the years. And Brave updates often. We update often just to add features, too, 'cause we're so young, but really do need software, it needs to be living, that means maintained and fuzz tested and analyzed. It means also that you're getting updates to your users or they are gonna be vulnerable. Nevertheless, there's a big black market for exploits. It's the big story in security now. You just can't keep ahead of them. It feels like not only an arms race, but kind of a losing race in that people are using C++ and C, these are powerful languages. C++ is great, right? It's evolving still. It's got lots of great features, formerly unsafe. You can talk about using template types and being careful. At the end of the day, it's unsafe. That's one of the reasons at Mozilla I sponsored Rust, and that's why I'm excited about Rust. We also see other safe languages coming before. I just wanted to say while I was kind of pessimistic about security, because of the undecideability problem. There are better tools and there are better programming languages. And I'll pause there, because that's a hopeful note for the future. I think if we use those better languages like Rust, we will have fewer security bugs down the road.
KENT: That is a nice thing to end on there. (laughs) So I know that like... so obviously Flash is something that we want to not have running on our machines. I've disabled the plugin in my browser, but sometimes I go to a site that requires it to watch a video or something. I have to open an incognito mode or something. But from what I understand, Google Chrome has started to or will soon automatically block Flash unless it's the only thing that's powering the site. Have you heard about that and is Brave doing something similar, or how is Brave combating this problem?
BRENDAN: Yes, I've heard about that. And I think it's a little bit slower. I wasn't sure what their plan was. I think it might be changing since we last looked. At first it sounded like they were gonna turn it off by default, but they had this sort of growing list of sites where they would actually allow it because, as I said, unfortunately, it's still required for some sites. That looks just too dangerous to us at Brave, so what we've done is we've turned it off by default. And if you go to a site that needs Flash, you will get a black plugin rectangle with some kind of a prompt that allows you to turn it on, sort of go into the general preferences and turn it on. That's the first line of defense for us. And then, if you do that, it's still off for any site, but we intercept the thing that tries to load it and we say, "Do you wanna turn Flash on for this site?" And then you can do that. I think you might even have to reload. We really don't make it easy for you, which is kind of intentional. And it remembers for that site, but (laughs) we did something extra. Because Flash tends to have endless vulnerabilities, after seven days for that site, it disables again automatically. (laughs) So why do we need the Flash? And I think that's appropriate, because that zombie's kind of, it's eating everything.
KENT: Wow, that's amazing. I love how hard you've made it. (laughs)
BRENDAN: That's, An-su did all that work, so. And she's fielding different variations on a theme where Flash comes in through some sneaky embedding or some different way that we can't always intercept. So we're working on it. So people shouldn't just assume that we hate Flash so much that there's no way to make it work on a given site. We'll take bug reports and we'll try to fix them, but we're definitely not gonna make it easy and we're not gonna turn it on by default. It is off by default in Brave.
BRIAN: But Silverlight isn't, or?
BRENDAN: No, Silverlight is off. We don't even have other plugins. I think Silverlight is dead anyway. The story there is that Silverlight was important, especially on the Mac because Netflix needed it for some level of DRM sort of software, obfuscate DRM and maybe on Windows earlier they needed it, but then Microsoft, Netflix and Google got together and did HTML5 encrypted media extensions, which is DRM for HTML5 video. And pretty soon, before that spec was even like, might not even been a working draft, I don't even know what state it was in, they started shipping support for it because they wanted to get rid of Silverlight. So Silverlight is dead. And that's good, because the Angler Exploit Kit was targeting Silverlight as well as Flash, and maybe even the Java plugin, which Oracle was a very bad steward of for many years and finally got wake up calls with massive exploits. And I'm not sure how good it is either, but we don't and Brave, we don't do any of those plugins. It's just, plugins are dead. It's just a matter of time. They're the walking dead. (laughs)
TYLER: So I wanna switch gears a little bit here. I think because your engineering background is so prestigious, a lot of people kind of overlook your CEO background. That's something I'm interested in, 'cause you've basically gone from this hard core engineering role to the last few years being in a CEO role. So if you were to give advice to some people doing that same transition, what advice would that be?
BRENDAN: Oh thanks, that's a good question. Well for one thing, doing Mozilla, even though I was CTO for a long time, you have to sit in the rooms where you're making fateful business decisions, you're figuring out how you're gonna survive, what's gonna fund you, which partners you work with, which ones you don't, how you work with them. So it's impossible not to learn that way, and even before that I was a principle engineer at Netscape, there were lots of opportunities like that. But I kind of forswore management too long. So I would say don't do that. If you get to a level of achievement where it makes sense to get into management or some kind of technical leadership position, do it, because you can 'cause more to happen than your own 10 fingers can type, right? That's the real win there. And you can help people grow and do things together that none of you could do individually. So it's great to be an IC, and I did it for a long time.
So when I got to the technical leadership position, then I was doing things like influencing but not managing. Influencing can work, but you end up, especially if you get into a larger organization having to influence person to person, and that gets attenuated across seven degrees of Kevin Bacon and it can be a drag and you can run into all sorts of politics. So management is, without throwing your weight around, with true leadership, management gives you this extra dimension beyond influence, which is that you're actually deciding on the order of work and helping people charge up various hills and build various castles, sky castles. Let's hope they stay up. And the CEO level is just the sort of top of that where they have to be the place where the buck stops as one of our presidents said. Was that Truman? And that means you get the accountability, too.And I think the other thing that I would say that's valuable is, and this is something that I hope came out when I was talking about advertising earlier, you have to have some amount of empathy to model various people's business concerns. Like maybe they are rapacious pirates, but maybe they have some legitimate business needs. And at the end of the day, everybody has to put some food on the table. So you have to look at various interests and how they align and possibly conflict, and sort of, it's like solving a puzzle. Can you get the interests to align more than conflict, or align totally, which can be beautiful? Can you make deals that are durable and that they really serve both parties' interests in some complementary way?
My best example of that was when we did Firefox we had this hot new browser when no one thought you could have a browser, like Internet Explorer was it. The web was over. And suddenly, Firefox was taking back market share from Microsoft, which had never been done in any category that I know of. And Google has got this awesome search engine and since 1998, people are using it instead of Alta Vista or whatever, because they have page rank, they count inbound links as reputation, they can't be fooled by the contents of the document having spammy hidden HTML comments that contain dictionaries or whatever. Google has this great search engine and they figured out how to do search ads, placed results as Sergey called them, and it's kind of beautiful because they can be as good or better than the organic results. They look texty, they aren't really annoying. And by the time we started dealing with Google at Mozilla in 2004, they already tuned up their AdWords system, second or third generation of this search ad business. So we had this complementary partnership, like Google doesn't have a browser, Firefox doesn't have a search engine. That was a good deal. It didn't last, and things never last forever. So at some point the Firefox people that Google was employing, I think this was early 2006, went off to do Chrome. There was a demo, I heard from some of my friends who had been Mozilla hackers, Darin Fisher and Brian Ryner, I think Darin runs Chrome now, the whole group, they did a demo in mid-2006 that was Chrome, and it was awesome. It wasn't, I heard, anything about V8, 'cause V8 was just starting then. It was more like, "We're gonna make this sad tab, 'cause everyone knows plugins crash, and everyone knows WebKit crashes. And it's a drag when your whole browser goes down if it's Safari or Firefox." So they did a demo where they had several tabs, and it's easy enough to have a captive crashing specimen somewhere and they made a sad tab appear and they got a standing ovation. That was the real big idea with Chrome, process isolation. It also gives you responsiveness. It also uses a lot of memory if you let it. (laughs)
So I think CEO management leadership, sorry I went technical again, having some idea of interests and how they might merge and align and be complementary and working on that is good. And to just finish that thought, I'm not sure Mozilla could've done anything to forestall Chrome any further. I think Google, when I talked to Larry Page I think in 2005 and he was all enthused about WebKit, I said, "You guys should probably do your own browser," because they're big enough, they have enough talent, and they can put their own flavor on it. They can decide what it should and shouldn't be. So you have to be willing to let deals like the search partnership end, and Mozilla didn't. And then for a long time it was considered like, "Oh, Mozilla is Google's boy. Mozilla can't get out from under Google's thumb." And there's some truth to that if Firefox over time, I think the peak market share was 27% right after Chrome launched, maybe within a year, and then it declined and Chrome passed Firefox in 2011 as I recall. At that point, people probably had a little bit of a point about the game theory. Like if Firefox keeps going down and you're relying on Google for revenue, at some point they might just say it's a write off or, "Okay, but here's the new deal and the terms aren't as good," or who knows what. I think, this is partly on me, we should've been cognizant of that and looked for another better way to sustain Mozilla. They did eventually go with Yahoo after I left. I'm not gonna comment on that (laughter) 'cause Verizon is buying it and it's kind of all different now. We can talk about that on a different show. But I'll say that for CEOs or aspiring CEOs or anybody thinking about management, you wanna be strategic, too, and not assume everything is forever and have a map of where the future is that you can use to navigate out of your deals as well as stay in the ones that will sustain while the going is good.
KENT: I'm sorry. Brian, did you have something you wanted to ask?
BRIAN: I just, earlier I wanted to just say you have to be "brave" not to use Brave. Anyway, you can use that if you want. I can also be your CEO if you want. (laughter)
BRENDAN: The idea was you have to be brave to use Brave, because we make... we make it hard on users a little bit. I'm not really selling it well here, am I? I'm not really a salesman. (laughter) What I mean is, if you're gonna defend your data and your security from malware and from trackers and annoyances and people who are snooping on you, that takes a little bit of courage because at first you might find they're saying, "Oh, you're using an ad blocker. You can't read my great publisher content." Or you might get a page that doesn't quite work right. Or you might have to turn on Flash for one site and then it'll turn off in seven days. (laughs) But whatever you do, it's gonna take a little extra effort, and you should be willing to expend that effort because we aren't passive couch potatoes on the web. That's just a bad model. That's like the TV model. And people worry the web is gonna turn into TV. And to the extent, video is rising and everyone wants Netflix and shows. Sure, why not? I mean, you can't stop that.
But I believe the web will always have a textier side and a more balanced relation between producers and consumers. Obviously, the YouTube stars for the young generation today complete disjoint from the Hollywood mainstream media as far as I understand it. I'm old, so I have to go by hearsay here. (laughs) Anyway, the web is more read write and less passive, and that I think allows for some of the web citizens to be brave and to assert their rights, and that could change the web standards. And that's, to finish the early point about Brave, we're not just in it to build something that's custom. And it's all open source, so what we'd like to do is standardize better standards for things like ad blocking and ads and anonymous ads, and micro-paywalls, micro-payments, anonymous payments, micro-donations. Those facilities are not in the web standards, and people have to cobble them together site by site or go around and do deals with sites. And you don't wanna sign in with nine different micro-payment systems.
BRIAN: Yeah, that's actually the big question I had was around micro-payments, and where you see the future for entrepreneurs in that area. Like, is Medium gonna be a giant monopoly now for blogs? (laughs) I guess it already is, but yeah, micro-payments is very exciting.
BRENDAN: It is, and I think there can be many approaches. At the end of the day, think further out at the end of the decade. If you're building a web that's important for its, I won't say legacy, but its long term, durable, text and video and images content, but you're also building AR and you're sort of PokÇmon Go-ing it over the real world, and you're building VR, which is definitely a gamer thing but can, I think, grow from there, there's some industrial and educational obvious place that are going well, then suddenly you have all these shared assets. And it isn't just the text and the video and the images and the links and the scripts, it's things like 3D models and texture art that skins those models. How are you going to protect those assets? DRM isn't gonna cut it. You're in a shared world. You can't encrypt the pixels with a secret key for each user when there are 50 or 50,000 pairs of eyes looking in through VR on your model. So you're gonna have to order things like watermarking, which I've blogged about in the past. And you're gonna have to consider ideas from Ted Nelson's Project Xanadu, which predated the web, like micro-royalties. And these need to be high integrity. These need to be part of the protocol. They need to be woven into the fabric of this new super web. And they need to be common among all browsers and viewers and AR and VR devices.
So what I hope happens here is future standards will make payments, anonymous payments, micro-payments, sort of frictionless payments, possibly for those who want to see them, anonymous ads. I'm always trying to get people to use, with permission, the Minority Report scene where Tom Cruise is on the lam and he's going into the subway and he's, everybody in the subway, their retinas are being scanned, which I don't know if that's actually practical, but it's really creepy because they're all being identified. There's no privacy at all, and they're all getting sort of beamed sound into their ears promoting custom ads to them. I think that's totally dystopian. I'm not sure it's technically feasible. And it just seems like we shouldn't have that future. We should have a future where, whether you're walking around or you're in AR, a combination of virtual and real, or you're in virtual, you have control over your data and you have control over your identity. And if we don't build that into the standards at the right levels, it's gonna become captured by the walled gardens or the big superpowers, and it's gonna get abused.
KENT: This has been a really interesting show. It didn't exactly go the direction I was expecting, but I'm just like really amazed at the thought that you've put into this and hearing the history of why we are in the state that we are and the things that you're doing. And so with the little bit of time that we have left, I am curious what your thoughts are after a little bit of time with this new yearly release schedule of ECMAScript. What thoughts do you have around that yearly releases of ES specifications and is this going to work out with this yearly train?
BRIAN: (laughs) Cool.
KENT: All right, so we can still bet on JS for the foreseeable future.
BRENDAN: For the foreseeable, it's a good bet.
KENT: Cool. All right, well we were actually I think a little bit over, and I have some things I wanna say for our last show, but thank you so much Brendan. This has been awesome. We don't actually have any questions on Twitter, so we'll just jump right into our tips and picks. So yeah, we'll go ahead and have Brian go first.
BRIAN: Oh yeah, sorry, I've got to leave soon. So I just wanted to throw out there that I've been reading this Matryoshka library for Scala, and I think it's something people should look at, because if you didn't realize how many composable recursion schemes there are and you're still writing loops, you should go enlighten yourself. Also, Bartosz Milewski is doing amazing category theory videos on YouTube, so check those out. And also, shout out to the show. I've had an amazing time. Thanks, Kent. (laughs)
KENT: Thank you so much, Brian. Could you get links to those in the show notes? I have no idea what Matryoshka is. (laughs)
BRIAN: I'll throw those in there. (laughs)
KENT: Hey, thanks so much, Brian. You've been an awesome panelist. Cool. Tyler, you go ahead next.
And then my last pick is, part of the reason that I'm wrapping up the show is because there's other things that I'm interested in putting my time into, more interested than continuing the show. So SliceJS is this really cool thing that I'm working on that has awesome implications, like this thing that I made up called Ultra Tree Shaking, and also learning code bases and stuff. And I'm giving a talk on it tomorrow night at a meetup here in Utah, which I will probably Livestream, so I've got some links to that. So sweet, yeah. That's all of my stuff. Brendan, what do you have for us?
The other thing I wanted to mention is something that I realized from Twitter people don't know about, and that's ES6 destructuring parameters. When you use object patterns and array patterns, you can put default values for the missing properties that are being destructured into the pattern using the equal sign. I can't really explain it over the air, (laughs) but check it out. Destructuring in ES6 has this awesome defaulting of individual properties inside the object or array pattern. It's really handy for options arguments.
KENT: Awesome, yeah, that's great.
BRENDAN: That's my tip.
KENT: Well, thank you so much Brendan for starting and ending this show with us. It's been an awesome run like you said. We've had a really good time. Maybe someday we'll start it up again. Thanks so much Brendan. All right, that's it, so we'll wrap things up. Thanks everyone. Bye!