 three of the computational law course at MIT, day one. That's right. Let's give a few minutes for people to log in here and start viewing. I might say a couple of things by way of housekeeping. One of those is that I sort of obliquely mentioned a little earlier that we're looking to do something kind of, well, a little bit edgy, a little bit innovative as part of capturing and collecting all the great presentations and ideas and new written works coming out of the course this year. It's partly thanks to our teacher's assistant, Mila, who is a practicing attorney in San Paolo and chairs the legal hackers chapter there in Brazil, and it's connected with Thompson Reuters Latin America and kind of passed forward an idea that they might be interested in republishing some of the proceedings or some of things that happen in activities during the course to let people know more about computational law. So that was very interesting and that kind of led to some more conversations and that's where we kind of got this idea generally. Maybe we ought to collect our materials and do a better job of it this year and perhaps we can follow in the footsteps of our friends at Stanford Codex to some extent who launched a the Stanford Journal of Blockchain Law and Policy. That came out of basically the same broad community that we swim in. Computational Law and Blockchain Festival or Festivus to our friends. And so basically we're going to try to connect, we're going to work on using PubPub, an open publishing platform to start to collect some of the lectures and some of maybe the interesting outputs of student projects or smaller group discussions that are happening tomorrow and Thursday and draft some blog posts, maybe some reviews and maybe some video or some other media types. And eventually maybe work on that through the CLB Fest 2019 and iterate with the goal of launching some kind of periodical. Law Review may be a little stodgy for our format tastes and MIT doesn't have a law school and that's perfectly fine. But maybe something more like a fresh magazine or some kind of new media publishing ground, right? The sky's the limit. The sky is the limit. The ether. So the next presentation that we have is actually, we kind of have two more, two sessions for Part 3 at the end of the day. And they are computational contracts with Chris Berent and basically information security, cryptography and protocols. I would consider it kind of a foundation setting course with Christian Smith. So the idea here is that we again really want to invite you to kind of go the extra mile at this time in the pigeonholes for each of those sessions, first up being Chris Berent's computational contracts session page so that we can be in more conversation with you. And what I'll do this time is I'm actually going to set the display parameters so that what we see is the most recent posted questions. So go ahead and upload the ones that you find interesting and we'll do that view from time to time. But we'd like to kind of up our level of game here and try to be more conversational adaptive to the real-time stream of thoughts and questions and ideas coming from you. So what do people do one more time in order to do that? You got to go to the agenda page. Okay, I'm going to do a little screen share here. Boom, okay. We're screen sharing and so what do we first do? We somehow get to the class page. Here is the class page. We go to the agenda page. Boom, click. Then we do what? From there scroll down to the session page so it's going to be a little bit further down. Okay, this is the sessions page, right? Yep, and click computational contracts. Right here. Chris Barron, 215, our version of 215. Here is the, you can follow on the live stream right here on the same page and you can, here we go. Oh, actually looks like we've got some, we've got some meeting these bones already, which is great. And then you just add your questions and comments right here. Yep. Computational contracts. And here's Chris's overview from this year here. Computational contracts are, I think, really essential to what we're going for in our take on computational law, at least the law.mit.edu take. The law is a multifaceted thing. The law very much, some people, when they say law, what they mean is what was the ruling that came from us, from the Supreme Court or from another adjudicatory body. Other people mean a statute. What did the legislature say? Other people think the law, especially these unitary executive people, think the law is whatever the president says and the regulations and the policy set I'm getting a little bit of echo here. I think Chris just, Ah, Chris. Are you with us? I am. Welcome. Okay. Just setting up the table for your talk, but a very important part of the law and one that's especially well aligned to a global change in evolving law for documents, kind of almost medieval paradigm to an information digital data centered paradigm is contracts. Contracts are enforceable in law. They have rules. It's an important part of law. And it's the law that governs so much of our lives. Leases, licenses and music are contracts. Commercial contracts, we already have good code for contracts, the Uniform Commercial Code and the Hague Convention on contracts. It's legal, but it starts to structure some rules and create a nice taxonomy to start with. And more to the point, perhaps, this is private law, not public law. So we don't have to go to the government and say, mother, may I please have reform in law and then see whether or when or what we get as a result of that. We can make our own darn contracts. Thank you very much. Freedom of contract is essential to this facet of the law. And what not only can we make them, we can format them, we can structure them, we can express them largely however we want. And that means that we can find rapid adoption in interesting sectors of the economy and facets of society of people trying things new ways. And the law is very flexible when it comes to contracts, especially, I mentioned the model, the United Nations Commission on International Trade, law and electronic commerce from the late 90s and other international legal conventions and implementations in different jurisdictions internationally are quite flexible with respect to different types of electronic contracts. And they're just looking to make sure that the key elements of offer and acceptance and adequate certainty and some other kind of procedural, almost like formats are there, but we can roll these things however we want. And Chris has been, what I would consider another beacon, light of how high the ceiling for innovation is here from his work in the energy markets of structuring very complex multi-party contracts in ways where they are expressed digitally as network services that are data-driven and makes much more efficient business models and operations as a result. And so tickle-pink, right, to have Chris. And you nailed it last year, Chris, by the way, which is why we invited you back this year. And so, so shall we get right into it? I think that's a good call. Okay, so, hey, Chris, thank you for joining us. And you can come up. I'll go on mute so we don't have feedback. And I want to welcome you, if you could just say a few words to remind people who you are and just what your take on computational contracts is. You don't have to repeat your whole life, but maybe just back into the hot stream of computational contracts. And then we're just going to start closing quite a bit that are coming from our students from all around the world. We've got quite a backlog of people that want to talk to you. That's great. Thanks, Daza. Can everyone hear me? Yeah. Okay, great. My name is Chris Barron. I am a transactional and regulatory attorney in the advanced energy space. I've been doing energy law in energy markets, environmental markets for quite some time. And I'm honored to be here with Daza and team with all of you. When I think of computational contracts, I simply think of contracts that have automated properties that can do more than simply the letters on the page in terms of how they often implement. At some point in the future, we might see contract formation and contract construction being handled more on a computational basis. But to date, and for the most part, when I think about computational contracts, I think of agreements that regardless of how they're expressed are able to implement and execute in a manner that automates certain functions, usually a processes. So that's kind of how I think of computational contracts. But the field that encompassed that term is certainly expanding. And text, oops. I can see the beard. I can't hear your voice. Okay. Yeah. Now I can see you behind Brian and I can hear you. Okay. Perfect. So here we go. There you go. Boom. There's Brian and here I am. Okay. So let's get right into some of these interesting questions. So the highest rated, the crowd favorite is for, it comes from Jose Rodriguez. For more traditional legal ecosystems, what would you say are the first to implementing computational contracts or document automation? Is there a right critical factor? Do you kind of get what Jose is asking? Is there an area of the law that seems to be adopting it quicker than others? Well, I think there's a scope, which is for more traditional legal ecosystems, and I'm not exactly sure we can do that, but if we can, I'm thinking big law firm, I'm thinking maybe regulatory agencies, a regulatory, heavily regulated environments like energy and transportation perhaps in some ways. What would be the way to begin to expressing these contracts as computational systems? It's an interesting question. And we're seeing, the legal community is very slow to come around to using new tools and new systems and so on. I like to joke it's often lawyers, clients who are utilizing more advanced tools and techniques who sometimes drag their lawyers kicking and screaming into the future. I think from a very, very basic ecosystem level, at the highest level, where you're talking about like a civil law versus common law jurisdiction, there's a lot of dynamics of a civil law jurisdiction that lend themselves to computational processes. You tend to have in civil law jurisdictions less of a bandwidth on where interpretation can come out and so on than common law jurisdictions. From a legal ecosystem standpoint, who's using computational contracts and so on? The leaders in automation tend to be folks who are using master agreements for trading different types of commodities, securities, and so on. The whole world of the over the counter markets, exchange traded markets and so on has taken, I would say, initial advantage, kind of first generation advantage when it comes to what can get automated from a computational perspective. There's still a lot that human beings are doing at trading desks to help effectuate it. From the legal perspective, the agreements that are used like that have an opportunity to take on more express computational dynamics, more of an opportunity to kind of reference and plug into automated processes, systems, and so on. Sometimes you certainly do see that at the confirmation level of deals, but there's unfortunately not a lot of kind of computational dynamics, automated dynamics that I'm seeing going into contractual frameworks beyond some of the kind of cutting edge stuff that's happening in the energy space, the manufacturing space, and things like that. I think the litigators haven't really, other than looking at big data analytics and so on for e-discovery and things like that, there's not been that much activity on litigators using automated computational dynamics other than what might exist in programs that they use for risk analytics around jury selections, verdicts, things like that. So from a legal ecosystem standpoint, I think drafting contracts that have automated functions is happening, but it's still in the evolutionary stages and a lot of law firms in particular, in-house counsel, lawyers in general are still getting used to how those dynamics play out. I mean, do perfectly, Frank, as an attorney, you try to draft agreements whose outcomes are fairly certain and static, where you know if this is elected, if this happens or so on, this is what the outcome is going to be. So-and-so is going to sell this to somebody for this price or so-and-so is going to be responsible to undertake this service and such. And automation is a little scary in the legal field because it represents less of a kind of single-track, stove-piped, static outcome and more of the opportunity for a whole range of various outcomes and so on. And so I do think a lot of people where they're used to drafting agreements so that that variation can take place in how the weekly confirmation or delivery tracking sheet or order sheet gets filled out between the parties, seeing that kind of automation up at the actual agreement level and how that agreement might select overall service provision, overall product provision and so on is still in the early stages. The automated contract systems I talked about in my last talk and that I've talked about with DAS and others whether they're expressed, regardless of how they're expressed and on what kind of server or system or whatnot, they're functionally master agreements that allow for a lot of variation and triggering of different deals and confirmations. And the agreement itself still has a long way to go before its construction, expression, interpretation takes on automated computational dynamics. Right now I still see it as an implementation-execution game with computational dynamics. That's a perfect segue into the most recent question that came out. We started with the highest voted and do you mind closing the question and then I want to maybe frame it a little bit for Chris? Yes, so Brendan, could you talk a little bit about how you see master contract, like kind of like the configuration of master contracts and subcontracts involving? Yeah, and if I could frame that just a little bit, could you first of all explain so everybody knows in larger contract systems, more complex contract systems, there's layers and or maybe master contracts usually come from the problem. So I mentioned EDI earlier, electronic data engineering, for procurement systems, we would have a that indicated some of the high-level rules and scope and perfect governance of the trading system. And then we have specific participation so I'm off your veto, I'm off your veto, I'm off your veto, I'm off your veto, I'm off your veto, I think the State government corporation we are going to use these kinds of and we will agree to say right to quote, send an acknowledgment that the goods were received, send an inmate, send an acknowledgment, name it a bird, and block the variations in there. So you've got this transactional system. You've got this basic opt-in contract. The parties agree to be bound by the rules and procedures of the overall system. Agreed to pay when an invoice is sent after these types of messages occurred. And then you've got the overarching master agreement, which among other things, at least in this technology infused, hard to maintain context, would say, here's the types of parties that can be buyers. Here's the types of parties that can be sellers. We're going to use this standard or this dialect of XML. We're going to have these services at your bases. You're on board your systems in the following way. We need the listing of the points of contact for these things. We will accept these types of payment, et cetera, et cetera, et cetera. So could you extrapolate a little bit on Brandon's question of how do you see the use and evolution of master contracts and subcontracts as how we can structure these new types of training systems and of all of these, the transactions going forward? Sure. Where to start here? So I mean, Daza, you characterized it well. A master agreement is essentially an agreement that two parties put in place saying, in the future, at certain times, we will undertake certain transactions in accordance with this agreement. And a master agreement tends to have all of the terms in it that would apply to any transaction between the parties. It's very common that you put in place a master agreement and in that master agreement in the back in the exhibits is what's called a form of confirmation, which essentially says, hey, when we transact, this is the form where I'm going to say, I'm requesting this many widgets from you where you're saying, I'm going to sell you this many widgets or I'm going to provide this much of this type of service or you're going to provide this type of this much service. So a master agreement usually has the basic scope of what the party is planned to do between them, payment terms, credit terms, liability terms, dispute resolution, stuff that would apply specifically to each transaction regardless. Confirmation is where you often have the details on the numbers of how much of something, how much am I going to pay you for it, and when am I going to get it and where. And to date, many, many parties have set up many types of master agreements. And I'll note that sometimes a master agreement will be what is also called a standard or model agreement. Those agreements sometimes are developed by specific entities. So if you have an entity that's a big player in its industry and its sector, I've worked with folks like that to develop their standard agreement where we basically then tell all of their suppliers and vendors, guess what, guys, you're using this. And if you want to work with us, this is what you're using. Sectors, industries will also get together and create what are called model agreements where you'll have a drafting committee of representatives from a bunch of different companies and law firms and stuff and everyone will get together. And they'll draft up an agreement, kind of deemed a model agreement that is meant to be a common master that everybody in that sector can use to standardize as much as they can the terms that people are transacting under. And so, you could have a master agreement that's just a bespoke one that's whipped up between two parties to handle a very customized situation. You could have someone develop a master agreement that's kind of their standard agreement where they say, if you wanna do business with me, this is the paper we're using. And you can have whole sectors that develop model agreements where everyone tends to use that same model agreement plus, and deals are effectively customized by having an amendment to the model agreement that you negotiate that says, this is added to this provision, this is taken from this provision and we're electing blank, blank and blank on these schedules. So there's different versions of it. To date, most of those agreements get put in place by the legal teams working with the business teams, they get done on paper, we share electronic copies, it gets put into file, and then it really only gets pulled out if there's an issue and most of the activity is taken over at the business level by the exchange of confirmations. The automation that's really emerged to date has been in, when I have a master agreement with multiple different parties, and it's normal for you to set up a stack of master agreements with a lot of different suppliers, vendors and customers. And that stack of agreements can at any given time have like a specific set of agreements within that stack be exercised to a certain level and in a certain way. So I might decide to buy some stuff from some vendors, sell some stuff to some customers and line up this supplier to do this next month. And that whole constellation of how those agreements are being positioned through daily confirmations coming out with it from the masters that are in place, that can happen in any number of different ways. And so most of the automation I see in computational contracts to date has been automation that reflects how do we take a group of assets, whether it be an industrial park, a manufacturer plus a power plant, whether it be a whole portfolio of assets, how can we position those based on market values and values that we've also values that we've established under our agreements with counterparties, how can we take that kind of constellations of different asset positioning and pick the one that is worth the most money that optimizes the best. And so to date, most of the automation we see in computational contracts have been focused on providing an automated process of selecting which confirms get sent to which counterparties and what the numbers go into each of those confirms. And then in a lot of instances we set it up so the confirm itself exchanges electronically or you automate the exercise of the confirm and the transaction between the parties and it just happens on its own unless someone raises their hand and says stop. So it's kind of again at that implementation level but the future is gonna hold some interesting things for how contracts get constructed and expressed from a computational kind of basis. But for now that's where we see kind of most of it and quite frankly, if you look at like the smart contract, the contract account on Ethereum and so on, most of quote unquote smart contracts, computational contracts that you see out there are basic agreements just expressed electronically that say when this thing happens, when the status of whatever it might be changes from X to Y, this action happens and maybe that so-and-so gets this many tokens at this rate, so-and-so gets sold this much at this whatever or so on. But it's for the most part, it's fairly simple mechanisms that we're seeing in place right now. And it's gonna be interesting in the future to see how far up the contractual development chain automation and computational dynamics can reach. Can I say one thing? Yeah. So we have a couple of comments on that. One thing I just wanna highlight is I'd like people to take away from this and maybe first of all, Scribes could include his future work for us to fill out in the notes. There's a basic architecture when you're structuring these contracts for electronic transactional systems or other types of systems that works pretty well. It's an engineered architecture that includes a high-level contract that sort of sets things that apply to the whole community and has some things like who's in and who's out? What is the scope of interactions well-happier or assets or transactions? How do you get kicked out maybe? Who decides when there's disputes? It would be another thing at a high level. So you could actually have a kind of a internal dispute resolution is not so unusual so that you can start to look at ways to delink to express this largely as a private international model that is time-honored in terms of its enforceability and allowing you to have predictable legal outcomes. And so the architecture I want you to think of is imagine designing electronic contract or even how you could have smart contracts been to what if you had a paper, master agreement that indicated we're going, here's our system for whether it's a DAO or otherwise or just more mundane transaction. And if you want to be in on it, we're conducting this swath of interactions on through blockchains. The way that you do it is ABC and we're gonna gap fill all of the, like maybe indemnification and liability and when the risk of loss changes, how we're going to evolve and update the technical standards. Look to the master contract for that stuff and then look to the smart contracts for more transactional kinds of things. This would be like a first grade level, in a sense, a way to apply how to use master contracts. This system, a lot of people that are doing this stuff may not be that sophisticated and they maybe haven't suffered for decades with master contracts as some of us have, but I want to encourage you to just think about just delinking a master contract from maybe participate agreements where you agree to be bound by the master contract and then transactional messages for like buy, sell, trade, license, whatever. This is really important and so thank you, Brandon, Brandon for bringing that up. So now this also kind of gives us some thoughts in the insurance industry and some other sectors, although Vicki raised her hand, should we defer? Yeah, I just wanted to make a comment that that is precisely the way I think about music is because, you know, music... Could I ask you to come here? Not only because it makes better video, but also we want to hear you. Thanks, Vicki. Yeah, so my comment was that that is precisely the way to think about it with music because almost any licensee, license or agreement has really broad reaching, indemnifications, usages, approved uses, all sorts of different things that couldn't possibly be incorporated into a small transaction, but then the deal points and the things that I put at the end of my deck, there's really just a short list of deal points in any kind of music contract, and these can be supported by business rules in a platform, they can be supported by smart contracts, and they're things like the territory, the rights calculation, the functionality, the way something is going to be reported and logged and tracked according to metadata. It's really a very short list of things that are critical for that on a transactional level. Here, here. And there's so much, Brian gave me one note, which I want to put at the end of what you're gonna say, on BLT, not just a delicious sandwich, no, no, but it's also an approach to incorporating business, legal and technical dimensions of, in this case, a trading system, say, for example. And so there's some, it's quintessential, and I would say fundamental things that you would want to have said once in a master contract, and you don't want to renegotiate or repeat every time, or worse yet, repeat a little differently every time in transactional agreements, like, when do you decide when we're going from whatever, from this version of the core system to version 1.1, or how do you, how do you get it, what registries are authoritative for certain times of things, what is the current version of API with the minimum metadata for this type of aura? This is basic stuff, but we cannot have it always be subject to my interpretation of a string of issues in several repos and GitHub. Like that is not a predictable legal outcomes. For some types of things, it may be desirable to spell out what we all agree, and if we do agree, then we can spell them under the master level, and then we can have, like, speed of thought transactions at the lower level, and we can also, as part of my career used to be, helping, you know, sometimes many party organizations craft the change management of the master contract and the, because you might want to change how those decisions are made, or who's in and who's out, and it's good if there's some process where people can propose change, you can be considered, it can be agreed somehow, and then it can be staged in phase, so like, we're going to change the master agreement in like 14 months, okay, in 12 months, in eight months, you can get out without owning anything in six months, so decide if you like this or not. Exactly, exactly, we're differences in music world, differences in royalty calculations might change once you reach threshold, and then there's a difference, and then you'd have, of course, in a decentralized environment, you'd actually be able to trace that back and see there's a point at which the calculation changed, everything before that is reflected, everything after it is something different. Now we're getting to adapt with systems and truly computational, not just contracts, but also the governance layer, and when we get good at this, the way Chris is quite good in the energy sector, some of these calculations can be based on algorithms and merit order, so it's not, like in the 90s, it literally was months of time in meetings and back and forth, these things, this could be reduced to weeks and days and hours. Minutes, even if you do it. I love the examples from music, I think they're quite apt and we've experienced, I mean, to a certain degree, if you're, whether it's intellectual property and instruments that reflected commodities, services, there's a lot of similar dynamics. I think the first generation of computation, no dynamics that the attorneys put in place was to not get yelled at by the business folks that we were slowing transactions down because they wanted to get a deal done, get it done quick, take advantage of the market environment as it were or whatever deal was, and so I think the first generation of computational dynamics and automation in contracting felt like it was there for the lawyers to catch up the speed with what the business folks wanted, and it was really kind of more of a, the phone rings and then we try to make the outbound executory computational dynamics as close as possible in the agreement. The, I think what we're gonna be seeing in the future is a lot of inbound dynamics as well, where to use a royalty example, maybe you have an agreement where the nature of the royalty is being formed by a whole bunch of market data, wherein if this number is here and this number is there, the royalties at this level versus that level. And I think what I'm seeing in terms of automated contract systems and much of the future of this is the process of pulling market marks, market data into the consideration for how transactions are gonna handle is less and less happening kind of just with a human pulling market data at their desk on a daily basis, what is more happening on an automated basis, showing what different profiles for market conditions look like. And that inbound data is coming in in more and more complex data sets. There's richer and richer data available to folks who are doing trading to the business folks. And what I'm hearing from those business folks is we wanna not only be able to do automation on the back end for how we choose what confirms we're gonna execute at any given moment, but to be able to do transactions quickly, but we also wanna have a certain little automation on the inbound data so that for a lot of traders and for a lot of people doing deals, the future is gonna be less kind of, I'm looking at this and then I'm making these orders and I'm kind of going from one spreadsheet to another manually. And it's gonna be more and more watching a flow of inbound data profiling market conditions that then trigger certain sequences, automated sequences of confirmation sets at different time periods and so on going forth. And so we're gonna see more kind of inbound automation and forming of data sets into systems that can accept that as well as more stuff coming on the back end. And the challenge is for lawyers is how do we create something that is open to be able to flow that inbound data and that outbound data and do it in a way that there's really appropriate breakers in the system. So just as the business folks are going to looking at more of kind of flows of data to transactions as opposed to kind of manually processing market data and then choosing transactions, as they're looking at more of kind of a flow of automation, the lawyers have to do the same thing. And we got to work with the business folks to say, what are the breakers, the circuit breakers we got to put in here? Under what conditions should this flow stop? If the market, if any market number exceeds this bandwidth, positive or negative percentage wise, should that stop the system and open up a dynamic and so on? In the past, a lot of that hasn't been automated and those questions haven't come up and the system tends to be stopped manually by the trader but in the future we're gonna have to look from a legal perspective, what are their systems that would stop the overall flow of services and quite frankly, are there things that would substantially change even the liability terms and other dynamics? There's a lot of different levers that can be moved under a master contract between the parties and the question is, is how can you kind of get to that? So, the future is lawyers gonna have to figure out how to watch those data flows and it's gonna be less of just how can we make the transaction paper and execute and automate enough so that the business folks aren't angry at us that we're slowing down business, the flow of business process and stuff like that but also how can we work with those business folks to look at how that stream of data to transactions can get optimized and again importantly, what breakers go into that system when we have to basically take it out of an automated ecosystem, stop the flows and begin some level of manual review. Here, here, and so Chris, we just wanna say we love you and come back sometime soon in person and hack with us and let's get you back on the whiteboard but you're speaking the gospel of law.mit.edu and it doesn't go without saying so thank you for hearing from your legal practice experience. A quick note on time. We're tracking a little behind. We plan this and so what we're gonna do is have the session go another five-ish minutes and then we're gonna reduce the wrap up at the end. Is it okay if we extend the time a little bit Christian? Okay, so we were going to close this, the next session it was gonna go from three o'clock to 3.30 instead of going like from 3.15 to 3.45 so we'll move it forward about 15 minutes and then we'll reduce the time for wrap up at the end of the day to about 15 minutes and perhaps we may extend a little beyond 4 p.m. I'm just saying Eastern. So with that, and that's at no additional charge by the way, and so Brian, you have been busting at the seams with some reflections on this in the insurance context. So it's not necessarily computational right now. A lot of the, especially the commercial insurance carriers and brokers, many of them have only recently gone digital within the last 10 or 15 years, but the way that insurance policies have been structured for a very long time is very much in line with kind of this object model sort of approach of creating something that can be used in a bunch of different contexts. And what I mean by that is with an insurance policy, your basic insurance policy object model is you're going to have a set of declarations where you kind of declare what broad coverage form and then in addition to that coverage form, you will have a series of endorsements which modify the policy in a certain specific way that is tailored to your specific kind of like use case or example. And while it's not yet at a point where it can be you know, has gone on for a long period of time and that many people, especially in the insurance industry like, but I think that there could be some lessons to be learned there as far as, you know, if we started doing this with, you know, I'm selling a widget from my factory and I've got my general master services agreement but I've also got, you know, a special deal for corporations and individuals who align with my interests and a different deal from those that don't, you know, you can kind of start playing around with how you want your contracts to be set up. Here, here, and in the kind of commercial contracting space as opposed to in the way that insurance policies are structured which is pretty specific. The term schedules is very common. So you can have it like a schedule under a master contract or that sets, you know, even like lower price terms or slightly more or less or different, you know, sets of offerings and products. You know, different delivery terms, right? Am I speaking the truth, Chris? Yeah, no, I mean, you can have any number of exhibit schedules that, you know, lay out, you know, sometimes a complex dynamic on how someone's getting charged, when it can get service or product can get, you know, exchanged between the parties and so on. So yeah, it's, there's certainly a lot of them, a lot of different ways that I can get it set forth. The layer of master contract, you know, kind of often agreement and transactions but there's other types of creatures like a schedule is almost its own creature on the idea of having almost like objects that can be reused at different, at different points in transactions or across different schedules. Constellation of objects. Constellation of objects is another very fruitful way to think about how to encapsulate legal terms such that they can be addressed computationally. So we can engineer the law, the MIT way and just the way of science and engineering in general. And which of those objects govern? I mean, that's often, it does the confirm govern, does the payment and, you know, the schedule of payment in terms govern, does the master agreement govern and then you have different circumstances where which agreement in a document suite where governance might change between agreements. And so yeah, there's a lot of interesting stuff on that front. Here, here, here. So I wish we had a lot more time. You know what I was just gonna say, you know, if it like I think with tags and like getting into tagging those objects with specific pieces of information, you know, that opens up a lot of cool possibilities there. Here, here, labels. I'm sorry Chris, Mr. Barron. No, no, I was just agreeing with Brian. Okay, yep, here, here. Okay, so Chris, we've got a lot of people with a lot more questions than we have time to address right now. So I think one thing we can observe, by the way, is this flip classroom thing is definitely the way to go. So we can become familiar with the idea and then we can get right to the juice of questions. We can get better at lining the questions up so we can hit more of them and maybe we, perhaps we can even become more synchronous, asynchronous with how we do your questions. It doesn't have to be one day at one moment in time sequentially. Maybe we can find more ways to do that. In that spirit, I know we're trying to weed a little bit more of your time, Chris. Well, if we were to take some of the best of questions we didn't get to and share them with you, you know, by email later, could we maybe get a little bit more of your thoughts and share it back with the group? Sure, yeah, we can set up something like that where we can record some responses. I'm happy to take a few more questions. That would be great. And don't worry, there's not a tight timeline on that. Something I mentioned earlier is we're gonna be rolling up from this class through the next Computational Law and Blockchain Festival of Global Distributed Event in March. So we'll have time as we work together on other projects, Chris, where I can find a gentle way to get some of your feedback and make sure we get it back to the audience. Thank you so much, Chris, for your time. We're really, really grateful for you setting these foundation stones of computational law in the contracts context. And you're welcome to stay with us. I'm gonna ask Chris, if you'd join us now so we can get into some more foundation stones and cryptography, information security, and protocols. But Chris, just bless you and thank you for your time and sharing your wisdom. Well, thanks, Daza, you're too kind. And I'm looking forward to answering the follow-up questions. And I will hang out and listen to Chris as much as I can. I'm always interested to hear what's coming out of Stranger Labs and the like, so it's always good stuff. So I'll catch you guys later, take care. Thanks, Chris, bye now. And the plug for this plug-and-play guess, it was Stranger Labs and Christian and I met. So we're going now to the next session, which is the cryptography, information security, cryptography, and protocols. So please join us on that page to continue posing your questions and ideas and other comments and we'll keep that flow going. Can I ask you to help with that? Yeah. And so I want to just introduce and thank Christian Smith for coming and sharing this core aspect of computation itself, which is security. And that's how we get to some of these primitives. We're using words like primitives in law, but they really do source from this field. And we first met when you, well, actually first knew about you when you were working on Anvil, which is a really great open source project implementing the OpenID Connect protocol for token-based kind of multi-environment authorization tokens. And it's an interesting identity-related protocol. And then you came to MIT and did some, I think, really great work and some great relationships. Now you've graduated to a startup, Stranger Labs, where you're taking some of the best of your previous work and thought leadership and making it available to the bigger, wider world. And so I'm glad that you were able to come back and spend some time with us during a work day. What's going on? Oh, is that just too trippy? Oh, okay. Great. And to have given a bit of a lecture already, laying out some of the foundations and to talk to us about it. So I was wondering if you could just, first of all, just by way of introduction, say just a few more words about your world and like, what are you doing at Stranger Labs and what is your angle on this whole big world of security? So I kind of got into this space to begin with because I was working on a bunch of different startup ideas with different people and different projects. And we found that we didn't have the kind of infrastructure that we needed to execute some of the ideas that we had. And as a result of that, I ended up finding all these open standards and at the time efforts to create standards that were really interesting. And we wanted to use that stuff. We wanted to have the same kind of capabilities as the Googles of the world, but at this early stage level, which is a little bit crazy. The business guys will tell you don't do that, but for us, for the ideas we were working on, that was really, really necessary to have the capability. And since the stuff didn't exist in a way that was accessible to us, we just started reading RFCs and writing code. And that's- RFC is a way to express a standard or like a protocol. Yeah, it's a specification. The internet engineering task force is one of the big standards bodies. And they don't actually believe in standards per se. You never quite get to the level of a standard. Initially, it's kind of a weird, cultish set of ideas about these things. You hear a lot of people talking about standards today and they have a really different take, IETF does, than some of the other groups like W3C, which is an interesting subject that we could pursue at length, but to finish the background, I got into cryptography by implementing these specs. And it's kind of a paint by numbers thing that's very elaborate and requires very precise programming and real attention to detail. And then when you put it out in the wild and you want these things to interoperate with other products that are speaking the same language or using the same protocols, those little tiny just from the hell and pain of writing the code to implement these protocols and at every step of the way, trying to understand it. That's how I got into the space and started to learn about this. And so what, I guess, just in a nutshell, like what do you do? Like what is your job and what kind of, what is Stranger Labs and what does it even mean to have a work that involves in cryptography? Like you sit around and think things or you sell something or like, what are you even talking about? So we're a sort of position in the gray area between research and commercialization right now. We're looking at some ideas that are a little too, maybe a little too broad and require a little too much implementation to fit well in an academic research environment, but they're not quite ready for VC-backed commercialization. And the area that we're working on is privacy and data protection stuff. We have some new ideas about how to approach privacy and data protection and the kind of computing architecture and network architectures that can make that possible. And what we've been exploring is some of the fundamental limitations in the way the web works and the way traditional databases work and some of the newer ideas that people are exploring in blockchain and IPFS and different things like this. They're using cryptographic protocols but they're using them for, and primitives but they're using them for very specific purposes. And sometimes not always hitting the right buttons when it comes to privacy and data protection. You're here. Great. So I wanna just kind of launch us off by asking a couple of questions myself. I'm wondering what could the law learn or what could people trying to do innovation in law learn from best practices and I guess solve problems in the crypto and security space? So one thing would be, the first thing would be the right attitude coming into it. This is surprisingly, it's a non-technical thing but attitude is really important. It's good to have a scientific attitude and have the curiosity and excitement that really helps to drive science forward. Those are acceptable emotions in science where let's say rage or something like that. It's not a useful emotion. So that's good. But there's another kind of emotion that's kind of counterproductive which is you've seen a lot of this in the blockchain space in the past couple of years where people wanna create one ring to rule them all and they get really caught up in egos around what we're doing. You can usually tell this when somebody's speaking in hushed tones and I'm gonna tell you what I'm working on and it's a secret. It's a secret, don't go tell everybody but don't tell everybody. You can change everything. And I think that did you guys ever read the Kruger Dunning paper? It's a psych paper, it's pretty good and it talks about, I will bring this around so that it's relevant. It talks about being unskilled and unaware that you're unskilled, right? And there's a kind of bold arrogance that goes along with that and when you combine that with some, maybe some dangerous or difficult subject matter, the results aren't always good, right? So I think cryptography is just so damn hard. So in that paper there's like, you're skilled and you know it, you're unskilled and you know it, you're unskilled and you don't know it. Right, so which is the worst one. They're also making the case that by being unskilled you're not aware that you're unskilled. So those things play out in each other. You're not able to make those next steps. And cryptography is this really, really humbling subject. It's so hard that even professional cryptographers when they get it wrong, it's not that embarrassing. You kind of expect that whatever you do is gonna break and you put it out there and wanna have some real scrutiny and know that this thing that I make, I can't break it. Someone else can break it, but I can't because of the assumptions that I have built into my head and the thought process that went into making it. If someone else that's going to find flaws and break this. And there's a kind of a timeline that's lost on a lot of folks of what it takes for cryptography to become acceptable, for a new protocol to become acceptable or a new technique or a new primitive. There's a timeline where a lot of people are critically evaluating these things and tearing them apart the more the better. And then there's a half-life once they're created because context changes. And something that was valid today might not be that great five years now, right? So a question that comes to my mind then I'm gonna turn to Brian to ask him what we have so far from the audience and also just I wanna pump you up a little bit here please. I know you're listening and some of this is new to some of you but if you have questions, ideas, comments including just what does an acronym mean or anything bring it and we'll be monitoring that. But a question comes to my mind in terms of attitude which is such a great, I wasn't sure what you were gonna say when I asked the question. On attitude and practices and culture in science and certainly in cryptography we have the scientific method which is based upon very almost like harsh in a merit-based sense peer review and in order to test the assumptions and test the implementation. And then we at some point think it's good enough and but more to the point we put it out there in some way that people can see it and can try to break it by invitation. And then in that way and so this is a completely different mindset from the mindset of the ring to rule them all and there's a valid, there's a successful design pattern out there which is we're gonna invest in something we're gonna build it the best we can we're gonna try to just assert it slash force it a little bit into existence. If you were familiar with that but now I wanna explore this other interesting way which is certainly not familiar in the field of law where we prize secrecy and we don't always want people to review, we really don't want people to review our work. There's some client confidentiality caught up in that confidentiality but it's more of an adversarial in emotions like rage and other sensitivity are not unknown. What if we had a standard agreement before it went live that had an open publish comment period and a bounty? What if we said, okay show us like the most common scenarios that you can say are statistically not unlikely then that would cause litigation or liability or harm exceeding $50,000 within the first like two months. And then if you can prove those you get a little reward and guess what we amend it and we amend it until we feel like our work in the law is good enough. Would that be an example of this other culture? I think so, I think so. Like pen test my smart contract on GitHub. Yes. There's another example that law could borrow would be the idea of a blue team, red team. Okay. So where you have one team that's tasked with protection and the other team that's tasked with how do I break this? How do I break the security capture play? Blue team, red team. I'm so almost like adversarial network kind of a way to battle the test and then to evaluate and assess with some rational evidence. Your friend, our friend Bob Craig. Oh yeah. Actually Bob and I have had some really good conversations and one he talks about, he talks about how CIO of Baker Hostet learned big law firm. He talks about how law is really kind of wait and see like it's really reactive. And one of the things that's interesting about some of the recent legislation like GDPR is that it's a little more proactive kind of getting out there and reasoning and building up from principles and put forward this law and leave it kind of ambiguous and then sort out some of the ambiguities at court but can you try to even formally or by some method of generating cases that cover some of those dark quarters, can you do simulations? You need to talk about this stuff. Amen. Can you, we do attack simulations, a singe over there that's some penetration testing stuff. And, you know, just in the law on purpose and see what happens and see what kind of cases you might come up with. Here, here, and that very much gets us back to this idea which is almost an axiomatic at law.mit.edu. Can we engineer things? So we have predictable legal outcomes and simulation is a time honored way to do that. So, okay, what do we need to have a simulation do? What must it simulate? And when do we have the right data and when do we have the right kind of rules and what is the right statistical model and other algorithms so that we're adequately simulating the relevant factors so that we can establish a rational basis for predicting the legal outcomes in a certain matter. So I like where you're heading with all this. Let me ask a question now. What do we have from our students? Yeah, so most recent question kind of wonders about how we could combine, you know, law to some of these information security principles in order to set up computational legal frameworks that are kind of more in line with what we're seeing in the information security community. Well, I think the first step to this is actually literacy. There's a fundamental literacy problem because this is multi-disciplinary. And I think people working in security aren't always super literate in the legal matters and people on the legal side of things aren't super literate or aware and oftentimes very badly misinformed about the technological and cryptographic aspects of things. So the first step there is probably to fix that literacy issue, address that by having some cross-pollination and having both communities start to proactively try to understand each other and develop some common language would be a good way to do that. I think you remember that first good conversation we had when we met out at Central Square and we ended up, you walked me all the way back to my storage container, but what was gonna be like a 30-second, hey, don't you work at MIT? And then it was very involved, where we got deep into Alice and Bob and non-repudiation. I was playing through all these different permutations of legal scenarios when people could repudiate something and we went pretty deep. And I think that was in my book, that would be a good example of cross-pollination. You're getting to understand some of the vantage point in even vocabulary. Sometimes we're sharing the same things with different words. Sometimes we're saying different things with the same words. And sometimes we have different words and we're saying different things. We can be literate enough to be conversant in these things that go such a long way. You have to be able to map the concepts back and forth before you can start saying which principles apply and how can we build on this. And that's a conversation that needs to get started. I don't think there's a quick and easy path to going back to the question. Was, I think, did we cover it? Yeah. And now we've got, so we just had a nice burst of questions. Any other, anything else cut your eye, Brian? So, Ann's got a good question that I think would be interesting. It could be interesting in terms of like actually seeing something like this that maybe like a B-Sides or something, but are there databases out there that could be used to do some of these simulations where maybe you're trying to do a red team, blue team sort of thing or capture the flag with something that's in a database but that you can play with and break down and I don't know anything like that. I'm not sure what the question means. Something that's in a database? Yeah, well, so databases of like, I would imagine like fake legal data that you could use to kind of see where vulnerabilities might exist or maybe something like the Enron. Yep, yeah, exactly where I was going to. So can I try to reframe the question a little bit just based on the way Brian said it? We used to have some legal hackathons where we would take data sets that could exist in a database where we usually got a big flat file and there would be questions like in the Enron data set which was available as a result of litigation and we could also go back to Edgar Pylings. The question is, can you discover the shell game in the company based on like digging down in the disclosures and like how could you do that? Who can do it fastest? Who can do it most completely? How can you, can we get a dashboard on that so we can monitor things going forward? Another one is like we used to do all the time like a few years ago was a big data set from a government like we did a lot with cars and transportations where people wanted to build really useful apps for traffic and for parking and other stuff but the question is have we adequately de-identified the data? Can you re-identify people? And some of those we did end up, helped some of them to synthesize identity data and then de-identify it. So if they re-identified it, everyone was ensued but maybe those could those be examples of can we play these games with data? I think so, it's in my mind more like what, what are those ways that are like, is there a way to set up a pipeline for generating data like this? Almost. And synthesizing data. So we can have like sort of a playground where we can work together to solve these issues. This is a really, really hard problem to be honest. It's harder than it sounds what you're talking about because it's so easy to do data inference. It's so easy. This is something, I mean, Sandy's lab and folks there have put a lot of effort into reversing, trying to understand for a given set of data and a specific computation you might wanna run on it, is it gonna leak personal data or not? Right. And they've done a lot of work on de-anonymization and stuff like that. De-anonymization is surprisingly easy. It only takes a few data points to be able to work backwards and reconstruct or identify, probabilistically, who was this? I mean, there's only so many people that live at one address and work at another one. Yeah, right. And those are really interesting questions. But I think they're sort of jumping farther out ahead of where we're all at as two separate communities right now trying to put our thoughts together and find where the alignment is. That's one, I think that's probably a higher order set of problems. Here, here. So let me ask another, so I've got a lot of questions myself, do you mind reviewing some of the questions? Yeah. Is there any questions? Sure. But something that I've enjoyed talking about with you and that might be interesting to others to think about is this approach in cryptography to describing scenarios using a cast of characters that are where people kind of know what you mean when you say Alice digitally signs a message to Bob. And I can't remember living right now, but Grace, let's do Grace would like to get copies of all those messages as part of know your customer reporting or something like that. And then asking a question like what are the opportunities for Grace to gain more knowledge or to perhaps introduce information security issues as a result of this. Can you talk a little bit about what are these cast of characters and how are they used in cryptography to describe basic patterns of situations? And then what I want to do from that is just crosswalk it back to what we do with legal back patterns and how we do a legal analysis and see if there's not something we can learn. Yeah, so Alice and Bob stories are just kind of ubiquitous at this point in cryptographic circles talking about protocols. And they're deliberately really, really simple. They're simple because you want to be able to reason about them, right? You don't want to see in the scenario. So like a secure messaging protocol, for example, would talk about Alice and Bob and Alice wants to communicate with Bob, introduce, they want to communicate securely. They don't want Eve, the Eve's dropper to hear or to be able to decipher what their message is. And so designing a protocol would be kind of Bob looking at that scenario and looking at all the different ways that an attacker could possibly go about getting the information that's supposed to be hidden and designing countermeasures for that. One of them, the obvious one in this case would be encryption to encrypt the message as it's being passed back and forth. Okay, so, and these characters in cryptography at least have kind of personas that are persistent, right? Yeah, yeah, there's Eve, the Eve's dropper and there's Sybil who will attack with multiple identities. There's Grace as a government agent that tries to subvert protocols. There's some for zero knowledge, like Peggy and Victor, I think for zero knowledge proofs that show up and there is just a whole collection of them. They're even judges and arbiters and different kinds of roles. And what you get from having this standard cast of characters is that it's really easy to understand a scenario very quickly. Like who's doing what here? You already know by their name kind of what their role is supposed to be and it makes it easy to reason about them. Here, here. But so just to cross walk that back a little bit, you know, when I try to, first of all, understand cryptographic primitives and protocols, I've really come to appreciate and get a lot of value from this constellation of characters as a quick way to express the relevant information about a scenario so that I can kind of quickly get it and almost kind of express it like a syllogism or like a logic puzzle or something and begin to kind of go through every permutation and go further faster. As I've looked in the law to see, is there something like, why can't we have nice stuff like that to quickly get to the bottom? What can sometimes be a murky, lawyers are always saying it depends. And then you have to pay me to find out what that answers and what it depends upon. Can we identify upon what factors does something depend in a repeatable way? And can we express this underlying scenario so that we can start to develop dependable and usable patterns? One thing I've found, I'll just throw out there for people to think about and as a potential area for future work and student projects and research startups, I don't know, is when, if you just say a legal scenario kind of out of the blue in a markdown document, you can get picked to death by, well, what about this and what about that? And it depends on all of these other factors and you start context shifting quickly in ways that you don't with the level of abstraction with Alice and Bob. There's one area where I've found that where there's repeatable use of characters in its bar exams and certain law school like end of term exams where we have a legal fact pattern and they will say something like Jane purchased a used car from Alex and Alex disclosed this amount of information and this way Jane paid Alex on Thursday, on Friday, Alex discovered that there was rust in the underbelly and it was gonna cost $800 or something like that what are party A's rights against party B, what are party B's defenses, that kind of stuff. What's interesting about them is that in the bar exam in particular, there's big committees of people that actually are the authoritative guardians of what the legal outcome would be and so much so that they can tell you with this amount of information, you should be able to give us this amount of certainty with results and if you say these things then you can be a lawyer, like they really are the keepers of our closest approximate to ground truth without going and litigating a specific set of situations and it's an abstract kind of fact pattern, we call it legal fact pattern. I think it would be interesting some fine day to do something like the mock trial that we did together in this room and getting digital signatures, cryptographic signatures into evidence in the case to find maybe some well-worn bar exam questions and answers that have been published and then crosswalk them with a little bit of creativity and stitching but crosswalk them with a way to express them as Alice, Bob, Grace, Evelyn kind of crypto scenario expression and see if we can't truly align the business, legal and technology dimensions of a situation and come up with better nomenclature so we can know finally upon what these depend and how to structure things to start with. Could we do that, do you think? Is that, I know we have a devil of a time just trying to lay a foundation to get a signature into evidence but is that achievable? I don't know about the getting it into evidence part but the first place I would start to think to look would be something like band logic and formal analysis. The logic of beliefs where you're saying, Alice believes X and Charlie said Y, right? And you come up with a set of statements and then there's a set of rules for reasoning about that and it might not map exactly the same but might be interesting to see. I think there's a sort of natural boundary it's fuzzy to look at but it exists in a real way like laws of physics principles kind of way of where technology leaves off and law kind of picks up. Yeah and there's some blur in there somewhere I can discover some. There's some blur but it's kind of a consistent blur. Okay, I think it does, yeah it's not like Ben overlap. Yeah. Zoom out far enough so you can clearly see that there is. Yeah, I mean you always know. I mean if you understand law well enough or you understand technology well enough you probably have a pretty good intuition for where it's gonna start to get fuzzy, right? Yes, so before we go to another question you said band logic, what is band logic? Band logic is a method of formal analysis for cryptographic protocols. B-A-N stands for pros, a body and need them and there were three cryptographers that came up with this. They're trying to answer the question of how can we know that a protocol is secure? And the answer is you can never really guarantee security but you can try to systematically find flaws in a protocol design and their approach is based on logic and belief that's sometimes called which kind of has some interesting legal things. Very much so, I remember when you first mentioned this to me and I did some exploration, there's many areas of law. Probably all areas of law include this somewhat but some of them are almost mostly baked on it such as agency law when we really get down to what did a third party reasonably believe about the authorization of an agent with respect to doing business for a principle. And so like the principle said, you can be my agent for purposes of selling my house and then the agent to an agent and the agent then went and sold all the possessions in the house with a third party buyer, what would they have reasonably believed based on this statement and that relationship. I think there's some areas where we could start to, where we could apply band logic and we could apply codes of law such as the restatement of agency which gives some pretty good rules about the roles of parties and the legal outcomes when certain situations happen among stated parties, in that case it's almost always three, a principle, an agent and a third party and something always goes terribly wrong. We have to figure out who's left holding the bag. I don't know if these things map directly. I don't know if you can just start writing band logic statements and kind of map that directly to law, but it is an interesting conceptual overlap and idea. There's another one that I haven't really explored as much called strand spaces that kind of deals with a series of events for each actor and then kind of trying to threaten them together. It's really, really interesting, really interesting. So we can get into more sequences and flows and maybe like that. In a simple way, sometimes we do a swim lane diagram but strand logic takes another level, right? Yeah, it's a different approach. Different approach. Okay, so some good things to be thinking about here. Band logic, let's bone up on that. Strand spaces. Okay, so Brian, what do we have? So there have been a couple of questions that are percolating kind of around ways that we protect information generally. So one of them, I'm gonna kind of meld two into one, but one of them asks more about learning some about zero knowledge and other ways of protecting privacy and then kind of the differences. The next one kind of wants to look at some of the differences between things that are hash versus things that are encrypted and just because something's hash doesn't necessarily mean it's encrypted. Sure, sure. So both of those seem to kind of be looking for cryptographic answers to things that require starting from a couple of more basic steps, which is security goals and security principles. What is it that you're trying to achieve? You're trying to achieve confidentiality. Yeah, yeah, exactly. So there's a kind of mapping of the security goals to cryptographic primitives as countermeasures, but your skipping is a few steps if you just say, well, confidentiality doing encryption and integrity use it or authenticity use a hash or something like that. You're missing a few steps. And I think people are misunderstanding the very, very basics of cryptographic primitives a lot of time in questions like this. And they're missing the idea that you have to have some goals and then you have to have a threat model. You have to have some idea of what you're trying, how someone would try to break your security before you start choosing countermeasures. It could be completely worthless to encrypt something on disk if you're sending it in plain text and someone's packet sniffing and listening to the thing. Or I mean, there are any number of scenarios like that and it's not necessarily good to just do everything, like go through a checklist of things that you're supposed to do and do everything because then you're maybe increasing your attack surface. Maybe if you haven't thought about the interaction of protocols or things like that. People really need to be thinking first about what are their basic goals? And I can tell you an area where this is really, really murky and blurred and confused is when people are talking about blockchain and IPFS. Now you start comparing that to GDPR. Well, you have these things that have immutability as one of their stated principle characteristics. And then you have GDPR, which has this right to erasure. Right? Well, how do you reconcile those two things? You really can't. And there isn't any cryptography that's just a blanket answer to some problem like keep my data private. It doesn't work like that. We have to be a little more surgical and get a little more granular and solve very specific scenarios. I'd like to get a little more surgical. Well, actually, I'd like to introduce people to the idea of a scalpel suction, a gurney, oxygen so that they can begin to think about performing surgery. And so I'd really ask that you not encourage people to perform surgery. I would like to provide more tools so people can begin thinking about building secure systems and that also are enforceable and reliable with legal outcomes. OK, yeah, no surgery. And so can you go right from what you just said now about looking at security goals and goals generally and map appropriately what your approach is going to be as a proportional and responsive to the goals. You mentioned basically the kind of like a threat model. But there's a particular thing I'd like to ask you to talk a little bit about for mapping threats. And it's the threat tree. Attack tree. Attack tree. Excuse me. I meant to say attack tree. Could you talk a little bit about attack trees and some kind of easy to understand context so people can know what this process is and we can start to think about in day two and three how we can apply it to some scenarios. So let's say I have some bars of gold. And I'm not going to just leave them laying there when I go away because somebody will probably come up and walk away. They're valuable. So I want to protect my bars of gold. Well, I go and I get a safe. And I put the bars of gold in the safe and I close the door. And there's one of those locks on it, a combination lock. And now as it could be gold, maybe it's information. It doesn't matter what it is. But someone, let's say, Syngin wants to get in the safe and walk away with the gold. He's from South Africa. Maybe they want to take it back. Hard to extradite. And so there are a number of ways that Syngin could try to get in the safe. He could try to cut the safe open. Now we're starting to work backwards from the gold. And he could try to physically get access to the safe in a number of different ways. He could do a burglary. He could pretend to be the cable man and come in like they did in that movie with the little car, the minis. What was that? The Italian job? The Italian job. A good one. Yeah. So there are a bunch of different ways that he could try to physically get to the safe. But some of them, it could involve deception. It could involve violence. You show up with a shotgun and blow the doors off and walk in and start shooting people or something. Or he could be deceptive about it. He could sneak in when nobody's home. And then he gets to the safe. And then he has to figure out how to open it. Well, in order to open it, he's got to know the combination. Or he has to have a way to cut open the safe. Then there's this notion of life cycle, security life cycle, that comes into it. Sinja was really, really sophisticated. Maybe he knows the safe manufacturer. And maybe he is able to subvert the manufacturing process or insert a back door so that he knows the manufacturer and he could find the back door. So we're into master keys, that kind of stuff. Exactly, all these different things. And so attack trees are this process of starting from the goal and working backwards in all the ways that someone could attack it. And you think about a lot of different aspects in this. What's the life cycle of the thing that you're trying to protect? Like we talked about, he could just show up and break the thing. That's like right now it's deployed as a countermeasure. But he could try to break it before it's ever in use. There was a case recently that I think it was disproved, but there was an accusation of chips coming from China with some vulnerabilities that he dropped to trade secrets. Yeah, IP issues. So you kind of have to be a combination of naughty and methodical to think about all the ways that you could potentially break something like this. And an attack tree is this big tree that you build up by working backwards to solve all the sub-problems until you get down to the basic leads. Well, he could aid or something like that. So the branch would be all the ways he could wrongfully discover the combination. All the ways he could forcibly enter. He could use some C4 and blow it. He could use a blow torch. He could use all the ways in which he could take the safe and get an abscond with it and then deal with it later. So these are like branches to twigs to leaves. That's right. And when you get down to the leaves of the tree, that's where you can start analyzing the tree. And you can start to prune out which of these things aren't really feasible. Yes. You can weight them and you can say which ones are very, very costly or that make them infeasible because of the cost or because it's physically impossible to do certain things to malibden them or something like that. You could basically find ways to narrow down to what are the feasible attacks. And then from there, now you're really starting to think about what's important to address here. Not everything that you could address, not hypothetical things, but things that actually, you know, this is sort of a risk process, risk management, you could put weights on these things to figure out which are the most important ones, what's the most likely. And then once you have them, you start thinking about what are all, for each leaf, what are all the possible countermeasures? What are all the ways that you could go or what are all the ways you could go about preventing that, an attack on that, right? Or preventing that attack. There might be many of them. Some of them might be very inexpensive but completely ineffective or they might be very expensive and completely ineffective, right? So you have to kind of evaluate all of that and then make some choices that are optimized around your goals, your means, do you have maybe a certain countermeasure requires that you have, is an armed guard, right? But you can't afford to pay the armed guard. But you could afford to pay your German shepherd dog food and that's one kind of countermeasure, right? Here, I remember in the, I'll just put out there. So don't, what Christian's saying is an informal response to a question, giving examples of things, but just to put a little more of meat on permutations of some of the questions you'd ask, it's always about preventing the attack on elite, but sometimes it's about mitigating or allowing some attacks are too expensive or don't make sense to prevent, but you can detect them before they're completed. That's the life cycle. So not just into the life cycles. Detection and response. And response and then sometimes you could do something where you basically render the goods unusable. So it's like, well, we can do some deterrence here and some other things like that. So thank you for explaining that. And I like encourage people to be thinking about this kind of structured thinking when looking at threats and potential attacks, when modeling the legal aspects of systems as well. Because a lot of what we think about in the law is when something goes wrong, it's a lot of sources of liability, sources of damages and ideally preventing that, but also mitigating it and absorbing somehow the risks of harm, and which I think we have a lot to learn, especially as the legal dimension, the business dimension, the technology dimension of online systems very much collapse into one thing. We'll need to learn how to be conversant with this. Speaking of being conversant, I see it's about four o'clock now and people have stuck with us, but I'd like to ask if you could, could you stick with us while we close up the session? Sure. So quick, hey, welcome back. So quick question from the core team is before I do a synthesis and wrap up, is there anything to, anything come up or anything to address? I think that's the only option is that this equals a lot of resources all of these issues that you can ask for the day. Do you guys want, can you join us if you're willing? Okay. And just pull a couple of chairs up. And so actually, I want to thank you, Christian. Of course. Awesome, awesome. Tour de force. Christian Smith, stranger labs. You're always welcome here. Thank you. Okay. So now we come to the wrap up. So actually, can you really quick share? Sorry, I said stay and I said go. It's always whatever the most recent thing I said was. I suppose. Okay, great. Welcome core team. So, so, can you just actually say what? Yeah. So this evening we're going to assemble all the resources you guys asked for throughout the day and then we'll send it out all aggregated in an email. So look out for that before class tomorrow. You're here. And another thing that I think does not go without saying is tomorrow we by popular demand are going to do a couple of online sessions. So we've got some things happening in person at the Media Lab. I know virtually nobody watching this is here in the area. So, but if you are here and you're interested in the in person events, check out the page and you know, for more information about that. We have some folks from the Red Bull team, I think with us now. IBM Piper Ledger is going to join us and George Howard will be primarily leading that session as we try to solve for some open music initiative use cases. For all of you, tomorrow we're going to be doing two. Three. Three, two sessions of online online sessions. The first one is at 1 p.m. to 1.45 p.m. The second one is at two something to something. About 2.30 to 3.30 to 3.15, so a couple of 45 minute sessions. And so a key thing we're going to do when we come together tonight and look through all of that, feedback that you give given and synthesize responses to the requests you have for more resources as well. So come up with a specific, simple as possible way that you can opt into these, to the different concurrent sessions that we'll start doing breakout sessions. What you can expect tomorrow for the breakouts are what? So tomorrow we're going to have one of one's breakout sessions within Serio and they will be going through some of the different ways that you can build interoperable apps and legal services. And they're specifically looking at apps that they've done in the Relativity platform and how those can be useful and kind of synthesizing a general sort of approach over the course of his lecture on Wednesday and his lecture on Thursday. And so one, and then Serio will be doing that walkthrough and they've got four apps that they've actually kind of built to provide his toy on kind of prototype examples to walk you through and develop and integrate something for a rest interface and get your OAuth tokens and what the data looks like and chased on. And it'll be very important. So it'll be one in the first session and a second one in the second session. And then we have more breakouts. Yep. And what else? And so in the afternoon we'll be doing the computational jurisdiction breakout session. Right. The, that's the, I'm looking at Brian. The Brian and Brian show. I thought that the defendant raised his right grounds. Right. And you point out the person that we're going to help us view that session. That is basically his session that was told by this very creative council general lecturer, Christoph Herrera. And when General Electric moved to Boston for their headquarters, they became a, among other things, a sponsored member of the Media Lab. We've had great relations on the research side between law.myt.edu research and their legal research. But their legal team, which is like thousands of lawyers, well engineered, FGE, it's not an endorsement. And there's, and so he posed at the MIT Legal Forum like a year and a half ago, this idea that's still very forward-looking. How could we have a computational jurisdiction? What would that, how could that work? So check out the video in the breakout page for that. And Brian, you listening, will kindly join Brian Wilson to help facilitate a discussion on what areas of law could be ready to be completely modeled computationally and what sort of data would drive application of those rules and what sort of algorithms would be used. How could we design and test something like that? And so Christoph kind of puts the gauntlet down with a challenge and we're going to try to brainstorm a little bit and talk about that challenge tomorrow. Any word from Christoph himself? That email up over, it was writing this morning. So Christoph doesn't know that we're talking about his session yet and I'm going to email him as soon as we're off here. I'd let him know and hope that what we need to do is ask him, do you have any ideas of things that we should talk about or do you have any further thinking on that? And obviously he's also invited. If he comes in, he should leave the session. Do we have any other breakout sessions tomorrow? Yeah, oh yeah. And Jameson Dempsey, who is the acting chair of Legal Hackers International is going to give us a little overview of this organization. He's got some great slides and a great talk and he'll talk a little bit about ways people can get involved all around the world and the type of activities that we do. And this workshop course in our open format is very much one facet of the sorts of things that you can learn more about and participate in globally through Legal Hackers. We are all Legal Hackers. All the guys. And so that will be a very good one. And then Thursday, and so then that will be what happens online Thursday, Wednesday, tomorrow. And then we're going to try to get even better at this and do six concurrent breakouts on Thursday where you can more find a more fine tune where you can choose your breakout. We've got some basic references from the Google form. And I think what we're going to do then just so you're not surprised by this is, and you can see this on the agenda, but we'll start the day with the breakout leaders. So about half of which, exactly half of which are in person, about half of which are online. We'll just reintroduce themselves, say like a minute about, like a fire starter, minute or two about what their breakout session is about. And then after about 10 or 12 minutes of that, we'll have an opportunity where people can select what breakout they're in. And some, if some breakouts don't have enough interest, then we'll do those breakouts. So then the breakouts have too much. We may see like, what's your first choice, second choice, third choice and do some load balancing. Based on the form, it looks like there's pretty well balanced interest in all the breakouts. So in my book, it's probably like two or three more people who makes a break-out session. What matters most is what you're interested in. And that will make a rich dialogue. And we've got some really great ways where we, the four of us as the core team, and then some kick-outs and help kind of work to create that. And we'll look more about exactly how we'll do that. We'll be able to announce after we figure out how we're going to do tomorrow and see exactly what's working all for those breakouts. We may get it right in a just as we go, probably. I think that covers it. So I just want to say thank you all for joining us and hacking the law with us over this first auspicious start day of a complicated law course of 2019. You've been great. I've been reading the best I can. It's like sitting from a fire hose on a pillow. And it's been really interesting. And thank you all so very much for playing along with us and trying out this pigeonhole tool. And let's see if we can't refine that a little bit too so that we can get more engagement on upvoting. I think would be the thing that most helps us key in on the things that you want us to address. So that's a work in progress. So thank you all for very much co-creating this course with us this year. And so we shall watch for those emails and tell you at 1 PM Eastern when we go live again. So now in honor of our legal hacker friend, Poppers, we'll carry it up to your popper's room. Happy, happy birthday to you. It's his birthday. Happy birthday. Happy birthday. Happy birthday. Hello.