Ep. #10, Secure Communications with Joel Wallenstrom of Wickr

Grant Miller: Hey, Joel. Welcome to the show.

Joel Wallenstrom: Thanks for having me. Happy to be here.

Grant: Yeah, really excited. Let's go ahead and dive in. Tell us a little bit about your background and what you've been up to.

Joel: OK. My background is really centered on computer security. In 1999 I got recruited into a job at a company called @stake, which a lot of people know.

I was a fanboy of a group called the L0pth Heavy Industries that created a tool called L0phtCrack, and I actually was surprised and excited to get asked to come work at that company and come out to California and build an office here.

Grant: What was @stake, for those who don't know? Tell us more.

Joel: @stake was a group of hackers, realistically. The way they really burst on the scene, the more national scene, was they testified in front of Congress.

It's funny, they had bathrobes on and the general gist was we can drop the internet from our kitchens in 30 minutes.

That is oversimplifying the message, but that was the message back in the early aughts, that people in our industry were warning that "We're building all these systems, which is great, and it makes things work. But we can also make them not work."

So Battery Ventures, actually, got the idea that we could build a company around this set of expertise and it was ultimately-- L0phtCrack was a product.

A lot of people know Veracode is a product that spun out of this company as well, but ultimately it was a professional services firm.

Grant: Why were you a fanboy? What were you doing that got you excited about this?

Joel: I just thought it was a contrarian way to look at all of the fun exciting things that were happening.

It's akin to, I'm sure, when people were building railroads and all these big machines were going east to west there were certain people that were like "Maybe there's something that we could do weird to the tracks," or they were looking at all these nuances around this big economic engine that was being created.

This is what the L0pht was doing, they were just looking at it from a different lens. So that's a really cool mindset and something that I was always attracted to.

Grant: OK, so this is '99. It's like the environment is everything internet and everything web, and so the nation's attention is on what's going on here.

So you see this group that's contrarian and has a different perspective, and you get attracted to it, and then they recruited you. How did they get in touch with you?

Joel: I just knew the CEO, and he said "You should come join us."

My initial response was, and there's a lot of lessons to be learned in this, was "There's no way. I can't hold the water for these guys. This is a level of engineering and understanding of the full stack beyond anything I'm capable of."

But look, everybody brings a little bit to the table. So I was convinced that I could bring something to the table, and it never--

Then I fell in love with this whole idea of this contrarian view of technology, and understanding that things were going to go to market, and we're here to talk about enterprise software and enterprise businesses.

That time and that period, it was interesting. This is when Bank of America was thinking "Should I have a website?"

This was far beyond "I've got this thing and I've got to figure out how to make it secure."

It was really interesting days because the Sapience and the Science and the Vyence and Razorfish, all these companies were raping and pillaging and building the first web property for large organizations.

This is an interesting jump into enterprise, and security was 100% afterthought.

Grant: They were just focused on eyeballs. That was the key term back then.

Joel: Also, not being first-mover a lot of times. A lot of people were sitting back, and so anyone entering enterprise, you'll see that as well from a customer base.

There's all this focus on "We need a lighthouse customer, we need someone to take the leap and then everyone will follow."

A lot of people in our industry aren't old enough, or we've forgotten that there was a time not too long ago when nobody was doing anything "online." Anything, realistically. We've come a long way in a historically short period of time.

Grant: Yeah, that's cool. Then you were there for how long?

Joel: I was there for like four or five years, and then we sold to Symantec. Right after that we started a company called iSEC Partners that ostensibly was doing the same things, but we were--

Grant: You didn't stay at Symantec? You left?

Joel: No yellow jumpsuits. I wasn't selling antivirus. Realistically that was interesting, and the lesson to be learned there is that the acquirers of @stake were looking at this as solely a network security play.

And part of that was what network security products can be pulled on the back end of the expertise.

Out here in San Francisco we had built out what we called our application security center of excellence, so we were really focused on a completely different layer, even in some cases a hardware layer.

I say that because the world wasn't ready to think those thoughts, so realistically our skill set and our passion was at a different place than companies like Symantec or Cisco or McAfee were really even thinking or focusing.

It was really commonsensical for us to say "We're going to start something that's more focused on the application security layer."

Grant: OK. So then you started iSEC--?

Joel: iSEC Partners, with some friends. We did basically the same thing, we were helping large organizations understand how to secure all of their systems, but really where we had expertise was in mobile.

We did a lot of work on the Android operating system as an example, but at this point there were a lot of web and/or-- Just like when there weren't any websites, there had never been mobile applications.

Easy things, like what permissions you give to the phone, that sort of stuff. A lot of companies were jumping in without thinking about how to secure customer data.

Grant: OK, describe what one of those engagements would have looked like.

You would be working with Google on Android and your team would jump in and be thinking about it from the security angle, "How do we attack this or protect this," like threat-modeling stuff?

Joel: Boy, it was varied. It really depended upon the maturation of the security teams that we worked with. A lot of this is public now, but for instance, we worked with Microsoft on their operating systems and we weren't alone.

They would fill a room full of 12 security experts who would just sit up there and work on the next release of the operating system. Very waterfall-y, you've got to think this is in the middle 2000's, so Agile wasn't a thing.

They were doing these huge releases and they would get a bunch of experts to come in and just beat it up. This is a company that had spent millions already thinking and engineering around security, then you might go to another company--

Even fast-moving early days Google and around Android, there was no security team. It was almost a staff-off where we would come in and be the security experts.

But the vast majority of it was, a lot of it was "I'm selling this product to enterprise customers and they've asked me about security. I've never really thought that thought. Can you come in and help us?"

That would be some combination of an architectural view. We'd test for bugs, but at the end of the day we were 100% successful in breaking things throughout the 10 years of doing this, so it wasn't a matter of compiling.

A lot of companies would get tripped into having more bugs than they could squash, and there'd be this big whack-a-mole game rather than really understanding how to deal with the problems fundamentally and how to get their developers to care, those types of things.

We would do everything from threat-modeling to training to creating automated processes for people to attract bugs.

Seriously, it was a huge win in the industry when we and companies like us could get access to bug tracking systems.

Like, "Give us Jira and let us actually put security into your process." Get it in the watercooler, if you will, so that people cared about it.

Not only cared about it, but it was operationally part of their processes to put priority on things and squash them.

Grant: A fairly common practice at that point was developers build stuff and then it goes to security review, right?

Joel: Sure.

Grant: It wasn't really as integrated as oftentimes it is today, where people are trying to develop from the ground up using a lot of the same primitives for security.

