Justin-Casimir Braun: Yeah, so I think it started essentially a bit later than in the United States. You kind of have this trend in policing, in kind of risk analysis… I would say that it begins in the early 2000s, where you kind of have semi-governmental organizations doing credit risk scoring, the first kind of instances of predictive policing, and also more serious thinking around big data mining for some risk analytics in the welfare context.

[10:23] And then I would say there’s a bit of a bifurcation. So you kind of see some instances where big industry players, Accenture, the Palantiers of the world, these big, big companies hype up the case for big data analytics to be deployed across different sectors… And at the same time, you have a lot of failures when those tools are deployed; they often don’t work very well, or people who have to use them in the agencies don’t know how to use them. You see some agencies that drop those systems, and at the same time you see other agencies that kind of build up internal capacity, and build those tools themselves, sometimes in collaboration with universities or smaller startups… But you kind of have these true pathways that continue to coexist at the same time.

I would say in terms of the systems that we looked at, most of them were developed kind of from the early 2010s onwards. It’s definitely gotten a lot more in the last five or six years, and across the eight or maybe nine countries now - I’m not quite sure how many we’ve looked at - but I think we’ve only seen a single country where we did not see evidence of predictive analytics being used to assess risk in welfare.

Ilya Grigorik: Sounds good. So first, let’s unpack the acronyms, because those are always not helpful. PCI stands for Payment Card Industry, and it defines a set of security requirements that you have to comply with as someone who processes sensitive credentials.

So an example would be your personal access number, your credit card number, plus the CVV and all the other data. There’s a set of protections put in place around that for if you’re handling that data, then how you should be treated, what kind of security precautions those services must comply by, and all the rest. And it is a fairly burdensome set of requirements to comply with, then you have to get periodically audited and show that you’re in good standing, and all the rest. So as a consumer, this is great, because fraud on the internet is definitely a big thing; it’s still very much an unsolved problem. Entering a credit card number into a random web form is not a secure undertaking. But we’ve managed to build a relatively reliable experience for consumers, thankfully.

Now, what’s different about PCI before? In PCIv3 a key requirement was that you had to protect the service or the surface area where you you’re entering your credentials. So technically, how we’ve solved that as an industry is we said, “Okay, well, if I want to accept payments on the web, I’m not going to do the obvious thing, which is just put a random form on my page and start accepting credit cards, because then I’m accepting that data, like my service will get a POST request, and I’m going to have the unencrypted payment credentials, and now I’m liable for all the compliance.” Instead, why don’t we outsource this problem? And hey, we actually have a great tool in the web platform. It’s called iFrames. iFrames can give us an ability to embed an external service that can basically do this. And we can skin it in a way that it looks seamless.

[00:16:11.10] Most pages that you visit on the internet, the payment form, if you actually open up your dev tools, you’ll see that it’s iFramed for this specific reason, but it doesn’t look janky; it looks integrated into the website. And the nice property of this solution is you can then just – basically all of the inputs, all of the mouse events are obfuscated from the parent page. So that means you can wholly delegate the responsibility for PCI, v3 at least, to your provider.

A common example of that would be someone like Stripe. If you want to accept payments on your website, they provide Stripe elements, you import a web component, pass it a few props, and boom, you have a checkout form under the hood, it’ll inject an iFrame, and do all the things on your behalf. So that’s great. And that’s been effectively where we’ve settled. I think PCIv3 came into existence around 2013 or 2014. So the last, let’s say 10 years or so, that’s how we’ve solved that problem as an industry.

Now, that is really good, but it’s not sufficient. So in the interim, what we’ve observed is “Hey, sure, you’ve isolated this particular input into a secure sandbox… But what happens if your top-level page gets compromised?” Let’s say you have a supply chain attack, or you have an XSS hole in your checkout page, and someone injects a malicious script. What could they do with that? Well, what stops them from removing your secure input form and replacing it with a fake one? Or maybe providing an overlay and then tricking the user effectively into entering information into an insecure form that then exfiltrates the data, and then swaps in the original. This class of attack is called skimming attacks, also known as mage card attacks, which is a nod to Magento. Not to cast shade on Magento, but I think one of the first published large-scale instances of this attack was against Magento, which had some flaw. Magento is an e-commerce platform, open source… And for better or for worse, that mage card attack name has stuck. Now, to be clear, this is a problem that spans all platforms regardless, as long as you have some sort of vector for attack.

So PCIv4 tries to solve for this particular problem. It tries to tighten the perimeter to say “It’s no longer sufficient to protect the payment page. You also have to protect or provide some guarantees around the parent page, the thing that is embedding this payment form.”

