CloudChat Interview Series
Andy Ellis, Chief Security Officer, Akamai
Episode 2: Trust for the Internet
Listen to Interview with Andy Ellis, Chief Security Officer, Akamai
Chenxi: Welcome to CloudChat. Today we’re speaking with Andy Ellis, Chief Security Officer of Akamai. Andy is a thought leader in the industry and has done a lot of work in the area of Internet security. We’re fortunate to have Andy here. Welcome, Andy.
Andy: Thank you. I’m happy to be here and looking forward to spring coming upon us.
The Internet Trust Infrastructure And The TLS Certificate Authorities
Chenxi: Andy, when we were prepping this, we talked about the vast trust infrastructure underlining the Internet today. Every time I go to my bank’s website to do banking, I trust that the Internet infrastructure finds the right web server and gives me the right content. If it’s not the case–if CNN’s not serving me the news, if my bank is not the right banking site–everything will break loose.
Just a few weeks ago, Google discovered that an intermediate certificate authority in China was issuing certificates to fake domains. When that happens, the trust of the Internet is disrupted. Talk to us how the Internet trust infrastructure works and how much we can trust it, etc.
Andy: When we look at how the Internet works, somebody types in the URL into a browser, and they get a web page. But behind the scene, there is an infrastructure that finds the servers you might be looking for. That includes the domain name infrastructure, and that converts names into IP addresses. And with IPv4, it’s four numeric digits, each from zero to 255. We all know that your Google’s name servers are 188.8.131.52. For a very long time, many people knew MIT’s name servers before they made them private. But that’s not easy for everybody. So the infrastructure translates strings like www.akamai.com to the actual IP address.
Now, once you get to a server, how do you trust that the server actually is the server it says it is? And so in addition we have the TLS certificate authority infrastructure. That’s how we are sure that the server is who we think it is. It’s like if you’re walking down the street and you walk into an Apple store, how do you know it’s really an Apple store? It turns out there are countries that Apple doesn’t do business in that you can totally walk into an Apple store there because somebody just copies the design logo and the design schematics and sells sometimes are fake, sometimes real goods.
And as long as you understand how much trust you should ask, then I think people operate with a willingness to accept the risk. I mostly accept that my bank is going to be my bank when I go to their website. And the concern becomes when users hit a critical mass of distrust in the infrastructure, we might have a serious problem. And I think things like what we saw with CNNIC are a great example of something that’s high enough profile that people might start to lose trust.
Chenxi: It used to be the case that the certificate authority does very little verification of the entity that comes to request for certificate. It’s as if I can walk into DMV and say, “Hey, give me a license that says Andy Ellis,” and I’ll take it and then go present it subsequently to expect services that’s destined for Andy Ellis. In the physical world, people will say that’s just ridiculous but that was what could happen on the Internet. Share with us how some of the problems that can arise from this issue and what have we done to address some of the problems?
Andy: Sure. First we should start from the primitive that make up the certificate authority infrastructure. And it all comes down to the ability to do cryptographic signing, which is an asymmetric operation where I hold the private signing key, I sign an object and you can use my public key to verify that signature. So I can sign and say, “Look, I am www.akamai.com and here’s the signature that says that’s me.”
But how do you trust the public key that I say is associated with that? Well, I take that public key to somebody else and they sign the public key with an assertion that says, “No, really that person is www.akamai.com and you can believe me because I am your Comodo or I am your GoDaddy or whichever certificate authority you want.
But there’s nothing magical about a certificate authority. What makes a certificate authority trustworthy is the fact that your browser believes they’re trustworthy. So the real root of trust sits with Chrome, and with Firefox, and Safari, and Internet Explorer when they say here are the list of entities that can find TLS certificates. And there’s no other restriction there. And that’s the key element. It’s like if you walked into the DMV and you got a driver’s license that said you were Andy Ellis, and then you were able to walk into a government facility, and they would accept it to get access to sensitive nuclear materials, for instance, that would make no sense. Why would the Massachusetts registry of motor vehicles be able to issue IDs to get you onto a military sensitive base?
But the CA infrastructure lets you do that. So China’s certificate authority infrastructure is allowed to issue certificates on behalf of, say, Indian government websites. That doesn’t make any sense, but that’s the key part of our problem. So the first problem here is every certificate authority can issue certs on behalf of any domain name that they would want to. Secondly, there’s the question of how do they verify that an entity is who they say they are?
In terms of verification, there are three types: domain validation. And what that literally means is at the time we issue the certificate, we validated that this person controlled the domain. And by control the domain, it’s we give them the URL and told them to put content on the URL and they were able to do so. So when we issued a request for that web page over HTTP, an unsecure system, we got back the answer we were expecting. That’s the way the less encrypted certificate authority operates. It doesn’t prove somebody is who they say they are.
A slightly higher level is organizational validation. Now, there’s no real difference between a domain validated and organizationally validated certificate to an end user. They don’t know the difference.
Chenxi: So the browser doesn’t know the difference either, right?
Andy: The browser does not show the difference in any meaningful fashion. An organizationally validated certificate is one where the CA asserts that they have seen paperwork that demonstrates that this is the legitimate entity that really has this name, that really has control of this certificate. As you can imagine, it’s very easy to get a domain validated certificate because you can use an API to issue one. An organizationally validated certificate often takes weeks to issue because you’d need paperwork on a company’s letterhead, and then you’re down in street number and all sorts of evidence to show who they are.
And then the third is the extended validation or enhanced validation certificate. People often call it, both of them, the EV cert. That’s the one that shows up as the green toolbar generally in most browsers. And that’s one in which the certificate authority asserts that not only does this entity exists, but they really are the only plausible entity that has that name. So I could go and create a company called Levi’s, I’m probably not going to get an EV certificate for Levi’s jeans because everybody knows who Levi’s jeans is and that’s not me. And so EV really is about saying that the human definition of this name belongs only to this entity. And so those are those three types.
Mixed Content Websites
Chenxi: EV certificates came a bit later, which is that green bar on the top of the browser that indicates this site has an extended verification certificate. But the site could dynamically third party content, such as ads or RSS feeds or other embedded content. Those third party content may or may not be from a similarly verified website. It could even be from a malicious website. So how does my browser, as my proxy, really process that? Or does it?
Andy: So this is a really hard problem is to decide what to do with the very few signals that you can give to user. Because all that extended validation means is that the company behind the website owns that name. And so you can really think about extended validation not as being a better security on the website, but about the fact that the companies that really had ownership of certain names. For example, some companies were late to the domain game like Nissan, the Nissan motors has the domain Nissanmotors.com, not Nissan.com because Nissan.com is a computer repair guy who’s held that domain since the very beginning.
Chenxi: Is this true?
Andy: It really is true, there have been lawsuits around it. Nissan tried to beat him with lawsuits to make him give it up but it’s his last name, and it was his valid domain and he got there first. But if you’re a bank, and the banks were last to the Internet, so they didn’t often get the plain language domain names they wanted. EV really lets them say, “This is who I really am.” That’s all it does differently. It doesn’t make any claim about the security of the website. Unfortunately people often, because it’s associated with the large brands that probably have better security procedure, people assume more security.
Chenxi: It’s a drastic measure, right? By taking out CNNIC as a trusted root, they in effect invalidated all of the other legal certificates that have been issued by CNNIC. Right?
Andy: Yeah. So it’s a hard choice. And we’ve talked about this in the industry when Comodo had problems and people said, “Oh, should people blacklist Comodo?” And if you blacklisted Comodo, they were the cheap certificate issuer for so long that so many people would have been broken by that, that at that time, the browser said, “Well, we won’t, because it doesn’t look like Comodo was engaged in this malicious practice.” They were just a victim of an attack. So that’s extra interesting.
Chenxi: But the consequence of certificate authority being a victim of attack is far and wide because they are the root of trust for so many certificates which underline the trust operations.
DANE, DNSSEC, and The Brittleness of the Internet Trust Architecture
Chenxi: A follow-up question. Andy, we’ve been operating on this infrastructure for so long. And we’ve seen some of the brittleness that comes with this architecture of a single root of trust, albeit you have a few of them, and from that root of trust you have intermediate certificate authorities, then everybody else becomes a leaf of this tree infrastructure. There’s an efficiency associated with the tree architecture but the brittleness is undeniable. So the question is: If you were to design the trust architecture behind Internet today, from scratch, would you go with the same architecture or would you do something completely different?
Andy: So I don’t know. It’s a hard question. One proposal that’s actually out there today is called DANE, which is the DNSSEC assertion of named entities. And it basically says assume everybody has DNSSEC, that’s a very big assumption, first of all. But the beauty of DNSSEC is that there is only one root of trust and it’s the same root of trust that is the root for name service. And so the 13-root name servers, they basically sign for the top level domain. So dotcom gets signed. And now, it’s dotcom’s responsibility to sign on Akamai. And then it’s Akamai’s responsibility to sign on things underneath it.
There’s something really elegant about that in that we already have a root of trust so you could overload it. Now, here’s the danger, that root could become brittle. But that already has a nice organizational hierarchy. So yeah, the dot-CN authority has no ability to issue in dotcom. The downside for all of us who has to interact with all of these different domain names, we’d have to have multiple different paths back to the root. We couldn’t just have one.
Chenxi: Is the multiple paths back to the root then becomes the added reliability to this architecture versus the single path?
Andy: I don’t know if it’s more reliability such as it’s this more complexity that doesn’t necessarily add the reliability. But what it adds is you don’t have the vulnerability today, where today, the root of trust is the browser trust store. And then popping out of that are the hundreds of certificate authorities, but all of those authorities are peers. And that’s the real problem is that there’s no way to say, “This certificate authority can only issue certs within this domain name space.”
And maybe that would be an enhancement I would do would be a simple one – to start restricting these authorities to specific parts of the name space. And then possibly something like DANE where you issue a DNSSec record that says, “Look, for akamai.com, only accept certs that are issued from this certificate authority.”
Andy: The benefit that we’ve had is this really race to the bottom on prices for SSL certificates. If we go back 10-15 years, it was really challenging to get an SSL certificate for less than $1,000 a year. You could and you could go looking and there’re a couple European CAs that would sell them that cheaply, but VeriSign effectively held the monopoly. They were the only people selling certs.
Thawte came along and was an open source alternative, and they got to about 40% of the market and then VeriSign bought them, and went back to be 90% of the certificate market. And VeriSign’s attitude for a very long time was, “Certs are valuable. We’re the only trusted name to issue them. Why would you use any other CA? And we’re going to make money on this.” And everybody else figured out that you could go be a CA, sell certificates for $40 and actually make just a little bit of money on that.
Chenxi: Yes, everybody is doing certs, hence, led to the problem we started this conversation with. You mention DNSSec. How widely deployed is DNSSec?
Andy: It’s not very widely deployed at all. So there are a couple of nation states that have widely deployed it. The Swedish roots use it and a lot of Swedish domains use it. But even within dot-gov where there’s been a mandate for 10 years to deploy DNSSec, it’s still very hit or miss on the deployment. We even built a turn-key solution so that our customers who are already DNS customers could just say, “I want DNSSec.” And that’s all they had to do and we would do all the work for them. Remarkably low adoption of that product. We expected everybody to say, “Oh, I must have DNSSec. Please let me have that product.” And really folks aren’t using it that heavily.
One of the big fears that we actually see is that DNSSec doesn’t have a roll back option, which is if you turn it on, and there are any clients who’d believe and trust in DNSSec, and you’d discover that you have a problem, you can’t turn off DNSSec because you will functionally irrevocably break those users.
Once you start signing, you have to sign forever. You can NEVER not sign. The moment you stop signing, those users get very confused about what just happened, that looks like an attack to them. You can’t get back out of it, it takes some time. You have to go back up to the roots, wait for timeouts to happen. At some point, you get back, but it’s a hard failure until you can come back.
Chenxi: Did they ever happen? Has it ever happened?
Andy: I haven’t actually seen it happen. That’s partly because we’ve seen such slow rollout of it that you haven’t had anybody really adopting it except with very good care.
The Move To Encryption
Chenxi: You also talked about another trend, which is the move to encrypt the web. In my last CloudChat with Michelle Dennedy, we talked about how some of the high-tech companies move to encrypt traffic, pin their certificates, and encrypt mobile devices. When the government comes to subpoena the data, or with a search warrant, they can say, “We don’t have it. Go to the customer.”
You talked about this as a growing trend, and some even moves to encrypt the public web content. Is this the right move in your opinion?
Andy: It didn’t really matter in whether I think it’s the right move because it’s happening. There are two different moves afoot. One is about encrypting all data in transit. And then a second is encrypting all data before you give it to a third party.
The first one really is about ensuring that you have privacy against the pervasive adversary. I think a lot of people are still very concerned about the revelations of spying that have happened worldwide. There’s also starting to be more people paying attention to injection attacks that are happening certainly as you cross certain nation state boundaries. We’ve certainly seen and talked of this having happened across the great firewall of China. I’ve seen that in other countries as well or where you have proxies that want to modify content in and out.
So there are great reasons for it and it’s actually very hard to determine where do you draw the line. Where do you say, “Well, this content needs to be encrypted. But this other content, that’s okay if it’s not encrypted”? Because it could be that what you and I think is perfectly innocuous, in certain regimes is very much not innocuous, and it may be a risk to the people who are there.
Certainly on protecting user privacy, this is the right first step. But it’s really important to acknowledge that encryption does not provide privacy. One of the guys on my team likes to say that encryption is like putting your back between your mom and the cookie jar. When you’re stealing cookie out of the cookie jar, and you hide the cookie from your mom, you didn’t hide the fact that you just stole a cookie, she just doesn’t know which one you took yet. It’s designed to tell to protect credit card numbers, not the fact that you moved the credit card number, but which credit card number you moved. And that’s a distinction that a lot of people miss. They think, “Oh, well if you’re in China, you can surf Wikipedia freely if you have encryption.” And the answer is not really. Traffic analysis actually is useful for telling us which Wikipedia pages you’re viewing. So if you want to go and pull up Tiananmen Square from inside China, there’s a good chance that the Chinese authorities know you’re looking for the Tiananmen Square webpage. But they can’t tamper with it. And that’s a good control to have.
Now, when we think about the data in the third party and the move to, “I don’t want my third party to be able to decrypt the data,” that becomes relevant when law enforcement does come looking for your data. And if I give my data to a third party and law enforcement goes to them and looks at it, I would never know. So the only thing I can do is make the third party not able to ever look inside the data, and that way, if a search warrant is served on me, then I have to know about it. And I think that’s the root of what people are looking for.
Chenxi: Last week, I was on the East Coast and I talked to a number of large financial institutions and there’s a raging fear within these institutions about unintended consequences of data leak. They were really afraid of when they put their data in somebody else’s care, and some other clients of that third party gets subpoenaed, their data could be unwittingly released because maybe a lapse in how the data is managed and stored.
So there’s a lot of interest in encrypting data before I hand over to the third party, and I’ll hold on to the keys so that I have some way of guarantee that when the government is coming to look at the data, they don’t have my key.
Andy: We do see that movement, we see the interest but there really isn’t yet complete turnkey solutions that let you get all of the features of handing somebody else your data and still make them unable to read it. Because in many cases, people aren’t just offshoring data from a storage perspective. This isn’t, “I want storage as a service,” it’s, “I’d like my business analytics as a service and I’d like to offshore my call center, and so I’d like each individual rep to be able to look at data. But I don’t want law enforcement to be able to look at it.” That basically is an impossible problem.
So when we get into this wicked problems, it’s very hard to actually write down what is the actual constrain? What problems do we try to solve? Which ones can’t we solve? And then go after the problems that are actually meaningful and tactical. And sometimes law enforcement is the big bugaboo. It’s very easy to say, “Well, I don’t want law enforcement looking at my data.” And sometimes you have to ask the question, “Why not?”
It’s perfectly reasonable to say, “I don’t want law enforcement looking at my data.” But you should understand why in a third party, it’s more at risk. Is it more at risk because you don’t trust that the third party will fight a subpoena to the same level of diligence that you would? That’s a fine reason to say, “No I need to be able to provide that fiduciary obligation to my stakeholder.
Chenxi: I think that that is a legitimate concern. Why would a third party fight a subpoena in the same way as you would? They’re certainly not going to look at the nature of the request and try their hardest to release only the minimally relevant data for the request. And the third party provider is not going to know the business logic which relates to the minimally viable reliable data. They’re not going to go through the trouble to do that. So that is a legitimate reason.
Andy: Right. It’s not the only reason, but is a legitimate one. One of the things I’ve often found is that the customer’s looking to move their data and their process into a cloud have a nebulous concern. They don’t actually articulate it to this level, “I’m concerned about your fiduciary obligations.” They’re just saying, “Well, I’m concerned about law enforcement.” Well, we’re all concerned about law enforcement.
What are your real concerns? Are you really worried about data theft or are you only worried about law enforcement? Those are two very different problems with different solutions. And so as a result, it’s very easy to say, “Well let’s just encrypt all of our objects,” and if you can do that, then wonderful. If you have a data schema where encrypted objects were the right solution, then wonderful and more powerful to you.
Chenxi: But as you and I would know, encrypting everything rarely is the right answer, right?
Andy: It is rarely the right answer. One of the things we saw that a lot of people use the word “homomorphic encryption” without understanding its limitation. They think homomorphic encryption will solve everything for them.
Chenxi: I think that the definition of homomorphic encryption and searchable encrypted data are actually two different concepts. Homomorphic encryption is about how you could do two operations then have another operation on encrypted data. And then you can switch the operations around, you can still get the same results. And we know mathematically there’s certain homomorphic encryption operations possible. It’s certainly not possible on all mathematical operators, and there is your limitation right away. You can’t take in two encrypted streams of data, “I want to multiply them and add them” you just can’t get the same result out.
But there are technologies that do allow you to do fairly sophisticated searches on encrypted data. You can even look at some of the security conference research literature. For example, zero knowledge protection. It’s typically applied to interactive proof of identity. So I can come to you and I say, “Oh, I can prove to you I’m Chenxi but without giving you any information that you later could use to impersonate me on my behalf,” or something like that. And these are hard problems to do in normal everyday operations. There are specific applications you could do zero knowledge interactions.
Trial And Error Of the Internet
Chenxi: We have seen evolutions of the Internet security. From the first generation trust infrastructure, we added add DNSSec, and later DANE, etc. It seems like we are adding layer upon layer to solve a problem that should have been solved in the first place. Can we really trust the Internet? Is this really secure by design or secure by trial and error? And what about new threats that we haven’t even seen? Are we, as a industry, locked in a perpetual arms race situation?
Andy: On the bright side, we’re finally actually in an arms race. DNSSec has been on the table for 15 years. A routing PKI to fix BGP is finally making progress. We’re finally actually making improvements and cutting out some of the flawed infrastructure. That’s a good sign. If you could call it a bad sign that we had these problems in the first place, but you might argue that if we had built a secure Internet in the first place, we wouldn’t have an Internet as we know today.
The original Internet was used by researchers at universities and they had this very open model. At that time, everybody on the Internet was 20 people. They knew each other by name, they trusted each other. They knew about potential attacks against the system but that was okay.
I’d argue that if we hadn’t made those mistakes, we wouldn’t have the Internet we have today. If we had corrected every mistake and make the requirements to get online too extensive — you had to have DNSSec and your TLS certificate had to be pinned, and you were using certificate transparency, and you’re doing all these other things, and your website could include no third party content that wasn’t well vetted, and you could have no application security vulnerabilities on it, etc. Can you imagine such a checklist that before you get online, How many companies would never exist?
A website is a business. I’d argue that if you made that too hard to do, our economy would be harmed.
The Deep Web
Chenxi: I think that one of the things the web is so proliferate today is because we made it open. We made it easy to use. We made it distributed to a large degree where there isn’t a single authority that controls everything. So everybody can get online through a somewhat different channel.
One result of this openness is the deep web. Everybody is anonymous in that part of the web and everything is encrypted, and everything goes through anonymous networks like Tor.
How do you see the move to add security checks and balances into the web such as DNSSEC, DANE, affect the deep web? Will the deep web cease to exist or will it proliferate?
Andy: So one of the things that I always find entertaining is that if you look at the deep web and you take Tor as a good example. In many cases, the security problems that we face on the public web, they’ve already fixed in the deep web. Look at Tor hidden services and there’s already a really great way to say, “This is my name and I’m the only one who can do it. It’s already built into that authentication. I think Facebook now has a dot-onion cert, so for the first time, we’re seeing actual TLS websites showing up in the deep web built in to the public trust infrastructure.
It’s worth noting that when we talk about the deep web, quite often people jump to the nefarious actors that are on the deep web, but many have very valid reasons to want to be private that have nothing to do with breaking the laws. There are unjust laws in many places of the world for example, and actually some of the users of the deep web include our own government operatives. In many cases, when they’re abroad, they want these channels to communicate where they are anonymous. So while one arm of the government might like to do away with all anonymity-based technologies, there are other arms of the government that really like anonymity-based technologies. They see them as something that helps us more than they hurt us.
I think the Deep Web will stick around in the state that it’s in right now. I don’t think it’s going to ever take over the public web, but at the same time, it’s never really going to go away. There are going to be attacks against it. Tor has significant problems with traffic analysis attacks, that the only way to mitigate that involves reducing the performance of the network even further, which I know are things that they have conversations about.
Next Generation Innovations For The Internet
Chenxi: We discussed earlier about the different innovations in the history of the web, where do you think the next wave of innovations will come from, and what kind of problems will they address?
Andy: Many interesting and hard problems face us on the web today. The biggest one is the explosive demand for bandwidth. It’s my expectation that our children won’t ever understand what a cable plan is, and why you would watch a video based on somebody else’s timeline other than live sporting events. That IP-based televisions will be the norm very soon, but there is not enough bandwidth to distribute that.
Chenxi: My household is already cable-free. We watch everything over streaming now. Occasionally we go to a bar to watch sports events as we don’t get them over streaming. I think that’s already happening. I don’t expect my son to, when he becomes an adult, to deal with data plans and cable plans, etc.
Andy: Right now, you’re the outlier, not the norm. The Internet doesn’t have the bandwidth to support your model at the norm. And when you look at what triggered a lot of the net neutrality conversations, it was really around increasing demand for Netflix and more and more places where that was a problem. And when you consider how small Netflix’s subscriber base still is, that doesn’t bode well for the near future.
Now, there’s a lot of work being done, it’s something that we work on and others to deliver high quality streaming content to end users no matter where they are, no matter what time to get that best experience on any device. It’s a huge problem.
Another one is the proliferation of mobile devices. The next generation may only ever use tablets or phones. And what does that Internet look like when we really design around a point-and-click interface, but now it’s a swipe-and-tap.
Chenxi: Do you expect browsers to still exist in the future in the similar form as it is now?
Andy: I think there will always be browsers because I don’t see a model for you have to have somebody’s proprietary app to interact with them. That would imply a level of consolidation that would be stunning and amazing to me. Like today, I went to websites I had never even heard of before the day started. I need to have some application, and that’s a browser, where I can say go here and do something for me and hold that within a sandbox so I don’t have to give it too many permissions.
Chenxi: I have seen discussions where people talk about in the future, there’s no need to type in the URL, content would come to you based on your needs, location, and behavior patterns, etc. I can see that happen with my son’s generation. Perhaps they won’t even know what a URL is. And when that happens, I think that that trust infrastructure becomes even more important; when you don’t initiate, things just get pushed to you. Folks like Akamai may be a player to make that happen. What do you think?
Andy: It’s an interesting model. And that’s what Facebook’s model is — you’ve got all of the news that they think is fit for you, and I’m not sure that I’d like that world. Because it’s really trust in the people, not trust in the technologies. Because if you’re only ever talking to 2 or 3 people, it’s very easy to know that those were the right entities to talk to. The technology problem is simple.
The hard part is, can you trust the messages that they give to you? We just saw the third party report on Rolling Stones’ coverage of the University of Virginia case and it’s a damning report on Rolling Stones. It basically says, “You should never trust these people for news ever again.” And Rolling Stones says, “Yeah, we got it wrong and we promise not to do that again. But we’re not changing our policies of firing anybody.”
Chenxi: Well, I’m not sure you should be reading Rolling Stones for news anyway.
Andy: But people do. They read Rolling Stones for news. This became a huge story and yet we find that, like all of us, reporters walk in with the narrative and look for things that support their narrative. Confirmation bias is out there. And this is just one example. We could pick many examples that might have the same problem.
Chenxi: Andy, thank you so much. One of the final comments – maybe the reason that Internet has more or less worked for us, has served so many purposes for us, is we’ve kept it open, we’ve kept a distributed infrastructure, and there’s no single overriding authority. Even when a subset of a system is compromised, the large part of the infrastructure still works. Maybe that is an argument for us to continue to keep the Internet open and distributed and democratic for the future. Do you have any final comment?
Andy: Thank you for having me. This has been really, I think, a wonderful and a great conversation. And I think if people look for the future of the Internet, much as I’m a big fan of democracy, it’s actually more the anarchy of the Internet that I think has served as well, and there are places where it hasn’t served as well and we should learn from them. But if we try to stamp out the places where it’s harmed us, we should also pay attention to the ways that it has helped us, and to how can we keep that help going.
Chenxi: Great, great last comment. Thank you, Andy.