Joel: Yeah.

Grant: So these are things you were probably teaching people.

Joel: If you think about web properties, and a good example is just input filtering-- It didn't exist. It fundamentally was not something that anyone who was building things thought about.

Grant: Yeah.

Joel: That brought up mobile applications, like even thinking about what permissions are given to the device or the operating system, that's typically not the goal.

You have people with big red Xs on their calendars in terms of release dates and they're just pushing for-- Hopefully not MVP, but MVP-ish type functionality.

Unit testing for security was not a thought process that existed, so a lot of it is pretty fun because what you're trying to do is stuff like this.

You'd have events, you'd do talks, you try and make it fun and cool and rewarding for people-- "People" being developers, to pull this into their workflow and their lives and their psyche. So, that's pretty cool.

Grant: OK. That was iSEC Partners, and you were a founder of this company. How big did it get? What was the scale?

Joel: We grew it to about 200 people, and then we sold it to a British firm called the NCC Group.

Maybe again, in terms of lessons learned, we as the partners-- There are five of us, and we looked at our future and we were going to have to really deploy capital into sales marketing, go to market.

Ultimately, a lot of what we did in that business-- We grew it to that size and it was all inbound, because what we were doing is our sales and marketing engine had more to do with research and doing presentations at conferences and creating demand via being smart.

Grant: Sure.

Joel: There's a cap on that model we had, and we were reaching that point where we were like "To continue to give our employees--"

We viewed ourselves as an employer as really in existence for our employees and bettering their positions in their lives and their careers, and being a slingshot for them, which worked.

A lot of them are CISOs all over the world right now and it's a really cool ecosystem, but we were going to have to become really good at filling the funnel and converting opportunities, and becoming more of a sales organization.

That's the thing, you have to be good at that, and you have to figure out how to be good at that, so we looked for help.

Grant: It was professional services, primarily. Was there any product or anything? Any technology you were selling on the back of that?

Joel: Not so much. When we were acquired there were some managed services on the back end of that, there were some testing tools. We tended to like to give away tools for free.

Grant: OK.

Joel: Really big distinction for us between tools and products, so there was a lot of intellectual property and a lot of automation, and we were really focused on doing that.

But in terms of having SLAs and licensing models and understanding how we would go in an enterprise ready way, go build products and monetize those and support those, I know we had huge amount of respect for how hard that can be.

So this was that leaping off point where we said "Look, we've got all this IP. You can create products, you can create more higher margin repeatable orchestrated services, which are like products. Managed services, if you will."

So that was the jump to NCC, and they've taken that and they've run with it.

Grant: OK, cool. You're then at NCC for a handful of years, right?

Joel: Right. Leading to where I am now at Wickr, being in security and again being a fanboy of all the really smart people, there was this concept of perfect forward secrecy.

A kind of cryptography that existed on paper and white papers and academia, but it was impractical because it was too resource-intensive.

I always like to say, "If you were going to do it on a mobile device you're going to have to carry around a building with you in order to make it happen."

But then this sneaky little Moore's Law thing happened and we started seeing it move into a place where it was practical and real, that the processing on the Node whether that be a laptop or a mobile device or a tablet or a phone, you were going to be able to have this level of protection.

The way it hit my brain as somebody who had 100% success rate breaking into every single product ever put in front of us, the main reason we always had success is everything was built to provide access to data. That's how it works.

At some point that business logic is going to exist such that you can go get it, and then you just ride those coattails. That's an oversimplification, but that's a big part of why things are hard to secure.

This type of cryptography means the service provider, in this case Wickr, there's mathematical certainty we can't be that weak link.

So, Acme Company, we would go test their service and it might be that we were able to get in through a third party, or we were able to use business logic to get access to things because the service provider had access to it, as an example.

In this case what I liked, and I used Wickr in my business-- We were transmitting zero-days and we had really sensitive communications, so rather than use old tools that people couldn't figure out like PGP, I could say to people "There's this thing called Wickr. Go to the App Store and I'll send you the document that way."

Now we can be certain that the people who are processing this data never ever have access to it, it's only on your phone and only on my phone, or only on your laptop or only on my laptop.

This eliminated very significant attack surfaces that we had always taken advantage of when we were trying to break into systems, or when we were hired to get access to critical information.

Grant: So diving back into some of the backstory on Wickr. It sounds like you were familiar with technology because--- You're not the founder, you're the CEO now, but you were an investor in Wickr.

Joel: Right.

Grant: You knew the team that was building this.

Joel: Right.

Grant: What's the full backstory on Wickr? How did it come about? You're telling us some of this, but just give us the overview there.

Joel: Yeah. I have a unique view on it as a early investor who is now somebody who's there full time, and that is-- Again, this type of-- It became possible.

A lot of what we deal with in technology is-- It even goes back to what I'm talking about. There was an internet and it was possible to have a website.

So now all of a sudden this type of different privacy was accessible and available and possible, and so Wickr and another company-- Or another product, Signal.

The two products, Signal does a one to one protocol for doing the same "Perfect forward secrecy." Think of it as extra encryption, so every single message is encrypted with a new key, which was completely impractical 10 years ago and now it's completely practical.

Wickr does the same thing, it's just a group-based protocol so it's built to do this with groups. Ultimately this means that there's an extra layer of protection if by some means somebody got access to the back end or something, then they get access to one message rather than every message ever sent.

Something like WhatsApp, there'll be a little bit of a different thing. If you get access to that now you have forward and backward access to everything that's been sent.

Grant: In an encrypted format, or is it un-encrypted?

Joel: You just have it, because you've already de-crypted it. This concept of "Perfect forward and backward secrecy" means it's a lot like a conference room.

If somebody walked in right now we'd have to bring them up to speed on what happened, and if they left they wouldn't have access to it after they left.

That's a decent analogy for what this type of encryption does. It adds an extra layer of protection.

Grant: Cool.

Joel: I was using this and I understood this to be possible, and I understood that as somebody who batted a 100% or batted 1,000, this would be one of the things that would make us not bat 1,000. I was really excited about it and I invested in Wickr, I saw--

Grant: Were you part of the seed round?

Joel: Yeah I was part of the A round, which was the same thing. Very early days.

Grant: Super early, this technology becomes possible, you had been in the industry for a while and you probably knew some of the founders and some of the folks that were working on it. You were like, "I want to invest. This seems great."

Joel: Part of it was also collegial, "I just think this is cool. We've been reading these white papers forever and I want to support this type of technology getting to market."