Jerod Santo: Yeah, the tough thing about dependencies, even when you can audit, if you can and have audited and checked out the owners and the code, and the whole do your due diligence, is that what we’re learning over the course of years and decades is even if you do that, if you’re loading your dependencies from the network, you can’t trust the network. And what you think you can trust today, you can’t actually trust a year from now, because the network changes. And so even if you’re doing some due diligence, you can still get bit. These so-called supply chain attacks are happening more and more often, where all of a sudden what you thought was your dependency is replaced with code that is not the same code. And that’s incredibly troubling for me.

Quincy Larson: Yeah. So I’m like “Awesome. This is great. Maybe I need to learn more about CompTIA.” And I made a tweet thanking CompTIA for their gift, and then it was just amazing the feedback on that tweet. Everybody was jumping in and saying amazing things about CompTIA. Like “Oh, I’ve been A plus certified, or I have had the security plus, and everybody at my company has to get security plus as part of their continuing education…” Like, all these people talking about it, people are getting CompTIA certifications as part of their degree program, all that stuff. And I was like “Whoa. There’s so much interest in these rigorous CompTIA type certifications.” We’ve always had rigorous certifications, but they’ve never been industry-style certifications. It’s always been like proof of learning is how we look at them. You complete a freeCodeCamp certification, you build all the projects, you’ve got tons of proof of learning… And people ask me “Oh, can I get a job with my freeCodeCamp certification?” and I always said it’s a proof of learning. It’s one of a basket of things that are on your resume that make you a compelling candidate for a job. But I’ve never said “Oh, it’s a guaranteed job.” And I don’t think any certifications guarantee jobs, or anything that. Some of them may have employer replacement programs… PMI is another organization, the Project Management Institute… And there’s ICS2, ICS Squared… There are all these other organizations that have these professional certifications, and I was like “Wow, maybe freeCodeCamp could move more in that direction.” We could create professional certifications, we could make them free, and we could make them on topics that other certification programs aren’t covering.

So we are working on four professional certifications that are going to somewhat replace our existing curriculum. Like, the coursework will always be there, we’ll always have the legacy certifications. But what we’re doing is we’re building a single, much more comprehensive, linear web development curriculum called Certified Full Stack Developer. And you earn this through completing - here, I’ve actually got a list of all the coursework that is currently in this certification.

So it’s about 3,000 hours of coursework. You learn semantic HTML, accessibility, CSS fundamentals, Flexbox, design concepts, typography… You learn how to work in a code editor, get your code environment set up, JavaScript fundamentals, higher order functions and callbacks, DOM manipulation, algorithmic thinking, object-oriented programming, functional programming data structures, dynamic programming, web standards, React fundamentals, TypeScript fundamentals, testing concepts, Bash scripting, SQL and relational databases, Git, security and privacy, Node, Express, security for web developers specifically, like OWASP, working with APIs, AI engineering fundamentals, and how to get a developer job. And you’re going to learn a ton of Python as part of that too, because we use Python as kind of our backend language.

So that is a very comprehensive web development curriculum, that not only is it going to involve the traditional freeCodeCamp core gameplay loop of building a bunch of projects - because freeCodeCamp has always been all about building projects - but we are adding a whole lot of additional stuff.

One of the biggest pieces of feedback we’ve had over the years is we’ve leaned way too much into learning by doing. And a lot of people want more conceptual stuff. And we’ve always said “Oh, just go to freeCodeCamp… Just keep doing it and it’s like wax on, wax off.” Like Mr. Miyagi teaching you how to do all the basic karate movements without actually having to do the karate itself. Or maybe you’re doing the karate, but you don’t actually know why you’re doing what you’re doing… So it’s been very learn by doing. And we’ve minimized kind of the theory that we’ve given people and we’ve just told people “Oh, go over to the YouTube channel, read the books that we publish every week, and you’ll get plenty of theory.” But what we’re actually doing is we’re working to incorporate that.

[00:57:59.05] So not only are we going to have the interactive step-by-step project building - we’re going to have 64 of those - but we’re also going to have 513 lectures, which are just three to five-minute videos talking about different concepts, everything from different design patterns and things like that, to how a system on a chip works, and stuff like that. And then we’re going to have 83 labs, which are basically just - you have a test suite and you have a blank canvas, and you have to write the code to get that entire test suite to pass.

And then we’re also adding a lot more spaced repetition. So we’re adding 66 quizzes and 6 preparation exams. Then we’re adding a big capstone project, and then we’re adding a final exam. And that’ll be conducted through an audited kind of testing environment that we’re building. It’s open source. So yeah, we’re building our own Flutter app, where you can go in and you can take exams, and stuff like that.

And then if you pass the human-curated capstone, if you build all those different projects - it’s more than a hundred projects - and if you pass the exam, then you become a certified web developer. And then you have that certification for three years, and then you have to do some continuing education to keep it refreshed every three years.

So it’s very similar to all the other big industry certifications. All of them expire after three years, all of them require you to do the additional coursework, continuing education… But the big distinction with freeCodeCamp - we’ve put this word at the beginning of our name, and we’re sticking to it.

Jerod Santo: Yeah, I had an information assurance sub-program at my university, and so I spent the last two years doing all InfoSec things. I actually did some penetration testing right out of college, and between the report writing and the fact that I felt like when you audit somebody - like, you do your best, but you can’t really say anything at the end of the day, except for “Well, we did our best”, you know. And it’s better than not having been audited, but I always was like “There’s a false sense of security that you have now.”

Nick Nisi: Well, you’re definitely getting audited this year… [laughter]

Matthew Boyle: [00:34:06.22] Yeah, it’s a great question. We definitely don’t retain everything forever, to be clear. I think we definitely retain for longer than four days. I think we retain for sort of between two weeks and 30 days for certain indexes… But we vary it massively depending on what the index is for. Like, we do have regulatory things that we do need to keep around, so they’re all logs that we need to keep around for auditing purposes… And they may stay around for as long as two years, four years. I’m not sure the exact details, but we definitely keep things around for a really long time. Especially as a security company, we want to be sure that any changes that are made are audited, and we can keep those around.

In terms of for like code-specific, let’s say error logs from an application, without getting into sort of more nuanced things… We tend to keep those around for sort of seven days or so. I think we could keep them around for less, honestly. I think four days seems like a pretty decent metric to me. I think the biggest concern for me would be over the weekend periods. If there was a long weekend, and people are out Friday and Monday, and you’re gonna catch them out for four days, you might miss entire chunks. So I think that’s why 7-14 days is probably a good number.

We’re less concerned with the volume of predictable log data. The biggest concern is unpredictable log data, and that’s why we rate-limit. Because even with the best [unintelligible 00:35:12.24] in the world, storage is limited. Say we have a bucket, let’s call it 100 terabytes of storage space… It’s very, very easy for a system to go wrong, and if it starts spitting out millions or billions of log lines every day because of – say someone did deploy and say “Every time a user takes this action, print out success.” And they were doing that for every single person who’d like pass through to Cloudflare edge; like, you would end up with quite literally billions of logs every day.

So being able to rate-limit each service, and make sure that things like that can’t happen is more important than the amount we retain it for. Like, predictable retention is fine; it’s unpredictable retention that scary. And we call it the noisy neighbor problem. Like, you’ve got to be a good citizen to those around you. So if we’ve got 100 terabytes of storage data again, and I use 99 of it, and only leave one left for the rest of all the engineering teams at Cloudflare, I’ve been a noisy neighbor; I’ve not been a good citizen of the environment. And that’s the stuff we’re trying to help protect against, is just make it easy for teams not to make those sort of mistakes.

Ben Cohen: It’s all over Twitter, yeah. So yes, at the time, I think actually that change was proposed by Chris Latner at the time… Or maybe he was the review manager, I can’t remember. Yeah, we removed the pre and post increment operator, I think because the idea is they’re a bit of an attractive nuisance. I think if it was just a pre increment or a post increment operator, that might make sense. But having two - that should not be the thing that people encounter as they’re first learning a language, is like “Oh, what’s the difference between pre and post?” There’s all sorts of myths on the internet about how one is more efficient than the other, and things like that.

So yeah, in the early days of Swift there was a lot of rapid motion with the language. That was actually one of the things that was a bit of a challenge for the very early adopters from the Swift 1.0 days, is the language did go through a fair amount of churn. Since I think Swift 4 we actually adopted a policy where there are no more breaking language changes, except with a major version upgrade. And so basically, when we introduce a new major language version - and the next one is actually going to be Swift 6; there was actually a post to the Swift forums just a couple of weeks ago about what it means to migrate to Swift 6, and what the goal is there. When we introduce Swift 6, that’s going to be the version of Swift that introduces data race safety by default.

So we talked about Swift being a memory safe language. The one exception to that is if you have two threads, and you’ve created those two threads, and they share state between themselves. If you mutate a global object from both threads at the same time, that introduces a data race that can introduce memory-unsafe behavior.

As of today, you can opt into a strict mode that will prevent you from introducing those data races into your code. So if you have the latest version of Swift, if you download like the latest toolchain from Swift.org to try out the upcoming version, you can opt into that data race safety checker, and they’ll give you a bunch of warnings saying “Hey, this is a class. You’re escaping it by sending it from this task into this task. That could introduce a data race.” And it’ll tell you, and you can go in and there are various language techniques that allow you to do something about that; unsharing the reference, making a copy, things like that.

[47:57] Swift 6 will turn those warnings into errors, and that means that if you’re starting a new project from scratch, you can be certain that your code is guaranteed data-race free, because the compiler just won’t let you accidentally write a data race. Obviously, like all of these things, there’ll always be unsafe opt outs, where you say “Oh, I’ve got to deal with this legacy API, so I need to be able to tell the compiler. I know, I know, but let me pass this value.”