Grant: Like, that's the thing you believe in at your core.

You're like, "I want this to exist, and I want it so badly that I'll invest to make it happen."

Joel: Yeah. It's an important step forward in privacy. That's always-- Look, when they weren't gargantuan but we took a percentage of our profits in my previous companies and we put it towards things we believed in.

Some of that was the EFF and a lot of it had to do with privacy. A really important thing is back in the early days of encryption--

I'm just going to say SSL or TLS, when these things were starting to come to fruition and we would promote them as possible, the enterprise typically would say "No. There's too much overhead. There's going to be latency, there's a performance issue."

We would have to prove mathematically that "No actually, there's not. This is just smart. I know it might be a little bit of a pain in the ass to change what you've done in the past, but this is better."

Now it's drinking water, and to a certain extent we're smart enough and fast enough on our nodes to be able to do this at the edge, if you will. I really believe this type of protection should be like drinking water.

At the user conference and developer conferences this week Apple said the same thing, like "Look. We're capable of doing this and it doesn't introduce any performance issues, so we're going to do it."

Now they're doing it because they think they're going to sell more shiny phones, and I don't know-- They should be unapologetic about that. That's great. That's their business model, but the key takeaway for me there is it's possible. It's doable, so let's do it.

When I invested in Wickr the first thing-- This was a very cool thing, it was very focused on journalists and people overseas in hostile environments, and the thickest of the thick tinfoil hat users.

That requirement drove the product decisions, which meant it was completely anonymous, which meant that nothing lasted more than seven days a week, so it was a very smart and appropriate tool for very advanced users.

People who understood what a handle was, and then what ended up happening and the reason I'm here at Wickr is it leaked into the enterprise but the vast majority of the enterprise doesn't know what a handle is and the vast majority of enterprise projects last more than seven days.

It turns out a lot of enterprises have these pesky little things called "Regulators" who have data retention requirements, and the practical realities of using software in the enterprise were misaligned with this heavy tinfoil hat free messaging app.

The call from the enterprise, when I entered there was already a product market fit in so much as people were saying "I need this level of protection, I just don't know how to build it for the enterprise. Can you do that?"

So that's been my task, and the team's task over the last two years, is to build something enterprise ready.

Grant: Cool. So when Wickr first launched, pure consumer-oriented, just in the app stores, was there a desktop app at that point too or was it mainly--?

Joel: No, it was just a mobile app.

Grant: Just mobile? Like a secure way to communicate-- The most secure way to communicate, realistically.

Joel: Yeah, exactly.

Grant: Different rating organizations always give Wickr the highest ratings in terms of privacy and security and safety.

Joel: A really key thing there in terms of the product vision there was it needed to be and it had to be anonymous, with anonymity being the polar opposite of virility .

There's this other product I mentioned, Signal, where the decision was "We want to be viral. You're not going to be anonymous, it's tied to your phone number.

So in fact if you get it, it announces to everybody 'I'm on this thing and I'm using this product.'" I'm not saying it's a bad decision, but for a certain user group that was not what they were looking for.

They needed to be more of a needle in a needle stack if they were over in a hostile geography, so anonymity was a really big important part of that. Turns out that to deploy in the enterprise, anonymity is impossible.

I used it in my "enterprise usage," but it was a relatively small deployment, and there are definitely customers who've used things like naming conventions around handles and figured out ways to almost in spite of the anonymous product figured out how to use it in an enterprise fashion.

But that's not the goal of the-- We have a Wickr pro product that is enterprise, and so it's been all about building things that are required by the enterprise.

It's a pretty big pivot and it's been fun, and a lot of it is helping people understand what their requirements are so we can build them and execute against them.

Grant: Is it one team builds both products, or--? How do you think about--?

Joel: That's really important. There were some surprises along the way, but we're a 40 person company and so the thing that we needed to do was build effectively so that we could support efficiently.

That meant getting everything on the same back end and getting everything on the same code base, sharing the same protocol.

Building and supporting multiple products is a slippery slope to really inefficient capital expenditures.

So that was the first step, is to say "We're going to have different products and different customers, but how do we do this efficiently and how do we make sure that we're not supporting more than we can handle?"

Grant: OK. You started to feel this pull from the enterprise, so that was-- I love the idea that there's some companies, and even you yourself when you were at NCC, you were using it in some enterprise ways.

But you saw some patterns that people were doing. I love the idea of how they were probably pre-fixing a handle in order to make it an identifiable handle.

So you saw some of this, like "Look. There's demand from enterprise." Maybe some customers brought use cases to you and said, "Look. If we had an enterprise version of this that we could control--"

So, what are the core features that you added in to pro to make it enterprise-y versus consumer? I think that's always really interesting.

Joel: Yeah. We'll talk about features, because that's what you asked, and there's another element I'll get to in a second which is in terms of deployment.

But on a feature basis, it was actually pretty stark to us and to our customers that when you're in enterprise software you're in the software deployment business first and foremost. How do you get 10,000 people the software?

Grant: Yeah.

Joel: Because if you can't get it to them then it becomes problematic. So SSO became the first thing.

Grant: Great.

Joel: That was the thing we had to do, which-- That's not a light lift, and it's certainly not a light lift also from a mindset.

When you have an organization that thinks "We just have to get this thing up on the App Store and we're good," that is not necessarily how the enterprise thinks about software and software deployment, and it's certainly not how IT organizations want to control it.

So really quickly on the back end of that, we were-- I don't know if we were forced, but it became obvious that we had to then--

Grant: So, when you joined there was there was no pro offering? It was like, "We're going to come in--" You didn't even probably have the idea of teams where you could invite people to come into a workspace or something, right?

Joel: Yeah. There was a way to basically input into-- You could input handles into a CSV file and just upload it. That was the thought process.

I don't have metrics on this but I would say it's probably a pretty standard way to get MVP-ish, would be my guess, in the history of deploying software. But that's not going to work.

Grant: Initially the product was all mobile, so now you at least need a website or an admin--

Joel: An admin site.

Grant: An admin site where you can go in and at least upload a CSV.

Joel: Yeah, exactly.

Grant: So it's like, "Step one. Create the admin site." OK, now you add some features in like "Upload CSV" and then you start moving into SSO, or I should say "Single sign on."

Joel: Right. In terms of the way we looked at the business, "What's the line of demarcation? Where's the breaking point of uploading CSVs?"

It's certainly somewhere less than 10,000 people or users. The initial use cases that came to us were "We want to offer this to the enterprise."