But obviously, people have existing codebases where they’ve got to ship their app, they’ve got to do an update, they’ve got the latest version of the language, they want to use the latest version of Xcode that comes with the latest version of Swift, but they haven’t got time to go through and address all of those warnings in order to switch to that newer secure mode. And so whenever we introduce a new major version, we always make it an opt-in choice.

So when you compile your code, you say “Compile with the version of the language 5.0”, or “Compile with the version of the language 6.0.” And if you tell the compiler “Compile with the version of the language 6.0”, it will stop you from making these data race issues into your production code. But if you compile with version 5.0, it won’t stop you; you can just get away with them just being warnings, and then you can tackle them at your leisure. And that’s been much better for the community, because it means that they can move forward; we don’t end up getting into the classic Python 2 to Python 3 situation where people are holding back… And you can also do that migration at the module by module level. So you can break up your code and say “Okay, this bit of code I’ve audited, it’s good. I can go to Swift 6 mode. This bit of code - maybe I’m going to do that next month, but in the meantime I need to ship my app and adopt it. Stick with Swift 5 for now and then adopt Swift 6 maybe after I do that.”

Daniel Thompson: Well, I mean, right now Tauri itself is close to entering the beta phase. The beta phase means we’ve reached a compliance internally with our expectations of what it should do. Basically, as soon as we mark Tauri as 2.0 beta, we’re sending it off to audit. It’s going to be audited by two companies. Radically Open Security on one hand, and on the other hand it’s CrabNebula, because CrabNebula has been auditing Tauri since the 1.0 release. 1.3, or 1.4, whenever we started the company back in November.

And once the audit is completed, and we’ve fixed the findings, we will then mark Tauri as RC0, give the community a good time to feedback, reply, make last-minute changes, and then we will release Tauri 2.0. I hesitate to give timelines, because audits can find lots of things that you weren’t expecting… But we do expect to keep things speedy.

We have a blog post about it on the Tauri website, where we go into detail about it… But the challenges of an open source community is that it’s really hard. I mean, even with the venture-backed group like we are being involved, it’s really hard to give the community timelines. I’d like to say a certain date, but obviously we’ve learned that engineering sometimes just takes the time it takes. But we’re closing it on it, and it will have mobile, so I think we’re checking off the to-do list for Tauri right now.

Mark Christensen: Yeah, that’s a great question, and you’re totally right. Data security is so paramount in healthcare. And my colleague at the NLP company cited that as one of the specific reasons why the workflow that we had in healthcare was a great overlay for data training. The data has to be audited, so data should have a couple of different audit trails on it; data should be encrypted, both in transit and in rest. Data shouldn’t reside on the devices of people that are involved in data labeling… So all those things were just a perfect fit and carryover between our healthcare workflow and an AI workflow. Yeah, you’re right.

Daniel Thompson: So we have a board of directors that get together to make strategic decisions about things “Do we get a trademark? How do we deal with managing the community? What about the book? How does that deal gonna work? Who gets how much finance?” Then we have the core team, which is, like I said, a number of people who have massively contributed to the project and are involved in the day to day decision-making. And then we have another volunteer group called the working group. Basically, the way that our organization makes decisions is by consensus. So if there’s a veto, then we talk it out. If there’s not a veto, then we discuss the best way forward.

For example, right now, we’re having a multi-day discussion about our future release strategy. Now that we’ve gotten 1.0 behind us, how do we do deal with new features? How are we going to integrate the auditors? Do we call something a beta or an RC,? How often are we going to release a major? The reason why we even got audited in the first place is because we’re going to continuously be audited. And I think that if someone is getting interested in Tauri right now, it’s a great time to find out what we’ve built, and know that the stuff that we’ve built up until now has been proven to be as secure as possible, and is backed by a team of people who really deeply care about the project.

[01:28:01.27] We have been accepting donations over at Open Collective, and some organizations find the project useful and make regular donations, others are personal donors… And we use this money for things that are project-relevant, like paying for the audit, or the trademark, or for deciding on – no, we didn’t ever do travel costs; we’ve kept it lean. But that budget has also been really small.

And so in the discussions around forming a company, what we’ve realized is that, sure, up until now, for the past three years, it’s been working really, really well on the backs of volunteers, which is almost the same as the instrumentalisation of the precariat, where people have time on weekends and evenings, and sacrifice social time in the real world, and then maybe they get new jobs, or they have to move, and they just don’t focus anymore… And our documentation needs lots and lots of attention, and how do you manage a documentation project of that scope just with volunteers… So we’ve really come to the conclusion that in order for us to continue sustaining the community, we need to find the means by which we can employ members of the core team, we can employ members from the community and people who are interested in getting involved in Tauri. And that’s the delicate balance of “How do you create a common good, while still participating in a capital market?” It’s a really intriguing concept to even think about, because when you say “The value of our company isn’t in what we’re doing, it’s in what other people are doing with us” - it’s hard for financial people to really wrap their head around and grok and be like “Yeah, that makes sense, man…”

At the same time, if we don’t continue getting donations for paying for one or two full-time roles, if that money were to dry up, people would have to start looking for other jobs, and the evolution of the project would stall. So in order to continue providing that common good, and doing it in the right way, is going to be a very delicate dance. But if you’ve been listening, you’ll remember that not even the core team can change the license of the code. There is no rug pull possible here, because we put the code at such a privileged, central point of the project, that the only things that we could even really consider offering are things that are built around Tauri. There’s no way for us to open-core it, there’s no way for us to even legally gut it. It’s owned by a foundation in Holland called the Commons Conservancy.

[01:31:53.21] So it’s challenging to talk about, and I know that there are amazing open source projects out there that have succeeded, and we’re taking inspiration from them… But at the same time, the promise that we made to ourselves when we made an open source project is that it stays open source; we’re not going to weaponize it because we don’t believe in your war. We’re not going to, delete the code from npm because we don’t believe in your police. I think that the greatest satisfaction that you can have as an open source software engineer is that somebody is using your code and enjoying it and contributing back. And that contribution back can simply be by building an app using it. Filing issues, filing pull requests, making donations - that’s all really great, but the mere fact that it’s being used is why open source exists. Now, we can get into the morality of what it means to be an honorable human being and a gentle person who cares for their environment and their fellow beings. We can talk about that. But that’s why you have other instruments. That’s why you have a community. You can take people out of your community if you don’t like them, but open source - it’s become more than a license, but at the end of the day, that’s what it really is. So we have an agreement with the community and with each other that this project is open source, and it’s staying open source.

Those are the arguments that I would bring to the table - that it’s a stable core, it’s been audited, and it is and will always be open source, and we’re working really hard on finding an honorable way to support the engineers involved in building it.

Ken Kantzer: That’s a really good question. I think you can correlate it with operational success, but there’s so many different axes of operational success. Like, are we really good at hiring? Are we really good at coming up with good Scrum patterns for our teams that they buy into? I think operational success - maybe that matters for being tied to like product success. There was just like a ton of discipline on product development. I don’t know if you guys have looked – so Basecamp writes like a bunch of stuff on remote, but one of their earliest things was actually on like software development and how they do product… And they have this amazing observation, which is like – one of the chapters is called “It doesn’t matter. It just doesn’t matter.” And their point is like, a lot of times you get into these product and feature discussions, and the answer is like, “It just doesn’t matter. It doesn’t matter if the button is on the right or on the left.” Maybe it matters like a smidgen, but it won’t matter for the success of your product.

I’ve just found that a lot of the startups that I looked back on are worth like a half a billion dollars, and when we audited them they had like four developers, and I was like, “I don’t know if they’re gonna make it.” And now I’m like, “Ah, I’m so pleased.” They were just really disciplined about that. They were just very focused. And that’s a form of operational excellence. They may not have had – like, they may have been messy in other ways, but they were really disciplined where it counted.

Tobie Langel: And as Chris was mentioning - I mean, you’ve audited the package once. Wonderful. I mean, I don’t know how your life is around maintaining open source software, but I just get pinged all the time because there’s like a dependency that I have to update, because there’s a security vulnerability somewhere… That probably doesn’t affect my project, because I’m just using a bit of it, but I don’t know… So that’s the other side of the coin, right? We have to audit every change, and we have to audit all of these changes just in time, because we actually wanna pull those patches in, because if not, we might be risking something else.

Juan Andrés Guerrero-Saade: Nobody likes that idea, particularly any of the really persnickety Linux devs, who think they’ve got their stuff locked down… But none of them run any kind of endpoint security, nobody believes in any security solutions working on that space… And we tend to use a lot of shoddy package managers that just shove code into our environments all day long, but isn’t audited, and nobody knows what’s going in there. There’s a lot of name typos squatting for packages… So you know, Brew, and npm, and Pip - all these things are actually quite scary mechanisms that we all rely on, that are being targeted, and we don’t really realize that the substrate of what software developers tend to rely on is actually quite porous.

Ryan Dahl: [27:52] Yeah, so obviously if you’re pulling in random packages over HTTP, you should be worried if you’re pulling in code, because maybe you’ve audited this code, but probably not. That code probably depends on some other code. And those can end up pulling in many dependencies.