Grant: Did you have design partners, like did you have early customers that were like--?

Joel: Yes.

Grant: OK, so did you talk about who those were or what the use cases were?

Joel: We're in the security industry, so a lot of the customers tend to be pretty opaque, but big professional services firms--

Which brings up a really important feature, and that is what we call "Federation," or the ability to talk outside the network is really important.

So a lot of what this was where I personally saw Wickr being used before I got to Wickr, was threat intel teams across different organizations who wanted to like, "I'm getting this signal and I want to ask if people are getting the same signal."

In some cases there are regulations where people are not supposed to share information with other companies, but they wanted to do so in a manner where they thought it was fast and secure and private. They're trying to fight bad guys in real time.

Grant: So, "We're getting this attack from some IP address over here. It's based in Pakistan, and we got to look at it. Are you seeing the same thing?"

Joel: Yeah.

Grant: Like, sharing some information in order to collectively battle.

Joel: Yeah.

Grant: So Wickr became a place for those security IT professionals who were using-- Then they were like, "OK. We want to do this at a bigger scale, we need to get the rest the team on, we need admin tools and things."

Joel: I'd say this has been historically common. IRC was something that was used in the past. Certainly people use Wickr now, they use Signal, there's always been this desire.

One of the really cool and gratifying things about the security industry is you hear people say "You only have to be not the slowest."

If eBay wants to be a little bit more secure than Amazon back in the day, or whatever. But at the same time as much as there was competition, we're all helping each other.

Grant: Sure.

Joel: You see competitive financial services firms, you see competitive e-commerce firms really sharing information.

Especially, maybe not at a CISO level, but the people who actually do work and get stuff done who are in the trenches are always talking to each other.

They would use tools like this to do that. An important part was not just to deploy this to my folks, but give me the ability to allow people to talk outside to whether it's lawyers, or threat intel firms, or whomever that they may need to talk to.

Grant: You're saying, by working with professional services teams early on, by default those teams are working with lots of different groups across--

Joel: Clients.

Grant: Yeah, clients, and then third party teams as well. They have both clients and contemporary people they collaborate with.

Joel: In my days, if I was sending a message saying "We found a zero-day in the thing and you need to patch this," you don't want to do that in an email. You just can't.

An analogy to that is, "We think the price on that company you want to buy--" If you think about corp dev and people doing deals, same thing.

Oftentimes there's software built for that which is just really flimsy and terrible, and so they would turn to these products to basically have really secure conversations about really meaningful projects that were going to have impact on market cap.

If you're a professional services firm and you're emailing those documents internally or externally, you're just exposing things to people who want to benefit from that information.

Oftentimes that can be nation states, but it doesn't have to be. There can just be people who are smart and understand that sitting on deal flow is a really good way to make a nickel if you're smart about it.

Grant: Yeah, sure.

Joel: That's another way that if you're a large professional services firm or an investment banker, or something. A law firm--

Grant: Prevent insider trading information from leaking to people that might use it.

Joel: Yes. An enterprise requirement was SSO, but very rapidly we then needed to accommodate things like 2-factor authentication, mobile device management, the types of things that are just inherent to the way that company handles software.

But also, once we started talking to lawyers, there are real needs to keep things certainly more than seven days, and sometimes for longer. There might be a regulatory need.

The real trick and the thing that we've done that is very unique in the market is we've given people the ability to essentially proactively enforce data deletion and retention policies.

Going back to that core principle, we never have access to it. The service provider isn't saying, "OK. Cool. You want to retain this? We've got this for you."

We flip the bits and we make the data transfer happen, but ultimately they always maintain ownership, so if something needs to be dropped into cold storage and encrypted for regulatory purposes they can do that.

They can keep it and keep it protected, and we the service provider never provide an attack surface, which is pretty cool.

Grant: Yeah. I think about this a lot in terms of, "How do you secure data and do it well?" Because the other solution that the enterprise tries to bring, and Box and Salesforce talk about it, it's something they call "Enterprise key management."

Joel: Right.

Grant: This is basically where the enterprise has an HSM, a harbor security module, and then they create unique keys. Then the trick is that these SaaS services like Salesforce or Box can make a request at that HSM and get a new key to basically de-crypt all your information.

For some cached amount of time they have all your data in an un-encrypted fashion, and in memory all of the data is un-encrypted. They could log it out incorrectly, and so they have access to un-encrypted data.

I would say it's like that shell game where you're moving a shell-- You still have to trust the vendor.

In your case right with Wickr, you're like "No. We provably-- You don't have to trust us. We carry the encrypted bits to and from, but we can't ever see them."

Joel: Yeah. I don't think necessarily this idea of centralized key management is 100% all bad, but you've nailed it.

At some level it requires management, it requires human oversight. It's cool to rely on math.

Like, that was my thing. I got to this point where I thought, "Here is a problem that exists for a real significant set of users where you can solve it with math rather than process and procedure."

Grant: I love that.

Joel: That's cool when you can do that, and when you can simplify that and deploy really smart resources to other problems, because we're all in a finite resource bind here.

I like the simplification of this. People are moving really fast towards trying to figure out how to move that shell game and make that as fast as possible, and I get that, because when you architect a system that is reliant upon that you're forced down that strategic path.

I get it. But there is a point at which simple is good, so that's what we're doing.

Grant: That's really cool. You said something that was really interesting, dive into it if you can. MDM, which is "Mobile device management," I think you're the first person we've had on that's really been a mobile-first enterprise software company.

Joel: Right.

Grant: You'll see more and more of that, there's all these apps are really mobile-oriented. Talk about what MDM is, like what is it? How do you do it? What's the value it brings? How'd you hear of it?

Joel: OK. That's pretty nuanced, because I do think that there is a population of security experts out there who is seeing diminishing returns on this concept of mobile device management.

However, for anyone who wants to get into the enterprise with anything mobile, it's a requirement. What it is, is mobile device management.

You, via MDM as an IT shop can manage what does and does not get on to the mobile device, so you're controlling what software exists and it's like a white listing or black listing of things on the device. I'd look at it that way.

Grant: This is built into the operating system? iOS and Android have native MDM, or do you use a third party MDM?

Joel: That's the really interesting question. For most, it was always third party. There's almost this branding thing that's BlackBerry-good.

Good software was mobile device management, it was on BlackBerries and people think about it as being one thing. But it started off as two separate things.

Just like antivirus, antivirus is dead because Microsoft and Google and people are just saying "We'll do this native to the operating system," it is very much becoming more and more native to the mobile ecosystem, if you will.