Guy Podjarny: It’s a learning exercise. So I was in this Israeli company called Sanctum. It lived over the bubble; it was one of the pioneers of the application security space, building the first web app firewall app shield, and the first web app security scan , AppScan. And Sanctum raised a lot of money shortly before the bubble burst, and that allowed it to get out the other side… And it had great technology, but it didn’t have the best go-to-market execution. Also, there was a need to rewrite… You know, as the technology of the web evolves and application security was growing, it was a constant chase to – you know, JavaScript wasn’t on pages when that started… So by the time Watchfire came along to acquire it - Watchfire was a company that audited websites for other types of problems, not security problems; it found spelling mistakes, it found broken links of websites, in big scale. And you know, some of you might disagree with me, but I think the tech was not as deep as Sanctum’s, but the go-to-market was excellent; and the tech was scalable. It was around breadth. So Watchfire acquired Sanctum a little bit before Sanctum ran out of money, in a slightly more elaborate private-to-private transaction… And I moved from Israel to Canada in the process.

And for me, the next 2-3 years were very seminal in my learnings. First, I moved, I relocated - a big life experience, seeing something that is different, which I loved, and I think I learned a lot from. Second is I got much closer – Israel is a great technology hub, but oftentimes when you’re there, you’re a little bit shielded from the go-to-market. But by moving there, I got much closer; I got on more sales calls, I got on more customer conversations.

I actually did a stint as a tech sales person, and then I took a product role; I went out of development, into product. So I learned a lot about the outside, and I learned to appreciate what a good go-to-market looks like. AppScan’s sales first quarter after the acquisition were the best ever for AppScan; this is the first quarter into Watchfire, after the acquisition of Sanctum… And it was just because the sales leader there just kind of figured out and immediately saw the way it should be sold over the phone, with a certain process, very quickly.

So to me, I think that’s my first takeaway, which is appreciate go-to-market, learn the interaction, appreciate sales, as I was a part of the org for about six months, and then kind of learned that product. And then when IBM acquired Watchfire, I guess I’m gonna say that there’s a bunch of things I learned what I don’t’ like about an acquisition. The acquisition itself was good, it was great; we moved into good surroundings, and IBM is very methodical with their blue-washing process on how do they gradually merge companies into it… But then it taught me a lot of things that I didn’t like to do post-acquisition.

I’d say my two primary learnings were - you know, one is we got acquired into Rational; this is a security company. We got acquired into Rational as a part; it’s the same journey that I’m on, this sort of developer journey to build security into development tools… And one of the key challenges, which we did some right and some wrong, were really around “How do we merge this security sale within the dev environment?” So I feel like I learned a lot there about the challenges in those scenarios, which I think helped me with Snyk later on.

Josh Aas: So what I’ve just described is the basic process of getting trusted from scratch. And that does require a big commitment. It requires quite a bit of money to get set up to a point where you can pass audits and even apply, and then every year while you’re waiting for all this stuff to happen for 6-10 years you have to stay compliant, get audited every year. So you’re talking millions of dollars and 6-10 years before you can even be a publicly-trusted CA in any meaningful sense. That’s the basic process.

There is a way to make a shortcut, which is how Let’s Encrypt was able to start without waiting 6-10 years first. So we did go through the process that I’ve just described, building up our own root of trust from scratch… But the world right now does not really rely on that yet, because it has not been long enough.

[31:52] And somewhere around mid-to-late next year we’re gonna switch over to our own root that’s trusted from scratch. But from our inception through now, we have what’s called a cross-signature… Which means we knew we didn’t wanna wait 6-10 years to start offering Let’s Encrypt services, so we’ve found another CA that understood what we were trying to do and was willing to help. They had a root of trust that was already trusted.

What essentially happens is we create a contract, an agreement between us, and then their root of trust essentially lends its credibility to us. So they issued a certificate that our root is trusted by their root, and their root is trusted by the browsers, basically. So that’s called a cross-signature. We acquired that before we did much of anything… Because without that agreement in place, there’s really no CA.

So one of the first things we did was get that agreement, because without that agreement in place, there’s no point in buying hardware and doing anything else… Because –

Frank Karlitschek: [20:02] The value proposition is – I would say in 80% of the cases it is something around security and privacy… And this often means on-premise, but it doesn’t really mean your own server in your basement. It can be in a hosting center that’s next door, and you have a special contract with them, and they’re certified, and they’re in the same country, and you somehow trust them. It can be that.

Other security things are also that you can audit the software. For example, we have some government users/customers who audited the software, so they actually looked at the code and paid people to check it, make sure everything is okay, and they looked for back-doors and other things… And because it’s open source, they could check that there are no backdoors in it. That’s not really possible with lots of other cloud service, Office 365, G Suite and so on.

So this is important for most of our customers, but there are other benefits, too. For example, speed and cost. Usually, you say “Well, Amazon is affordable, and fast, and everything”, but if you really have a lot of data… For example, Nextcloud is used by huge universities, particle accelerators research institutions who literally generate petabytes of data a day. It’s really hard to upload all this data to Amazon or to Google Cloud. Because of that, they have their own hosting center in the same building. In this use case, Nextcloud can be useful to provide services, to collaborate on this data, to sync it to other machines, and so on. Amazon is big, but it becomes really expensive if you upload petabytes.

Gregory Kurtzer: For Singularity, we never considered it. For our cloud development – I mean, it is a cloud service, so that’s not something that we’re open sourcing. So that is definitely a closed source. But we’ve actually gotten some really interesting information, which is - everybody’s talking about cloud, everybody’s talking about getting all their apps and everything up to the cloud, and so we developed this cloud service thinking everybody wants to go up to the cloud. A really interesting spin on this, and something I totally didn’t expect, is that almost everybody - well, maybe not everybody; I’m exaggerating… Maybe about half of the people that we talk to wants to run that on-prem, and I wasn’t expecting that.

So we are figuring out how to relicense and rebrand our cloud services, and allow people to run those on-prem. And we have several different cloud services at this point. The key store that I was mentioning before is just one of them. Another one is a build service, so you can actually build containers without requiring root or without requiring any sort of privilege escalation, because we have a service that does that in a controlled way. We also have something called the container library.

Now, in compute - and I’ll give a little bit of background on this - there is various regulations. In pharma, for example, on the science side and the bio side, they have various FDA regulations even, that they actually have to manage the environments for any software that contributes to a diagnosis of a medical issue. Anytime software is involved in that, that entire stack has to be treated as a medical device, and a medical device has to be archival for 5 to 10 years, meaning we have to be able to reproduce those results and reproduce that environment for 5 to 10 years. Well, Singularity provides a perfect solution for that.

[47:59] Our container library, one of our services, is kind of built around the idea of “What are the specific benefits of this binary image format that we have, and how do we archive and always allow people to go back to previous workflows?” and so on and so forth. That’s a feature that we have in this container library.

The other one is - you know, a lot of people talk about DevOps, and they pass recipes around; they pass the source code, in a manner of speaking, around, or their environment. Well, again, because our containers are 100% immutable and cryptographically verifiable, why don’t we just pass the container around? And that way you never have to rebuild it. So it goes from the developer, you build that binary container, and then it can run through a DevOps pipeline that can be completely built up for whatever the pipeline is, and customized via CI/CD integrations and whatnot, and then come out the other side as “This binary immutable image has passed all of this.” This gives us the ability now to inject things like the security teams into the DevOps workflow… Because once this pipeline, once this container image is going through this pipeline and it gets to security, and security is like “Okay, I’ve audited this. I feel good about it. I’m gonna now sign it”, and then continue it on its way - well, we just added a cryptographic signature on it that wherever you run in production, you can say “I’m never gonna trust this container unless it has this key fingerprint. And if it has this fingerprint that your security team owns, then I will allow it to run in production.”

So it gives us the ability to do things like inject security back into the DevOps workflow, and it changes things. It changes how we’re doing this.

Adam Baldwin: Yes, it brings up a very good point… Just because it doesn’t have any problems doesn’t mean that somebody has actually looked for it. Right now that’s a problem across basically all tooling. Unless you have somebody auditing those packages, you have no confidence. The ^Lift team does auditing of the top hundred modules for the npm enterprise offering. So we do some thorough auditing of those packages and keep an eye on those, but there isn’t a good indicator for thoroughly audited.

[32:23] This is a challenge that we had early on. I at one point could tell you that – Chris, there is not a list of those npm packages someplace; I could probably dig that up though.

At one point I could tell you that we audited every 12,000 of those modules early on for child process [unintelligible 00:32:43.03] So I could tell you that we audited those for one thing. Even then, there’s gonna be blind spots, so I think the goal is to figure out how to incentivize those individuals to audit things, and then to figure out how to capture those efforts. It’s gonna be a challenge, and it’s something that we’re looking forward to as a challenge… But there’s no tooling that really gives you that confidence level yet.

For me, that’s frustrating; it can be frustrating, but we’re gonna expose all of the signals that we do have. Right now we have the database, and I know there’s some differences in those databases. Right now we maintain our database, which was at one point in time donated to the NodeJS Foundation, which sort of kindled and started up the Node Security Working Group… So they’re maintaining ecosystem reports right now, so we’re doing just some of that, as well as we have internal research that goes into our data set as well.