So iOS will-- You can control what software is on your devices, you're not going to need a third party going forward, so you're seeing MDM software getting--

Grant: Baked into the--

Joel: Baked in, getting acquired. However it's this, in a lot of cases, sometimes unwieldy legacy software that large enterprises-- Once they go through the process of getting something working they're pretty anti-unplugging it and going to some other process.

It'll be around for a while, so one of the things is the challenge for us is we go to Acme Company and they're using one MDM provider and we're going to Bacme and they're using another.

Grant: So, what's the product? What are you as an application developer--? Is it shipping to a different app store? What's the difference from your perspective when you're developing?

Joel: Ultimately from a process standpoint, what matters to us is there will be a team ostensibly in the IT organization that's responsible for-- It's not white listing, but having MDM accommodate this software.

We have to basically be accommodated, we have to go through that process and this whole-- There'll be some vetting.

Like, "Have we looked at these guys? Has there been a security assessment? Do we have approvals? Have they gone through the chain of command to be approved?"

Then we have to essentially give them a "build" that accommodates their mobile device management strategy, if you will.

Grant: Maybe you have to like build specific SDKs into your apps for these different platforms or different APIs?

Joel: Yeah, there are hooks. It's all been-- Yeah, it's an API. It's usually IP.

Grant: These are some standards that you, as a application developer delivering a mobile application, need to have to probably expose some end points in your application and hook into some things.

Joel: Here's a good analogy on the SSO side. There's something called "Open ID," which is an industry standard.

People have looked at this and said, "Man it's crazy to have to go through this process for 100 different MDM providers, or SSO, whatever. Let's come up with some industry standards."

Oftentimes you can lean on something like Open ID to say, "We understand that you need us to accommodate your software security strategy that includes SSO or MDM, whatever the case may be. We write to these open standards and we can do this." Usually, that's enough.

Grant: I love this. The whole point of Enterprise Ready is to provide the guidance and insight into the features you have to deliver as an enterprise software company.

I just hadn't really thought about it from the mobile side, even though interestingly my previous company was in the mobile enterprise space.

But we were an SDK, so we weren't actually delivering an app to the app store, we were delivering an SDK that you could build into any app.

But this idea, if you're going to build a mobile first enterprise software company, you need to understand how to integrate with MDM and do that-- You're basically saying it's a core requirement. You're not going to get very far without doing that.

Joel: The alternative is that you are shadow IT. That runs a little contrary for our go-to market, because ultimately what we're saying to the enterprise is "You've got this shadow IT problem."

One of our financial services customers took-- This goes to that "Who's going to jump first?" None of the other banks were really doing anything other than turning a blind eye to the fact that consumer apps like WhatsApp and WeChat and Wickr and Signal existed.

All of those things existed out there, but "We're just not going to have a point of view on it because we're not ready to have it."

Then they were doing real-- There's real deal flow going down on WeChat, so they're sitting back looking at this saying "Wait a second. People are using their own devices to do real commerce?

Significant deals for our large organization on a product where we have no access or control, but the Chinese government does? That's not a sustainable place for us. What are we going to do? We have to deploy something to--"

Grant: As an alternative. To provide the same functionality, but within the control and purview of the enterprise.

Joel: The key, the really interesting and hard thing here is that when they deploy something, and they say "Everything is being watched and recorded," then they're squishing the balloon and sending people back to WeChat.

What we do is we give them a hybrid approach to say "Grant wants to talk to me, his employee, about a health care issue."

There are rules within our organization where some things are completely private and we'll never have access to them because we're using a service provider that never has access to it.

However, if we're talking about something in a regulated deal or in a regulated part of our business, we're going to turn on retention because-- We're going to show you, we're going to signal that to you in UI, there's no surprises.

We're having an honest conversation with you and that has to be retained. If you don't provide that hybrid approach, if you just keep doing this thing where you're like "Here's a secure thing, but we're watching everything."

Then smart people in your organization are like, "I'm not going to trust that, because now I love my IT guys, but they're going to leave a hole. I can't let our adversaries get access to that so I'm going to go use this thing out of the App Store," and it just keeps fluctuating back and forth.

We're attacking this from a very different standpoint than people have in the past, which is "I have to give you this--" As much as MDM is a requirement-- I saw a study where 60% of titles at Citibank have compliance in them.

People are not-- The enterprise does not say "I don't care about the regulators."

If they're regulated they care a lot, so giving a solution, that was a really big requirement.

Then the thing that surprised me most, the other requirement I wanted to get to was, my day one I was like "OK. We are not going to deploy on prem because that'll be too hard."

Day two I was like "OK, yes we are. All the signal from the customers who care the most about real security have requirements, whether regulatory or otherwise. We've got to deploy on prem in our own cloud, or whatever. They can't just go and stick a thumb in the eye of the people who regulate their industry."

Day two we were trying to figure out how we were going to containerize our software, and that had never been done before by us or by many of our employees.

That in and of itself, I know that's near and dear to your heart, but that is a thing I can remember just sitting back and thinking "I didn't think about this. How are we going to do this, and how are we going to do this in a manner that 40 people can still live and breathe while delivering software to their customers?"

Grant: It's one of those things. My previous company I mentioned, we were enterprise software. I didn't get it. I didn't get on prem, I thought everything would be multi-tenant SaaS. Then as soon as I started to really understand--

I was actually a pain in the ass to our security guy, I was using shadow IT and I was the worst.

Then as I started understand a little more, "Wait. We use GitHub enterprise, why is that?""Because all this data would go un-encrypted in GitHub," and I was like "OK. You don't want that."

I started to understand it a little bit. I was like, "Man. I was an asshole." I actually apologize to our former security leads. I was like, "I'm sorry for the transgression-- My former transgressions."

Then we figured out "Software can be deployed on prem. There's a bunch of new technologies that are emerging, Docker and Kubernetes and all these things just make it so much easier than it would have been 10 years ago."

We've been stoked to work with your team. They're super smart and they've been incredible.

Joel: Yeah, the team at Wickr I just am enamored by. It's been so lucky to work with them, they're all very smart people.

This is not what we were used to delivering though, and so the first board meeting I had I said "Look. We're approaching this problem like we're restocking a Coca-Cola machine, when ultimately our customers want us to launch a space shuttle."

It's a very complex and important process. We have customers that keep a lot of people alive, so all of a sudden we got thrust into this niche where we had to deliver really important software to really important customers, and we'd never really containerized something before and given them a build.