Jeremy Soller: Exactly. So each scheme is typically owned by one process. So one process for each scheme. A process can have more than one scheme. Usually, they don’t, but sometimes they can, in the event – for example, the network stack, especially the new version of the network stack has TCP and UDP and IP all implemented by the same process. So any operations on those file systems gets sent to the same process. But what this means is that you can easily audit all of the open file descriptors and all of the available paths on the system. Who supplies them, what is happening to them - all of that can be audited from the kernel level. So by asking the kernel for all the open file descriptors, and for who created them and who is using them and all of those things, you can also design a more secure system. You can say “Well, that file descriptor shouldn’t be open. I’m gonna modify this process to close that file descriptor.” Or “This program should not have access to this file system. I’m gonna modify the permissions that it gets launched with”, things like that.

Adam Stacoviak: I guess one thing we can probably dive into a little bit further is what you really mean by “secure”, and mainly for breaking it down for everyone to really understand that… Because on your matrix that we mentioned in the previous section it says “Secure = Everything’s secured with end-to-end encryption.” People may say that quite a bit; maybe it means one thing for someone else but it means another thing for you, but you’ve got an entire page dedicated to describing what you mean by “secured with end-to-end encryption and protected by European privacy laws”, which you’ve described as more robust and more comprehensive.

Can we kind of walk through some of the information shared at Wire.com/security. You’ve got “End-to-end encrypted”, “Independently audited”, “Multi-device messaging.” These are pretty interesting things I think that people don’t really break down unless they have to break them down. So to say that new encryption keys are used for each message, so if one is compromised, a key has minimal impact; or how you can use several devices… Can you start breaking down some of the end-to-end encryption details that you all employ?

Dan Kohn: [47:44] Yeah, that’s a great question. Thankfully, we haven’t needed to make a lot of tradeoffs so far. We’ve been able to be really successful both in bringing in new projects and being able to provide them more and more services, and correspondingly bringing in a ton of members. So at least right now, we’re really in a positive feedback loop, and that is our whole philosophy of how open source ecosystems like our can grow - you have these projects, companies can use them to produce useful products, those products can throw off profits that can be reinvested back into the projects again.

On the member front, we’ve really had a ton of success in 2017 on bringing in almost all the big companies in our space. So we now have all six of the biggest public clouds (depending on how you measure) and most of the big enterprise software companies, and others that all consider these technologies to be integral to their future.

We’re particularly pleased over the last few months that we were able to bring in Oracle, Microsoft, Pivotal, VMware and SAP as platinum members.

Then on the books, we’re a non-profit foundation, so we have audited financials and we work with the Linux Foundation’s finance team to keep pretty clean books. Those are all shared with the governing board, and then this (probably) February we’re gonna be publishing a summary for the first time… So it won’t be the very detailed thing where we put every single expense into, but just how much we’re spending on developer tools, and what we’re spending for third-party events that we go to, and our documentation, and other kinds of things.

That is also probably a good segue to the question of our own events, which has been definitely been a big focus for CNCF. We’re now just I think 13 days away from the biggest event we’ll ever run, which is KubeCon + CloudNativeCon. That’s gonna be in Austin, December 6th-8th, and it’s not sold out yet, but it’s heading very fast towards selling out at 4,000 attendees…

Jerod Santo: [\00:32:04.06\] Most users do not even know that there’s a way they can identify a site as encrypted or not encrypted, let alone the EV versus non-EV encryption. So the goal is let’s get all the sites encrypted, because people won’t know one way or the other. The EV - I think it’s a clout thing, or it’s kind of like pimpin’ your ride; [unintelligible 00:32:27.26] That’s the only reason why I think it would be attractive to me, because like Jacob said, the encryption is the same. It just shows you went the extra mile to be audited more thoroughly than other sites did.

Adam Stacoviak: It seems like this tool is really unified, no matter what angle you need to store secrets - whether you’re the developer, whether you’re the machine, whether you’re on the security team and you need to do things like revocation and stuff like that… It seems to me like you’ve built this perfect tool for literally managing secrets and being able to scale - if you need to move beyond the open source tool, then you can; you have other options, like the pro version, the enterprise version that you can upgrade to. It seems like this is the best unified way to encrypt, and then actually authenticate or get access to certain service or certain databases, or encrypt data, things like that.

Is there anything else out there like this? I know it’s built into other tools, but this one, unified way, as you’d mentioned, this tool has been audited by external agencies to confirm its security. Is there anything else out there like this?

Hillary Hartley: Yeah, absolutely. The back story is that each federal agency has an inspector general. The inspector general (IG) of that agency is essentially generally charged with ferreting out waste, fraud and abuse. We’ve been saying for two years that our time was coming, because every program gets audited at some point or another, and 18F went under audit by our IG starting at the beginning of 2016. So basically from about January through July or August we were essentially under review, and mostly they were scrutinizing our finances.

This is probably a little more information than we need, but essentially 18F is funded by an internal revolving fund that is inside the GSA; it’s a fund called The Acquisition of Services Fund, which is managed by one of the top-line business units in GSA called The Federal Acquisition Service.