We don't even touch the environment in which-- We never see it, we don't know anything about it. Part of it was scary and a lot of it was invigorating, to say "This is going to be hard."

We were weeks in terms of getting releases out, and I mean that going back and forth with the customer. With the help of you guys we're at 15 minutes, or 10 minutes. We can get this done fast.

A testimony to what Replicated does is the market mandated this. So, this is what happens. People can have visions of grandeur of "It's all going to be multi-tenant and the world should just drink from this this cup of goodness."

But the reality is enterprise has to do certain things, so there is a huge void for companies like Wickr to say "How do we do this? How do we use Kubernetes to make this a company that can stay 40 people rather than be 200 people flipping process, if you will?"

It's been really impactful, and the coolest thing is to watch our customers on the other side.

It's release time and they've gone from "Here we go again," to "This is cool. This is great. I know that I'm going to be able to get something that's predictable, I'm going to get it out there it's going to deploy, it's not going to be a huge suck of my of my resources and we can get on to doing our important work."

Grant: Focusing on the enterprise IT admin and trying to make their life easy has been-- No one really thinks about them.

You think about end users because you want end users to have a great experience and people build for that, but the IT admin is often a little bit ignored, so we wanted to deliver something that would be a really pleasurable and great experience there.

Joel: They're ignored, and they're human.

Grant: Exactly.

Joel: All of us, what we really like a lot are our W2s and our weekends. If you give them a process that is destined to be off schedule and viewed as not successful, that sucks for their W2 and that also sucks for their weekends.

Everything's not just down to W2s and weekends, but I think about that a lot in terms of our enterprise customers and the people who are responsible for deploying and managing the software.

If we don't make their lives easier then that's difficult, because there's a whole train of software products just waiting to make their lives more difficult.

Grant: This is actually one of things I love about enterprise software in general, you can deliver great experience-- We spend so much time working.

This is what we do with 40 to 80 hours of our weeks, we spend it in an office doing work and we deserve software and tools that are going to be great, that are going to be easy to use and they're not going to be the cause of our pain.

Joel: Right.

Grant: When we get to come in, and a thing that you said too is acknowledging when you're talking about the difference between jumping between a secure app and a non-secure app, and you're using both of these.

This mix of the company provided app that was totally monitored versus now they go to some consumer app that is totally secure.

What Wickr did is just acknowledge that the world is not black and white but it requires shades of gray, and by providing a solution that allows for the shades of gray to exist.

What you're doing is you're really making everyone's lives easier and better, and they can get better work done and they can actually meet the compliance requirements, because compliance is serious.

You go to jail if you do it wrong. So, it's fun to do that stuff.

Joel: There's an anti-sales pitch on that for Wickr a little bit, it's that I do think we make people's lives easier, but you brought up a really good point. You have to have a point of view in terms of what those shades of gray are.

One of the things that's been very interesting in the enterprise is we say, "This is actually mathematically certain enforcement of your data retention and data deletion policies."

When people don't have them-- To a certain extent there's some customers who look back at us and say "I've been meaning to get those data retention and deletion policies," but that's important.

That's why it's a really-- That's one of the things that I'm enjoying about this is we can go in and say "Take a deep breath. It's not that hard. You have them, they exist. Everyone has some set of information governance policies, so use this. It can help you enforce those.

Maybe you do need to be a little more mature in terms of data segmentation and understanding how data is going to be handled, but the alternative is right now people are just handling data in one way.

There's just one fashion, and maybe they go back and they try and retroactively enforce some viewpoint or shade of gray or policy on data, and that's not a winning process here.

We've got to understand organizations are going to be-- We're seeing GDPR do this, obviously what FTC just did to Facebook, although really that's not even big enough or enough, the downgrading of Equifax.

We're starting to see regulators come in and say "We're going to increase the liability for you neither having a point of view nor enforcing it."

Again, going back to that ease, I know what we're doing is we're giving technology to IT shops and compliance shops to say "We can deploy this and we can go back to a regulator and say, 'No. It maps exactly to our policies.

Now you may tell us we need to change our policies, and that's fine. Then we can change the way we deploy this thing. But we have something that's enforcing this so we're being as responsible with the data as we can be.'"

Grant: It's interesting because it's both. The funny part is there's some requirements that you need to keep data for a long time, and there's some requirements where you're like, "No. We need to get rid of it faster because it's sensitive and you don't want to actually have it around," and being able to enforce on both ends is really cool.

Joel: The key here in a lot of cases is where it's retained. It doesn't have to be on the endpoint, it doesn't have to be stored locally. There's no reason why it can't just be pulled down and put into cold storage. There's a lot of--

One of the things that I brought to Wickr from an experience standpoint is as I was wrapping up the career in the professional services world around security, it was the advent of e-mail retention policies, and we would go and say "You should probably not retain everything forever. Server side or certainly on the client side."

We would enforce these 30 day, 60 day e-mail retention policies, and invariably there were executives who'd yell and scream and say "I can't do my job if I don't have access to all the old stuff."

Because it was a change and it was a really scary change for them, and ultimately all you had to say was "No, we've got it. It's somewhere. If you think the world is going to crumble if you don't get access to the thing, we've got this thing air-gapped and I'll go through that process with you to get it."

It was just that assurance that made people start to operate down the path of this retention policy, and then it just died down. Nobody cared. They started operating in a more secure fashion, the non-Podesta fashion, if you will.

That's one of the things that we're doing as well, we're saying they look at a tool they're like "Wait a second, this stuff is gone after 90 days or a year? What if I need to go back to look at those deal terms in seven years, or what if the regulators want to?"

You just air-gap it. It's just gone, and it's encrypted, and more than anything else-- I'm going to go back to it.

Wickr never has it, so the one thing that you can eliminate is that is a service provider and that's an attack surface that is just completely eliminated. So again, that's different.

Grant: It's interesting. The regulatory environment is always really interesting. The stuff that we've seen with GDPR and with the California Privacy Act and some of these other ones, it's just making people more aware that data is--

We always thought about it as an asset, but it's also really a liability for anybody that has it. You have to understand how you're storing it and what you're doing with it, because we just see constantly that people mishandle this data.

One of the ways to not mishandle data is to not keep it.

Joel: Right. Historically people have been tuned into that, but if you go to some place like Google and if you have a data balance sheet the upside is it's more of an asset than it is a liability.

Grant: Sure.

Joel: They get a $57 million dollar slap on the wrist related to GDPR this year and it's a celebration. It's like, "Oh my God. That is the least punitive thing we could have ever imagined."

Now there's every indication that you're seeing that liability increase, so again, these are smart business people so this metaphor of the data balance sheet is a real thing.

As liability starts to increase they're going to look at this and say "Wait. There is a risk to keeping everything."

I always use the example of Netflix doesn't need to know, or I don't think they want to know that Joel Wallenstrom watches Gilmore Girls on Tuesdays, or that I'm a Gilmore Girls fan.

They do want to know that for a very short period of time so they can aggregate it with all the other data and make really smart informed decisions.

But it immediately starts to carry liability as soon as there are proper nouns and locations and anything that can be attributed as a breach in privacy is going to become a thing for them.

I'm not saying the data is not important, I'm just saying keeping it forever and the liability is starting to increase.

That's the hypothesis here, is that that liability is going to-- Look, Elizabeth Warren wants to break up companies realistically on the basis of their irresponsible data protection processes.

At least that's part of it, there's a competitive aspect to it as well. But that starts to look like a real liability.

Grant: Yeah, it's true. Going back to something interesting you said earlier, you mentioned that one of the things that you do at Wickr is around Federation. In talking around the same concepts, we're really excited about a new technology in the Federated machine learning space.

TensorFlow just announced TensorFlow Federated, they did a really great cartoon comic strip about what Federation is, and I actually learned things from it."

This is a really interesting and exciting technology because basically what it does is it allows you to actually have machine learning that is learning from all this data, but the data never has to leave the different devices.

You can keep it all locally in Wickr and you could learn how to actually know predictive text and stuff. Then once it's learned, then you send up these learnings to a server where they're further anonymized through some crazy techniques that I learned about.

They basically mix in some zero sum stuff in order to never have the data actually be raw in itself. But when you add it all together and aggregate all together it zeros itself out so you get the real patterns.

Then you learn from it and then you send down new algorithms to all the devices and you keep learning in this way. But this is a really interesting technology, it is truly privacy preserving.

You never have to centralize any of the data, so you're never sending anything but totally encrypted data through a server. But on the devices, you can have true AI and ML.

Joel: There'll be voices who say or would have said, "Why do you even go through that process if nobody cares about protecting that data?" This is a signal to "You are not going to have access to markets if you don't treat data the right way."

So that's what's really punitive, somewhat GDPR is trying to accomplish and even this idea of antitrust, I don't know that I buy into that.

The real penalty is not giving access to a market. So it's almost like the serial data abusers have an anklet, an ankle bracelet that doesn't let them out of the "I'm going to abuse your data" house.

They can't-- The most damaging thing that can happen now-- Something that I take-- I don't if I take pride in it, but there's validation in Mark Zuckerberg saying "We think the future is completely private, small group conversations."

That's what we are doing, that's what we've been doing forever. Again I don't think that's philanthropic, I think he sees from his data what customers want down the line.

People ask me if I'm worried about that competitively and quite honestly, like we talked about earlier, we're all in this for privacy.

That is a genuine statement and I welcome more and more organizations providing that level of privacy, but if people are just making that an advertising campaign and lulling the enterprise or the consumer or whomever into this false sense of privacy, then there needs to be an ankle bracelet.

That's where regulators could come in and say "No. You've defined yourself as somebody who abuses data. Consumers or enterprises can make their decision to work with you, but you can't go out and advertise that you're protecting data."

Because there are, like we're doing and like Apple is doing, there are ways that you can do this mathematically and if you're not using those techniques then realistically you're not protecting it.

Grant: It's interesting too, because some of these things-- TLS is a great example, it's the kind of thing that people can grok pretty easily, where the end user experience is the same.

You just go to sites and it all looks the same as if it's encrypted or un-encrypted in transit. You don't really know that it's happening, but it is protecting you.

It's behind the scenes and so these things that are happening behind the scenes, it's almost like it's too seamless. Wickr feels like any other chat, which is good, but it's doing so much more in the background.

Joel: Right.

Grant: The thing that I love about TLS, they have done some interesting stuff. Even if it's little, the browsers built in the little locks and the green and the different colors.

There's ways to show that "This is encrypted," or just the idea that the devices or the client need to display something a bit more like abruptly to let that "You're actually sending un-encrypted data beyond."

There's stuff that will come together to help make this more obvious, but it's one of those interesting challenges where you're like, "We made it so easy and so good."

Joel: This is a really important aspect, and for people listening to this who are trying to build products, UI/UX matters a ton. So some anecdotal experiences I have that are right in line with what you're talking about before my Wickr days I got access to--

We did a lot of work with Google and there were some security-focused UI people, and you talk about the lock-- They'd do focus groups and they're like "I like that shopping bag."

The point being, it's really hard and nuanced. You've got to understand that you're going to have to get that feedback.

We did this thing, ultimately I'm responsible for this misstep, and that was one of the things that we understood from our customers is they liked the fact that we went to extra measures to essentially remove data from the device to shred it.

We called it "Shredder," and there were multiple layers of shredding and we figured out how to do it faster.

My thought process was, "Let's just give everybody maximum shredding and let's build it into the product and we don't have to take up that UI space or that decision making tree for the consumer to be like 'Do I want to shred? On what frequency do I want it?' We're just going to be the world's best at this and we're going to bake it into the product."

The second we took out optionality around shredding, people were freaking out. What they were saying is "I like to push the shredder button, that makes me feel comfortable. That gives me a sense of security."

We would respond and they would typically, via Twitter via customer service, we'd say "We're just doing that for you." They would ultimately say "That's great, but I want to see it happen. I'd rather do that."

That's something that we constantly do. The messages used to burn, they literally would, we would have animation of fire or smoke and we didn't think that was very enterprise-y.

Ultimately the data we get back from the enterprise is they're right. We don't necessarily need that, but there is still a population in those enterprise customers where "I thought that was fun. Can you make the things explode again?"

There is an interesting balance between building products and building products that do things well, and how you engage with the customer and how you engage with the consumer versus an enterprise customer. It's very nuanced and important.

Grant: Yeah. It's this interesting balance, because when you add enterprise in now you instantly have not just an end user but all these intermediate users that could be anything from the admin, to the IT admin, to the executives.

You have all these different layers and ultimately the end user, you want them to use the product and love the product, but it seems to be the consumerization of IT that they don't always write the check.

Sometimes the CFO is like, "Why do you make these animations?" You're like, "OK. We'll pull it out." Then all of a sudden it's like--

Joel: The user base is like, "No." Something that we've done at Wickr over the last year and a half two years is--

Again, I talked about it being the most tinfoil-hatty product, so one of the things was there was a promise that we did this thing from the very beginning. This is a very different way to look at security for a software company.

We did something called "Security promises"and I'm going to get to what we're talking about here in a second.

But that ultimately meant that we were going to say "All things being equal we're going to make these promises, and it's going to be very binary.

We protect your data and we're saying we protect this data because we're making this assertion that we encrypt things in this place."

Using an example is a verifiable statement so we have third parties come in to verify that we're doing the thing that guarantees that we are keeping that promise.

We make all of these promises so that we don't have to have a 50 pen test for every customer that comes in. We're placating that enterprise user and what their requirement is on a security basis.

But that doesn't necessarily mean that the end user is telling us what they want, and it also doesn't mean that we can't listen to that end user, so part of the real tinfoil hat was "We'll never get signal back from the clients as to what button is being pushed."

Grant: Right.

Joel: If people are pushing the shredder button they don't really care if Wickr knows that.

That is not an invasion of their privacy, and we're going to tell people we don't think that's an invasion of their privacy and we're going to be very open that we're going to look and see what buttons are being pushed so that we can accentuate those features for them.

Grant: Sure.

Joel: But in the sake of privacy, originally, we were like "The hypothesis is we'll never know what anyone's ever doing with the product and we're going to build a good product."

Boy, is that-- Talk about running into a forest with a blindfold. That's a tough one.

Sometimes there's too much security, and you have to be objective about this and say "I need to be able to go talk to the customer and see what the customer is doing. If they ever came back to us and said "I don't want you to know that we're using this feature," then we could always change.

But ultimately that's what they want. They want to have that conversation with you, and you don't have to-- In our case, that doesn't make their communications any less secure, doesn't make their file transfers any less secure, their video conferences-- It does none of those things.

If we know that everyone is doing screen share and that's the most important thing for them, then we're going to keep innovating around screen sharing.

Grant: Yeah, it's a nuanced balance though because you don't want to pull out too much information. Obviously there's a hard line around any content, but how about the length of every message? How about the size of files?

There's different things that you're like, "That would actually be useful so we know if we need to do at larger file transfer size," but you're like, "I don't want to--" So then you end up just incrementing it, and you're like "OK. Let's just do categories. Is it anything--? Are people trying to send stuff over 5MBPS or something?"

You start to balance it back and forth, but there's a lot of thought that goes into deciding that.

Joel: It's funny, for a very secure company that basically says "We're not going to give people access to information," we're really rooted in transparency in terms of how we communicate with our customers.

Getting it 100% right is impossible, but we can always do is be 100% transparent with everybody in terms of how we deal with these issues.

Going back to enterprise software, for people out there who are trying to understand how to build products, you're never going to build a secure product that's going to meet everybody's criteria for security.

But have a process, be honest and be open and show that you have the ability to fix things fast, and you have the inclination to not snake oil people.

That's going to end up really-- Ultimately in the enterprise sales cycle, when that type of approach hits their team who's doing the evaluation, that matters more than perfection. Because perfection, especially in anything that's even remotely agile, who cares what it looks like Tuesday the 4th at 3 o'clock?

You have to show that you have a process and an organization and a will to continue to push the envelope and do the right things, and communicate it honestly with the customer.

What we do is we just don't want to surprise anyone ever. That's a bad business for us to get into, we are in the trust business so we want to be really transparent with our customers about everything we do.

If we ever do something, or if for some reason all of our customers say "It's untenable for us that we're using your product to make video conferencing calls," then we can change. We just really commonsensically don't think that's a problem.

Grant: Yeah. That makes total sense. Joel, this has been amazing. I've loved the conversation. I could ask you a million more questions and we could go on for hours.

Joel: We'll do it again sometime.

Grant: Yeah. I'd love that. But before we go, I just think it's really interesting to hear how CEOs do the elevator pitch. What's the pitch you give in one or two minutes, or whatever you want to do--?

Just tell us what Wickr does in your own words. I just think it's really interesting to hear.

Joel: OK. Wickr takes a different approach to data security in so much as we are a service provider that never ever mathematically certainly has access to any of the information that's being transmitted on our platform.

That's a very different type of security that can be offered to customers who typically really care about this and have big either corporate market capitalization risk associated with being "owned by adversaries--"

Or, let's just say their lives are on the line, so it's a different way of transferring data. When we first looked at this as a need, what we saw was communications.

What we do is we provide messaging, team collaboration, channels, groups, video conferencing, file transfer-- Anything that you can imagine in a communication or collaboration product that is completely secure.

This is oftentimes used to replace email or other virtual collaboration products, but it's also used as a complement.

We view this as something where we're very focused on integration, so our customers build integrations into Slack or into other products so that they can secure the conversations and still use other products as well.

Something we haven't talked about that's really key to our strategy is as a smaller software company what we really are is a platform.

We have customers who are building and we're exposing the capability for them to build their own customized workflows, so in a lot of ways what we are is we are a platform where you're one step away from building your own end to end encrypted workflow.

We're seeing people use orchestration with swim lane or phantom or different products to build orchestrated incident response processes.

We see executive teams using our platform to distribute sensitive information on an orchestrated regular basis to executives so that it only goes to their phone and it only lives for a certain amount of time on their phone, providing an extra layer of security.

The real sales pitch, and the real elevator pitch right now, is we are a really secure collaboration product but the future that's really cool is we're giving developers the ability to build their own workflows on top of our platform.

That's probably, from a vision standpoint, the most exciting and fun part of the company.

Grant: That's really cool, I was actually thinking there was probably a big opportunity to do that in our earlier conversation. That makes a lot of sense.

You're offering this primitive encryption, secrecy primitive that other folks can build in the workflows. Because as we were talking I was thinking through lots of different use cases, so that's really great that you guys are onto that.

Joel: A good example, the one I use a lot is AWS offers Lumber Yard for game developers. They just say, "Come and build. We're giving you the tools. We're not the best game developers, but we're going to give you the tools to build whatever you want to build."

We can't think of every circumstance where people have a need. Communications is a commonsensical one, and that's where we started, but we want to give people the ability to just build what they need to build and orchestrate what they need to orchestrate.

To do it and not have to worry about our ability to be the weak link in their process, we just help them make it happen but we never have access to the data.

Grant: Very cool. Joel, thank you so much.

Joel: I appreciate the time.

Grant: Yeah, that was really fun.