Hello, I'm Patrick Dills from the Reach Lab at the University of Wisconsin-Madison, and I'm here to present on the stability properties and rendering limitations of admittance-controlled haptic devices. Haptic force-reflecting devices must be able to achieve a wide range of impedances to successfully render a virtual environment. Admittance-type haptic devices regulate a forced-to-velocity relationship to render a virtual environment to a user. This controlled topology typically renders large impedances easily, but has trouble rendering small impedances. Stability behavior is inherent to an admittance control architecture and limits the range of stable impedances that a device can achieve. This work examines the stability and rendering limitations of admittance-type haptic devices under a wider set of virtual admittances than previously examined, and identifies factors affecting the stability and rendering performance. Specifically, we examine virtual mass, stiffness and damping, and combinations of virtual mass, stiffness and damping. Our model used to analyze stability and rendering limitations includes a virtual admittance, a position controller, and a human impedance model. A single degree of freedom admittance control loop can be represented in block diagram form, and in the case of high performance admittance-type haptic devices, the control loop can be simplified by neglecting the human's disturbance on the high bandwidth position control loop. Considering high frequency behavior of the resulting open loop transfer function results in approximate expression showing the impact of the human's impedance, the position control bandwidth, and time delay on the minimum pure stiffness and damping and admittance-controlled haptic device can stably render. Results show that increases in position control bandwidth increase the minimum stable stiffness or damping a device can stably render. Furthermore, increases in time delay generally increase the minimum damping and stiffness and admittance control loop can stably render. However, if the device's phase crossover frequency is below the position control bandwidth, then increases in time delay can decrease the minimum stable stiffness. We also examined the effects of position control bandwidth and time delay on combinations of all three virtual admittances, and were able to create a map showing the volume of unstable impedances and admittance-type haptic device characteristically demonstrates. We experimentally validated these results with a user study where we asked six participants to interact with a single degree of freedom admittance-based haptic device. Participants interacted with bilateral virtual environments composed of a pure stiffness, combinations of mass and damping, and finally combinations of mass stiffness and damping, where we decreased the displayed impedance until unstable behavior occurred. Each user's impedance was estimated via frequency domain methods, and the data was used to generate theoretical stability boundaries, which compare well with the experimental results from our user study. In summary, we identified the effect of the human's impedance position control bandwidth and time delay on the minimum stable stiffness and damping and combinations of mass stiffness and damping and admittance device can achieve. This was validated with the user study, and we hope our work will inform the design of admittance-type haptic devices in the future.


Next up, we have Carlos O'Donnell speaking to us about securing GCC and G-Lib C. Please take it away. I really like Joshua's talk. I mean, we could keep talking about that stuff. I'm always interested in Yachto. I've done embedded stuff previously. Hi, everybody. My name's Carlos O'Donnell. I work for Red Hat. I work in platform tools for Red Hat. Platform tools is the broader team that provides C, C++, Rust, go system tool chains for all the builds that we do for Red Hat Enterprise Linux for the layered products above those things. The team is quite big. The talk that I'm going to give, and I'm going to have to start sharing my screen here in just a second, is here we go. The talk that I'm going to give to you was it was a team effort. Lucy Kerner, who is with us for Security Global Strategy and the platform tools team, how we put this talk together. So just making sure that everybody can hear me and everyone can see my slides right now. Someone give me a yes, we can. Yes, we can. Thank you. Excellent. So we're going to talk about securing GCC and G-Lib C. We're going to start. We're going to look at the past. We're going to look at the present. We're going to look at the future. We're going to look at some of the foundational principles that come out of us looking at the tool chain, at the behaviors that developers have in the past. And what we can do to secure GCC and G-Lib C, improve the security of the applications that you're developing. But before I do that, I want to start with a special thanks to Sudesh Boyarekar, who's on the platform tools team for security strategy. I also want to thank David Malcolm and Martin Seabor, who are part of the GCC team in the help of some of these slides together as we as we look over past present and future. So let's start by looking back at GCC and G-Lib C security. And I want to look a bit about the past practices in developing core runtimes and developing the compiler. And we'll see how they influence the kind of choices that we want to make, the kind of foundational principles that I think the new tool chain moves towards. And you'll see why those are important and why they're relevant to our future projects and why we would pick those. So just looking at G-Lib C, as you look back, and I've covered here a couple of points here, from G-Lib C 218 to 226, over the course of the years, we've had a number of these CVEs. And the thing that we see in these CVEs, the thing that's really relevant about these CVEs that happen in G-Lib C is that they are common defects. They're common defects that we see industry-wide. And that means that from a core runtimes perspective, we began seeing that we needed to adopt a more interactive model with the compiler, with the runtimes, working together in order to shift towards prevention. Because as I look back at these CVEs between 218 and 226, we see things like in the Get Outer Info CVE, we see integer overflows, we see stack and heap buffer overflows. In the Get Outer Info one, what's interesting is it's a pointer manipulation problem there. And in many of these cases, GCC, the compiler, could have helped us perhaps detect some of these things. So in the past, we begin seeing, like the G-Lib C developers, we begin shifting towards prevention. I'd say probably one of the most interesting things, and I'm a member of the Upstream G-Lib C Development Project, is we see a shift to WER, which is a real tight coupling with the compiler to make sure that if the compiler detects something, we're really going to go look at what the warnings the compiler has provided. And we're going to work with the compiler upstream to make sure that in that closed loop, the compiler is providing us good information about what it is that we're compiling in the sources, and that we're either correcting or adjusting those false positives. So this is looking back at G-Lib C, saying, hey, we've got these CBEs, we're going to shift towards prevention. And we begin to think that by W error, having the compiler always generate errors when we would have might have had warning. Now, what about the compiler side? What was the compiler doing at this time? So, you know, 2012, 2013, we begin significant compiler improvements, you know, in warnings infrastructure, in static analysis infrastructure, and that's based on common industry feedback. And so we begin developing the framework in GCC for the future static analyzers that we're going to be using and also for the warnings frameworks that we're going to be using to produce better warnings. And again, those better warnings coupled with W error, coupled with compiling the core runtimes of W error, are going to begin to produce that iterative cycle to improve the quality of the development process and the runtimes. On top of that, we have plugins and analyzers. And so one of the interesting pieces here is that, so G-Lib C has function pointers internally for certain operations that it does, those function pointers are relevant for us. Because those function pointers represent potential attack vectors. So in our case, enabling plugins would have been a plugin to look for function pointers in G-Lib C. And we'll talk a little bit about that in mitigation. So, you know, we see with the core runtimes, we've got CBEs, we move to prevention with the compiler. We're also beginning to shift towards prevention frameworks for detecting, improving warnings, plugins in order to analyze the code that you're actually compiling. But in 2017, we really, you know, we really turned towards improving the quality of, improving the quality aspect of prevention, which is this watermarking technology that we're going to talk about, which is Anibin and Anacek, which is actually a compiler plugin. And we'll get to that. So, you know, we look at the past and we say, we've had these CBEs in the runtime, the compiler, we really want to improve looking at the, you know, looking at the frameworks, looking at those things. And it kind of led us to these three foundational principles, which was obviously, I mean, not obvious, but, you know, when you look at them, you say, yeah, these are great. You know, prevention is better than mitigation. In many cases, if we can prevent or provide a higher quality FOS tool chain, then that means that downstream, customers won't have to schedule downtime. Customers won't have to review. Customers won't have to do upgrades because CBEs are present because we prevented them. But the important thing here is in the middle, we have prevention. We really want quality control to ensure that the compiler flags, the safety, the ABI, and the things that we want are all in place in the way that we expect them. And if either of those things don't work, mitigation is there if the prevention doesn't work. So let's talk about prevention in the compiler. So prevention in the compiler generally, two important things. We have buffer bounds checking and we have object size detection. Buffer bounds checking has been continuously improving since GCC9, array bounds, string operation, overflows. Those things are key because bounds checking provides us the ability to, you know, to look at whether or not you've overwritten those bounds. Object size detection is, again, important. And an important piece of object size detection is going to be marking up runtime headers with specific access attributes in order to allow the compiler when it's compiling a C or C++ application with those headers in that new markup to give you even better results when it's looking at warnings for compiling your code. So prevention in the compiler, we've got buffer bounds checking and object size detection. The, you know, the next thing in prevention in the compiler is the kind of dynamic aspect of the static analyzers which are, which had arrived in GCC10. The sanitizers, which are UbiSAN, T-SAN, A-SAN, they are shared with LBM and the new tool chains with GCC and Clang. And I would say plugins, plugins for the compiler. I think for G-Lib C, the interesting plugin was the plugin that Alder Hernandez wrote, which was a plugin, again, to find all those function pointers that could be attack vectors for the runtime. Because if you know, when you can modify a function pointer, you can modify the control flow of the program. And there are several ways, which we'll see in mitigation where we want to, we want to change that. So prevention in the compiler, we talked about prevention in the compiler, prevention in the runtime. The prevention in the runtime, the thing I want to highlight about prevention in the runtime here is annotations to library function headers. So as GCC's warning framework improved, it became apparent that one of the things we wanted to do is annotate headers in C and in C++ with additional aids to allow GCC to, for example, compute sizes of objects and also to know something about the parameters of those functions. And so we have access annotations now in G-Lib C that allow you to say, well, for this function, this parameter is read only, for example, or this parameter is write only. And so in that way, we've begun marking up the run times with access information. It actually allows the compiler to do a better job when compiling your code. That's an important thing to call out here as in for prevention in the runtime. So and I know I'm going quite quick. I do want to leave some time for people to ask questions and to answer those questions. But we've gone, we look at the past and we said, you know, we're shifting towards prevention. We said there are these foundational principles for the GNU tool chain here, which, which are, you know, prevent prevention is better than mitigation. We've got to have quality control. And at the end, we do need to have mitigation in the event that that your, you know, the prevention isn't enough. So what do we mean when we talk about quality control? So quality control, I'd say breaks down into three distinct things. The first thing I want to talk about is ABI tracking. Second thing is community process. And the third thing is the QE aspect of verifying that what you thought were your security mitigations or your security flags or security hardening that you put in place were actually there. So live Abigail is a, is a project whose entire purpose here is to serialize ABI artifacts, to be able to compare ABI artifacts, to be able to save from release to release. When I have a compiled library, C or C++, when I have a compiled object, what's its ABI? And then you can save from release to release. Has that ABI changed? That's all well and good. But the next part is upstream security process, which is you have to tell your users what assurances you provide about ABI. When does the ABI change? When does it not change? That's important because there's a lot of security defects that have to deal with sizes of things changing. And when those size of things changing, you get buffer overflows, you get reads of non-deterministic values. And so it's important that, that for an upstream project, you set security expectations appropriately. In G-Lipsy, we've been working on having a well-defined security process with exceptions. It helps the community understand where we will accept things and where we won't. So for example, some people often come to us and say, well, it's a regular expression engine, something that has security assurances. How much memory can a regular expression consume? The regular expression engine actually has a set of exceptions for it because theoretically you can write a regular expression that consumes a lot of memory. So you'll have to restrict the process if you're processing regular expressions and you want it to consume a finite amount of memory. But at this point, I would say we've done ABI, we've done that public security process with the community. The next piece we want to talk about is setting quality baselines. So within Fedora and within REL, we've been we've been working with a compiler plugin that is, that's called Anabin. Anabin has a dual, which is Anarchek. Anabin, as a compiler plugin, looks and records all of the options and operations the compiler took in a translation unit. It records them in the binary as metadata. So that at the output, when you're done producing all your binaries, you can run Anarchek and you can look over the analysis of what made it through the binary process. Did any functions attempt to disable source for incubation? Did any functions attempt to disable or change optimizations? And what this allows you to do is record what's there and then at the outset of the process, you can look to see, did I comply with whatever policies I had in place for the compilation of my binaries? For example, did I want fortify source equals to enabled and all my binaries was it ever disabled over some code? I will mention an interesting point here that there are parts, for example, of your runtimes that you may not be able to instrument. So again, you know, when you get to the Anarchek side, we do, there is this process of exceptions. But in general, once you have assured that you've got this API stability, once you're assured that you are, you know, your community understands your processes for exceptions, you then set that quality baseline for your for your generated binaries using using Anabin and Anarchek. So we've looked at, you know, prevention, we've looked at quality control and now we look at like what's the tool chain doing for mitigation for securing GCC and G-Lip C. In GCC, we've worked a lot on runtime traps. That's in in any case where you want to protect the runtime from carrying out unintended execution.  I'll give you an example here. F stack clash protection prevents jumping stack guards and it's generally done by the compiler instrumenting and probing the next page that you would access before you get there. The compiler mitigations are largely about runtime traps and runtime aborts to prevent bugs from being exploited. In the mitigation instance, when you detect that there's an exploiting process, you generally want to bring the process down to a state where it's failed safe. In in compiler and runtimes, we've recently added a new level of source fortification in which we tweak a little bit that balance between the runtime cost and the the amount of checking that we do. And this is a four to five source equals three. It was added to G-Lip C two thirty three and the implementation is immersion in LLVM and it's currently in progress for for GCC. And fortify source is that that again, we're looking at buffer bounds checking across across interfaces and across those interfaces to make sure that at runtime, the buffer bounds are what you expect. And, you know, it would be it would be remiss of me to not mention the belt and suspenders that we have with control flow integrity for hardware control flow integrity. So that's Intel CET and AR-64 is packed BTI. We have both of those in in GCC and in G-Lip C requires a compiler and a runtime and limit enablement aspect. And those are very interesting belt and suspenders when it comes to turning on for hardware that has these these control flow integrity state machines for tracking those state machines to make sure that the processes when compiled with CET are following the the are following what CET requires. That is to say that the control flow that is assured by CET is actually being met. This is very interesting for mitigating Rob cop and job kinds of tax. And so that we have that in GCC and G-Lip C. Now I had been mentioning in the past encrypting function pointers. The the the interesting thing about that is positive feedback that you get working closely with the compiler is you can develop plugins for finding function pointers in in G-Lip C and that you can come back and you can obfuscate those function pointers. And that's useful. You can obfuscate them with a bit of randomness. That's useful because in those cases we reduce ASLR leaks and and control flow exploits. So looking into the future, we have, you know, lots of project plans are focused, I think, remains still on prevention. There's key projects to improve mitigation. But let's let's dive into that. So prevention in the future, we've got brand new static analyzers in GCC for preventing use after free and double and double free. Those are going to be very interesting to watch them evolve to work with the compiler developers as we compile G-Lip C and compile the core run times and and and see how we improve those. I'd say future of G-Lip C. Something we've already done, which is removing malloc exploit primitives in the form of the current implementation was improved in G-Lip C-234. But I'd say there's there's almost this discussion of reducing attack surfaces, right? Removing the the unused converter plugins, dis allowing certain features, you know, from a from a from a prevention perspective. What we're doing is we're removing we're removing interfaces. So long as the user is capable of doing that. And containers are always useful because they allow us to play with some of these choices. You can have like a UBI minibus or you can have a minimal container that, for example, has a few of these things turned on in and provides different behavioral and also provides a different attack surface. Quality control, I think the interesting thing to mention about future of quality control is deploying sanitizers more extensive during OS development. I think there's this aspect of the core runtimes, particularly in G-Lip C, where we cut up the core runtimes and enable sanitizers for a larger portion of those runtimes, larger portion of the runtime components within G-Lip C. Some of the dynamic loader can't be easily instrumented with sanitizers because there's a chicken and egg problem. Sanitizers depend on the implementation provides certain functionality, so you can't always instrument that, but you can instrument a large part of G-Lip C. And I'd say mitigation in the future is going to be, I still think those sanitizers in the runtime. So in summary, I'd say prevention, quality control and mitigation are those key foundational aspects of what we're looking at. We looked at the past in G-Lip C and GCC, how that started, how our behaviors there started to trend us towards prevention. Once we thought about prevention, you're really into prevention, quality control, mitigation. What we've done today has been a lot of work in GCC 9, GCC 10, GCC 11, and in G-Lip C also to make sure that we have those pieces in place. And in the future, we've got lots more projects in order to ensure that the core system tool chain is providing you all the features that you need to harden and secure the applications that you're building with it. Thank you. And I am going to flip to check to see if I have any questions. So I'm just going to stop sharing right now. Yeah, you have a question already in the Q&A. I'll just read it. Sure. Can you speak to F-analyzer options added to detect CWEs and do you plan on enhancing the coverage for CWE detection? So tell us a word about F-analyzer. I don't have an answer for that today. So if you if you want to email me, we can discuss it. So I'd say there's probably a longer conversation to be had there. But thanks, John. And I'm going to see if there's a... How's this? You're not opposed to improving it. No, I'm not opposed to improving it. No, yeah. And I'm going to just look down. Sebastian Crain has a question. Do the principles you describe in the talk apply to the GNU Compilers other than CNC++ such as GCCGo and GDC? So the so Go is interesting and some of the principles we have here apply so long as the resulting output is an ELF binary and so long as you have, for example, dwarf debug information, because a lot of the way, for example, live Abigail and have been in Anachec, a lot of a lot of that relies on us having dwarf debug information generated by the compiler that we can use to reason about types and interfaces. It relies on being able to have an output binary that allows you to store metadata in it. So I think these principles are all at a high level that are applicable. The primary focus for Platform Tools Team has been CNC++. There's a lot of code that's being built in CNC++. Yes, today we are like Platform Tools. Absolutely. We've got teams working on Go and on Rust. So there are very similar questions about, you know, how we extend these things. I think that's very much a work in progress. Excellent. And let me go back. All right. Anyone else have any other questions? No, I'm very happy to take questions by email. Also, if you want to reach out to me, so. Yeah, do you want to post your email in the chat?  Oh, absolutely. Absolutely. Well, not like you couldn't find my email just by Googling, but yeah. Right here, Carlos at redhat.com. So excellent. Yeah. And I I've tried really hard to stay on time there for you, David, so that we can keep everybody going forward and getting the rest of the talks in place and getting people back to their their daily schedule. Well, I greatly appreciate that. And I'm sure everybody else does too. I will note that in this particular case, we have the interesting thing that we have a break coming up. So, but I'm sure people could use it a break. So always, always. Absolutely. Right. So, so folks. So first of all, Carlos, thank you very, very much. I really appreciate the work you and everybody else is doing there and for you helping to share about it. All right. So thank you very much, everybody. We have we have a break scheduled up next. We are scheduled to return at twelve fifteen with lots more interesting talks to come. So please take a break now and we'll see you at twelve fifteen. Thank you so much.


Here's what we're going to do. We're going to talk about South Africans with rotational shot put, how to get more throws in, what to look at, what to think about, and we're going to talk about it all in this video. So here we go. Check it out. Hey everybody, it's Eric Johnson from Airtate Throws Nation and in today's video, what we're going to talk about is the next video in the series and we're going to be talking about South Africans for the rotational shot and your wall throws. Now again, the reason we're advocating wall throws, when you go into the off season, you need to be able to get in a higher volume of reps in a shorter period of time. Crunch time is one of the big things people face. You have limited practice time. You have limited training time. So how are you going to get in a nice volume of throws that you need to get your improvements? Wall throws is that answer.  So that really helps to keep the pace moving or just cuts down in the back and the forth. You can get your work in. The second reason is when you're throwing into the wall, you're not focusing on distance. You're focusing on what you have to do technically. You're focusing. You should be focusing on feeling positions and just the only thing it's going to do is go to the wall.  And again, that's not to say we don't want to have our throws here in Arizona. We have great weather. We're outside throwing now a couple of times a week, but we take a couple of days a week tour. We can just focus technically so that when we go out to the ring, we take that mindset of technical focus. And then when we crank it up, that's going to be a good thing. South African, this is nothing revolutionary, but the difference is with us. We're looking at the pillars and we're identifying the problems in the throw. And then we're putting together always a customized drill prescription for the athlete and every athlete that we coach in our program, even though they follow the system, they're learning the mechanics through the system and the six pillars. But we're identifying their specific individual needs and we're creating their own custom RX. Okay. So here we go. Now, one of the things he has to do is make sure he goes from left. He's right. He's going to go his right to left. So he's getting the right entry. He has a tendency to want to start here. Now a lot of people have systems where they're going to start this way and they're throwing this way and they're going to rotate and they're going to turn and drive. I don't think that's bad. I think what we're going to do is actually really similar that. We're going to keep the feet. We're going to move here. We're already basically starting with the sweep leg in this position and we're going to be able to feel the foot turn a little bit more and then we're going to drive across the circle. So he's going to work on again going. We're going our right to left. He's going to push. Okay. So now what we're going to do is we're going to take him back and we're going to see about having him start this way and he's going to wind and he's going to turn the foot so he can come out this way. So let's give that a shot. Okay. So what I'm going to have Carson do again, he's going to start here straddling and he's going to rotate this way so he can feel the push. Go this way. Okay. So you're going to see what we're doing by that. He's over rotating and he's coming across the circle this way. What we're trying to do is get him to keep the left shoulder out. Now if you've seen some of the Discus videos I talked to him about, we're trying to have him understand that the path of the left shoulder is going to be really key so that he's going to be able to come into this position and get his hips under him. He's sliding his hips and he's over rotating. So we're going to try that one more time and he's going to start here and we're going to go this way and he's going to push. Okay. So now we're going to be, he's going to feel that rotation into a linear path. Start with your feet even. More even. There you go. Okay. He's going to go here, turn the foot straight to sick. Whoa. Whoa. Whoa. Okay. Now perfect example of big over rotation. So he's not turning his knee here and driving this way. So this is the point of the wall throw. Very quickly we can identify positions. Theoretically I should be in the safe zone standing here, but as you can see, that wasn't okay. So key thing here is what we're identifying is his sprint. So here what we're working on with a, with a South African, we're working on kind of a transition from our pillar to into pillar three. He needs to feel the drop in position and that's a tricky thing to teach. You're pushing the knee and the hip forward and you're creating sprint across the circle into the middle as fast as you can that small in the shot put. We're going three foot six inches. It's a very short path. So here's where you're going to see the big, the big strategy change for Carson is how he's moving linearly into the throw and that's what we need to fix. And so what we're going to be doing is focusing on that pillar three drop in position and the sweep. So he's got to be able to feel this type of position into the throw and right now you can see he's over rotating. So we've got to change the path of the arm as it opens. So he opens this way into the throw versus getting to rotational, which is going to make you to rotational and lose that linear movement into the throw, which is what we're seeing a little bit. Okay. So here we go. And then we're just going to have him kind of throw. And again, this is the point of the technical focus. We're focusing really hyper focused on technique and this is a great off season thing to do. Let's go wind. That was better. Okay. So you notice he did a real good thing. He just slowed it down. Trying to feel positions and find everything we've been talking about and discussing. So he's going to do that again. And then we are going to wrap. We'll add a little more detail and we'll go into depth for drills and different things if you're an online member. So check that out. Okay. There you go. So good. So now we're starting to feel that change and that transition. So when we're doing South Africans, the point is we usually will do the drill. We're feeling more of this type of motion because this motion helps feel the load in the sprint. But in this case, we could see where we isolated and we're forcing him to feel this motion. So he's going to feel how to drive and go linear into the direction of the throat. So this is where we're piecing our things together. So you're going to notice in our system, when we're going through a progression, we're identifying the pillar issues, retraining those patterns and putting it together in the pillar connection and testing the efficiency of the newly developed pattern. Okay. So that's the goal.  It's technical, technical, technical, mechanical. Start. Don't forget times to work your rhythm. And then as we get closer in the season, becomes much more about rhythm and then less and less about thinking so mechanically and thinking more rhythmically. And that's why you want to get wall throws in because you can get that high volume of throws you need to set up those new patterns. They're going to help you throw a lot farther, faster. Be sure to check out our free mini courses on rotational throws and the glide for throwing chain reaction. If you're a online member, log in. We'll go through this same video in more depth. And if you're interested in becoming a member, check it out. So thanks so much. Hit that subscribe button. Be sure to hit the notification button and we will see you on the next video. The shot moving and we're going to keep the left side is going to have a point where the right side is going to accelerate into it. And so we're trying to increase.


The Royal Jubilee at the new patient care center, an absolute fantastic facility, officially open today and better care for families on the island, South Island's tremendous. From the very beginning I have supported and I have watched the development of the patient care center and today I am so thrilled to be able to join with all of you to officially open this amazing facility for all Vancouver Island families. The first hospital in North America with 86% single patient rooms, we have 500 beds, 86% of them are single rooms. This will really help us provide individual patient focus care, almost eliminate the potential for hospital acquired infection and provide the healing and therapeutic environments that patients deserve. The difference between my being in the old hospital and a four bed ward and now in a private room in the new hospital is just like day and night. I can wake up and I can look out the window and I see the beautiful view of Mount Tommy and I can turn on the TV if I like, I can raise my bed, lower my bed, make myself more comfortable in the room. I'm not sharing a bathroom with three other patients and I would think that infection control has to come down with that. First of all, a significant investment by the taxpayers when you consider that we're looking at a patient care facility worth around $350 million. The fact that it's coming on time on budget is something taxpayers can celebrate but in terms of the care it's going to provide to families and patients and the working environment it represents for healthcare professionals. All state of the art, all world leading and all good.


Alright, I guess we'll get started. Hi everyone, my name is Sohan and I'm talking about evolving exploits through genetic algorithms.  I've gone for many years. I do programming, I love viruses, worms, and I've been trained as a computer scientist and I do penetration testing in the daylight hours. But, you know, I'm still a noob. But, uh, this talk was focused uh, mainly off of uh, kind of uh, my computer science interests and uh, my job and my inner laziness wanting to come out. And I was looking at my job and I go, uh, what I do on a day to day basis is I exploit web applications. And uh, there's a number of problems associated with, you know, performing this task. And uh, the uh, the major ones are it is driven by the customer. So you have to provide them what they want. Uh, there's a small scope. You are only allowed to hit a tiny portion of the site. So you have to have a uh, scalpel-like uh, efficiency. You can't hit the whole web server with a hammer. Uh, you only have a limited amount of time. Usually very short. As in a day, two days, three days. Uh, and it's all report driven because it's based off of giving a report to the customer. And so uh, these problems were what has been driving me to look into this area. And uh, and there's a number of ways that I approached trying to solve these problems. And my methodology was usually run as many scanning tools as possible against a web application.  And from there, if it does turn out to be exploitable, I write and exploit for it. But uh, there's, there's a couple problems inherent with that approach. Because uh, the code coverage uh, is inherently small because I'm trying to limit the amount of code that I view on a day to day basis. Uh, so uh, I, I want to have myself view less code and make sure that the code that I'm viewing is actually uh, potentially vulnerable. Instead of just what have you. And uh, also the uh, inspection of suspicious areas that are discovered by say web scanners or manually testing. Uh, it's also time costly as well. Uh, and then additionally, the development of a working exploit for a site takes time as well because there might be additional uh, blocking uh, mechanisms in place like a uh, a WAF, a web application firewall which you, you can see you have SQL injection but all of a sudden you don't really have SQL injection because there's, there's an additional layer you have to break through. And uh, there's a number of really good tools out there for exploit discovery and development. And uh, I, I, I use Acunetix, Burp, Zap and SQL map very frequently. Uh, and they're all fantastic tools. Uh, but uh, I, I realized running uh, you know, some of the other tools like Nessus and map uh, other scanning tools uh, that there's, there's this, this problem. There's this very similarity, there's this very big similarity with uh, an existing industry. And it's a, it's a fundamental problem with web application scanners as we know it today. So uh, what up bitches? It's funny. He thought you were clapping for him. He's like, well I, you know, said SQL map, what? Okay. All right, you know why we're here? Wow, this first time I had, there you go. That's what I'm talking about. At the very back in the gray. No, in the hoodie man, bring your skittles up here. Oh, what is this called? Thank you. Oh my god. That was awesome. The price is right. You are here. All right. Thank you sir. Wait, what's your name? Connor. Connor. Connor represents all of you who are first timers. And Defcon. So foundational problems with current techniques. Sorry, that's all I know. I think he was talking about scanning. Oh, scanning. Scanning and software. Oh my god. Look, he's got a countdown timer.  Four minutes.  Well, thank you for the alcohol. I appreciate it. So, uh, back on track, the foundational problems that we have with web application scanners is that uh, the current main technologies are built around a signature based system. They, they have a understanding of what a potential exploit could look like. They throw it at the web server and then if they retrieve a favorable or unfavorable result, they mark it as a finding. And so, uh, this is, okay. So, so, uh, I thought, you know, hey, why not, why not take genetic algorithms and apply them to web applications? Why not take, you know, your average basic SQL injection and go from something that a web application firewall can easily protect against and a programmer can easily defend against to something that is, uh, more, more hard to, uh, to stop. And so, uh, this whole process of evolution is, is something that was really fascinating to me. And so, uh, so for this talk, we're going to use genetic algorithms to make exploits for SQL injection, command injection, and, uh, our attack surface is HTTP and HTTPS. So, uh, it's web based parameters. And, uh, we're not going to cover anything else. There's, this, this could be applied to a number of different things, uh, another, uh, JSON, Ajax, what have you. But, uh, just for the scope of this talk, we're talking about SQLI and, uh, command injection. So, uh, the tool I wrote for this talk is called force evolution. Uh, and it takes this concept of, uh, I, I'm going to use genetics to write exploits for me. So, I don't have to do it myself. It's, it's the inner lazy programmer. So, uh, what is a genetic algorithm? Well, a genetic algorithm is essentially, uh, you create a large number of things and in this case, there'll be exploit strings. And, uh, you look for a certain solution that these things will provide. And in this case, it'll be an exploit. Uh, and then you score all the strings performance using some sort of vague ambiguous fitness function. And this fitness function in our case, uh, we'll get into that later. But there, there is a way of determining, okay, using numbers, this is a better injection string than the previous one. And, uh, so our, our algorithm here is we have this loop. While we haven't found the solution, we score, we kill off all the low performing strings. Uh, we breed the strong performing strings, the ones that are more efficient or they bypass or they exploit better. And then, uh, we also mutate the strings randomly. And then once we have found a correct exploit, we display it and show it. And so, uh, the tool Forced Evolution does exactly this. We create a large number of pseudo random strings. Uh, they, we are pulling upon the history of all previous, uh, well, all that I could find. Uh, SQL injections and command injections. Uh, and using them to influence the population of creatures that we breed. So we're not, uh, losing evolutionary progress. We're progressing forward. Uh, so we're, we're, we create a large amount of strings and we breed in what we know has worked in the past. But we use that just to influence the population. We don't actually say, okay, we have a set of signatures because then we're back to the original problem. Uh, and then, uh, if we, if we go through the exact same process as a generic, genetic algorithm, uh, we send the string as a parameter value, either post or get, what have you. And then use the, uh, the response from the server to determine the score. And this could be many things. So there, we, we have a good deal of granularity in how we can score a string. And then, you know, just like the rest, we call, we breed, we mutate, and then it, when we find a string that exploits, successfully exploits an app, we display it. So, there's a number of things that we, we also need to talk about. Like, what is this fitness function? Like, how do we define, is this string better than another string? And, uh, there's, there's a couple of things that we can look at and say, does it cause weird behavior? Uh, is the string reflected? There might be a potential for XSS in this. Uh, does the string cause an error? And if so, it, uh, is our SQL injection or command injection displayed inside of that error? That, that gives us additional information as well. And, uh, also, does the exploit string cause, uh, goal data or sensitive data to be displayed so that we can see, oh, potentially this is, you know, a good exploit. So, once we've, once we've found out what a, a creature's score is, then we breed the top scores, and then we kill the, uh, the under performing scores. And, uh, the majority of, well, I can't really say majority, but, uh, a good chunk of genetic algorithms use this genome crossover. And this works really well in our domain, because we have these variable length SQL injection strings that we need to breed against each other. And so, the, this breeding process consists of cutting each string in half, and then mixing halves, and then mutating them. And, uh, the current implementation that I have in the tool is, uh, two parents create, uh, four children and also survive themselves. So, they pass on their genes, and they also live to see another day, until someone is better than them. Uh, now for the next step, like, what, what do we mean by mutating strings? Are mutating our, our exploits? So, yeah, that, my whiskey, oof. Uh, the mutation rate, uh, I found to be, uh, usually it's best to have it variable. Um, and there's, there's a number of operations that we can use, but it all boils down to three essential operations. We have mutation, changing a single byte in a string, we have adding information, and we also have removing information as well. So, it's, it's somewhat like, uh, natural evolution. And so, uh, say, say the example of the, uh, the pre-mutated string ABCDE, or ABCD, uh, the mutations that have been applied to it are, the X has been pre-pended to the string, the B has been deleted, and the D has been mutated to an F. So, hopefully that'll give you some idea of what we're saying. We're not doing anything crazy, we're just picking a random part of the string, and we're changing it a little way. So, uh, that's how we mutate the strings. Now there's a couple things to keep in mind as we go throughout, because we have this algorithmic process of breeding, killing, breeding, killing. So, our, our population is going to vary, uh, and the mutation rate versus search speed is very important, because, uh, if we mutate too quickly, if we say every single part of the, every single attack string that we have is going to change, it's essentially throwing random data at the web server, and it's really not efficient, it's not worth, it's not worth doing. It's, it's taking a bunch of dice, throwing it in the air and hoping you get all sixes. So, uh, it has to be, uh, tuned down to a point where it is efficient search. Uh, and there's also the, uh, the string call rate versus the repopulation speed. If you call more than you breed, uh, you're the amount of strings in your population will decrease and vice versa. If you, uh, repopulate too quickly, they'll be like rabbits and they'll denial of service around machine. So, uh, with these, with these things in mind, I went ahead and I compiled a couple of statistics on, uh, the, uh, the leading edge tools. And, uh, I did Acunetix, Burp, Zap, uh, the OWASP, Zap, and SQLMap, as well as forced evolution. And this, this is just the raw data, but I'll go through some charts to show you how it compares to them. Uh, the number of requests sent to server, uh, is, is a very significant amount. Uh, forced evolution sends on average maybe 10, 30,000 requests to a server. So, this is not exactly a, a stealth attack tool, but, uh, we'll get into some of the, the pros later. Uh, and the time to exploit is usually dependent on network latency. And so these, these will fluctuate a little bit. But, uh, forced evolution does perform well compared to some tools, but not very well at all to others. And, uh, the same for SQL injection. I also did the same statistics for SQL injection. And, uh, the, the total number of requests for server decreases dramatically because SQL injection has a finer way of expressing, uh, the score associated with the fitness function. The, there's, there's a better way and it's easier to score one string higher than another because you have more information to do so. And so it's naturally more efficient because it, it depends on that fitness function, that scoring mechanism to determine who lives or what string lives and what string dies. And so it reaches a solution faster. And the time to exploit as well, uh, decreases proportionally. So, uh, hmm. With that, let's go ahead and try a demo. May the demo gods be gracious. Because this, this does, uh, depend on, uh, Python import random. So, let's, let's hope everything works. There we go. Okay. Ah, this is terrible. I'm sorry. Okay. So we have a generic web application here with a log in form. Uh, and, uh, it is vulnerable to SQL injection as you can, I'll type in just some random characters and it doesn't, it doesn't bring back correct input and, uh, there's, there's also other problems with it as well. So we know that a vulnerability there exists and we can discover this vulnerability or this suspicious area like we talked about previously through other scanning tools. And, uh, now all we have to do is point, uh, forced evolution at it and we'll go ahead and exploit it for us. Let me see. My VMs, all of a sudden change size, sorry. Okay. So, and, uh, forced evolution will be up on GitHub in about 15 minutes after the talk. So, the command line options, I wish I had my glasses, are, uh, we have a target and for this we'll just do localhost and we have an address of the vulnerable web page. So in that case that will be sqli index.php and then we also have the vulnerable variable which, uh, I believe is password although I believe both would work. And then the method, the method previously was displayed as post or, I'm sorry, get, but, uh, the tool has, has both options. And then the other variables, we'll just include for completeness. We'll just include the, uh, the username. Typo? I would be dangerous if I had my glasses. Okay. Username equals, let's just say Defcon. And then we also have, uh, what, what will constitute a valid exploit? So in this case we want to get to the administrative area of the site and so we'll put in, uh, our goal text will be administrative. We'll just put admin because the tool will search any request or any response that it receives back, parse it and then, uh, determine if it has that string in it. So, and on the right hand side I have a tail of, uh, the current requests coming into the web server. So as, as we start running the tool that, that will jump up. I wish me luck. Here we go. All right, right now it has created a large number of strings. Uh, well, actually not that large. It's only about a thousand. But, uh, it's running them against the web server currently and it's scoring them based upon what does the, uh, the response it receives back. And it's taking the top performers and then it's breeding them. So right now we're at generation two, three, nothing crashed. Okay. And because this is based upon, uh, random, random strings, uh, sometimes the solution is found extremely quickly and sometimes it's, it takes a while. But, uh, because of the influence of the, the previous database, uh, this, this will become much, much faster. I'll take this back over to my side. So the pros and cons of using genetic algorithms, uh, the cons, they, there's, there's a couple major ones. Uh, this is not a very stealthy attack tool. Uh, as you can see this generates a large amount of requests to the web server and that's inherent in genetic algorithms as, as a whole.  So I wouldn't run this against, I wouldn't run this against, uh, yeah, a production environment. Job security? I don't know. Yeah, and, and it is a slower process to develop and test exploits, uh, at least from the front end. Because I'm sure anyone in the audience, when they see that SQL injection, they, they brr, write it out. Uh, but, and see the program took, you know, 20, 30 seconds to do it. And genetic algorithms will always be suboptimal to source code analysis because there's, there's just more code coverage you can do. Uh, but the pros, the pros for genetic algorithms and using these to create exploits are, are, are fantastic. They're, they're really cheap in CPU, RAM and hard drive and human time. Uh, you can run that on a Raspberry Pi. The, your only limiting feature or factor is the network speed. Like how far away are you from the web server? Uh, and as far as my time goes, I can just turn it on and it runs. I, I don't look at it again. It's good. Uh, and I feel it has more complete code coverage than other black podge approaches because not only does it have the signatures that the other black box approaches have, it also isn't bound by a box of thinking this is, or someone's saying this is what we know a good SQL injection to be. It doesn't have that definition. It's, it's limitless in its approach to the, the solution. And so that, that, that takes us to the, yeah, right, right now this tool will break web applications in the future. Uh, it might not do it efficiently, but as the, the database of, uh, SQL exploits grows, it will do it more efficiently. And uh, the, the, another huge pro for this is automatic exploit development. Uh, the, I don't have to invest my time into sitting down and figuring, oh, okay, I got SQLite. Oh, okay, there's a WAF. Oh, okay, there's something else. Oh, okay, there's filtering roles. This, this doesn't need to know about those. It just cares about that question and response. And so, uh, it's, it's really fantastic in that regard. And, and, and the last biggest pro for this is emergent exploit discovery. Because since this isn't bound by what we know as okay, this is a valid exploit, this will create new things, new ways of approaching problems that we haven't seen yet. And for that reason, I think it's absolutely fantastic and I think we should pursue this. So, in conclusion, you can download the tool, give me, give me about 15 minutes. And uh, there's my contact info, so.


Thanks for having me here. I'm actually, this is going to stay, I think I'm going to try to, because it's 20 minutes, I'm going to bounce through a lot of ideas and sort of hopefully tag them for more detailed and involved discussions during workshops and stuff this afternoon, rather than trying to go really deep into anything in particular. With that in mind, I'm going to talk about complexity in social and economic systems as sort of a leading point. So the reason that we have these complex emergent behaviors in our socio-technical systems is that we are fundamentally modifying the environment that we participate in. Actually, there's some interesting analogies to discussion of sort of biological evolution where our bacteria was functionally changing the environment and that changing environment changed the fitness landscape for the participation in that environment. And we're actually doing this in sort of macro human scale by engineering on the world and inventing things and building new technologies and fundamentally modifying the means with which we interact with each other and our environment, which in turn our social and economic behaviors adapt to. So this is sort of behavioral evolution. I'm going to be focusing on this from a sort of, social behavior and social ecological perspective, but I always find it fun to talk about how the sort of complex feedback dynamic emerges in these sort of what I would call cyber physical systems. And anyway, so this is sort of the main entry point. We have this overlap between the sort of temporal dynamics, how we behave, how that behavior changes the environment and how in turn the change environment changes our behavior. The sort of paradigms for complexity and engineering are not particularly new. I like to point out that the socio-technical systems paradigm was introduced in the 50s, the sort of second order cybernetics and the discussion of sort of control systems and the way we organize our societies and organize systems becomes part of those systems itself is sort of introduced in the 70s and was very popular in the sort of, I don't know like late Cold War post-Soviet application of engineering to sort of human systems. And now actually we have something that is a little bit newer. I like the term cyber physical systems there, things like our power grids where there are the economic loads put on the grid, the physical network infrastructure, the plants and various other forms of sort of business entities that actually collectively source power, source materials, source labor, like all the way down to the economics at the individual consumption of power level. Those systems are highly networked and in fact we see things like cascade failures when sort of part of a power system goes down, the loads get shifted and you can actually have the same systems that make the resilient in the short term can make it fragile because you sort of pick up the loads that were dropped and if that sort of overloads the system then you see more things go down. These are actually some of our best physical networked sort of multi-layer systems that exist today and I think it behooves us to study them as part of our sort of what I would say more social system studies as I get into sort of decentralized organizations, this is gonna be more about human coordination in a less physical sense. So this is a slide that I've actually given a 20 minute talk just on so I'm not going to do that right now but I am gonna highlight the fact that there's sort of a partition here across silos and across what I'm gonna call, I'm gonna call it scale here. I don't know that's the right word, at least in this context but our silos here are areas of expertise or sort of places where you can have understanding of the mechanics, the dynamics or behaviors in the social context and economic context. Here technology is here generally information technology and physical is the sort of more, the environment or the physical environment that you're interacting with and there are lots of cases where we look at one or two of these things together but when in our increasingly interconnected systems it's very difficult to fraction them apart from each other and still have a coherent view of what I'll call a generalized ecology. Like if this is a social and economic ecology then the environment is defined by technology and the physical environment but as the rate of change of the technological or physical systems rises it becomes less appropriate to separate the time scales and so we kind of have to reason them as that the systems that are co-evolving between social and economic and technological and physical but in order to do that when we pull that all into context we can't necessarily look at the full depth at the same time so we sort of trade our slice in silos for a slice in layers and the way that I've done this breakdown in my work is to focus on our sort of global systemic goals value flows like the desired emergent properties of a system which are the byproduct of the specific local agent behavior which is itself constrained by the patterns of interaction so patterns of interaction basically say what does it mean to interact? What is interacting? That's different from what interactions actually occur which is different from which sort of global properties emerge as a result of those interactions so this is still quite a sort of evolutionary dynamics like and as we get down into this trusted computation and durable data now we're talking about the way in which sort of novel information technologies are allowing us to sort of program these environments because we have cryptographically cryptographically guaranteed execution of code this is a bit like writing your own rules of a mini universe you're saying you are allowed to do this and not that and if you attempt to do something that the system doesn't allow it just doesn't happen unlike our traditional economic systems where basically you do anything that you get away with you pre-prescribe what you can and cannot do in these environments and an attempt to violate those sort of coded natural laws breaks but what's really tricky about this is that you don't really do this at a very human intuitive level to make it work well you're generally working in very abstract spaces you're defining you're defining the very notion of what is possible at an abstract level and it backs up to the fact that you have durable the last layer is what I call durable data or trustworthy state information which means that these computations can be state dependent which is what gives them real world like properties if you just have trusted computation but computation isn't over isn't able to write or read a trustworthy state then you don't get the capacity to sort of embed state dependent dynamics to internalize externalities like you want things to have the same property of the physical world if I want to move the state of the system I need to expend some energy or expend some resource or I can't simply arbitrage an environment I have to actually pay the price of moving it and therefore I only change the system in so far as I really, you know the cost is worth it and so there's this Pareto response that says yeah okay I wanted to move the system but I don't want to move it ad infinim because moving the system costs me energy and as long as my capacity is finite I can't diverge the system and so if we want to talk a lot more math later during breakouts I'm happy to do it this is a conceptual framework for being able to go basically to create sort of programmable environments where you actually have reasonable predictability of emergent properties but the point here is that emergent properties are not defined as equilibrium in the sense of exactly this will happen rather they're quite the opposite they live in much higher orders like if the system can be changed according a certain set of rules that means it has a set of reachable spaces and you're actually just restricting those reachable spaces and that means that you have some underlying universal properties that can be thought of as some Lyapunov function in a high dimensional space over a part of the space maps to zero or stays within a ball around a set because moving out of that set is costly and that the system is sort of attracted back into that set but this isn't a statement about the state you would, the first order state this is often a statement about the second or like even like the third derivative and it's constraining how much the system can move away from a subspace in a highly expanded view of the world so the last conversation has me really like wanting to go into math but I'm not gonna do it I'm gonna talk a little bit more about the technology because one of the reasons I came here today was to try to give this community more knowledge about what this technology stack can do starting from the sort of low level sort of rules that define networks decentralized networks and configurations through which peers interact at the computational level you can form peer to peer networks which are essentially communication and computation networks where each peer is essentially provably following the rules of the protocol and their behaviors are not controlled just the rules about what valid behavior is and the byproduct of that low level technology is to enable sets of higher level interaction patterns which are sort of if this is computational communication network this is sort of social and economic behavior where what one can do agent to agent here is a property of what this peer to peer network exposes so this gives you the rules of this world and enforces them and thus individual interactions are hey whatever follows the rules but then collectively those fit into these larger sort of networks of interacting activity sort of ecologies of behavior which actually results in emergent properties and from a design perspective you have to basically make claims about what you want what you're trying to achieve up here work backwards through this conceptual stack towards what I can actually build and roll back up to defining these things and essentially enabling and measuring the extent to which you're achieving your desired properties we generally approach this using a sort of formal scientific and engineering process which mixes basically three kinds of science right we have analytical most of the system design is Lyapunov theory a lot of it because I run a private research company is part of projects so I'm working on writing some papers and some tutorials when times available but the core sort of high dimensional representations of systems in abstract mathematical spaces allows you to do computer aided design essentially run simulations of those systems and refine your understanding of those systems and then ultimately implementing things observing real data which creates a sort of standard scientific feedback loop but we're trying to basically understand the implications of our decisions about social and economic rules one of the probably most important points that I make ever is that whenever you're doing this you are making subjective choices about objective measures there isn't an objective fitness in the sense like people like to reason as if there is one and more often than not you have to pick one to reason and then you have to back out in sensitivity test and understand what is the implication of making that assumption because you don't get to say well this is the social utility of the system like even if you go into social choice theory like there's a million ideas and none of them are inherently right and often they even conflict with each other so you have to basically say I've systematized this social and economic co-evolutionary system and at various points in the process I have made subjective choices of objective measures and so one of the most important parts about being a designer of these kinds of systems is to actually be explicit every time you do this and find ways to A, B test or sensitivity test those assumptions so sensitivity test when you parameterize things A, B test with alternative metrics and repeat the same experiments computationally when possible with different measures and see how robust the results that you've gotten so something might have nice dynamics and converge to an equilibrium under some and here I mean equilibrium in the sense that there's a low dimensional attractive subspace not that the whole system somehow converges to something static whether or not those spaces, the behavior patterns the sort of ultimate emergent non-equilibrium dynamics that have some properties actually are desirable is also subjective so it's a really weird place to be because you're sort of forced to simultaneously objectify but to do it well you can't actually trust your own objectifications so anyway, so I'm gonna talk a little bit about decentralization and organizations because I think these terms semantically cause a lot of challenges and in order to actually make any meaningful progress on any project you have to sort of get on the same page so I define organizations in terms of networks and just simply say that you have it can be multi-scale but for simplicity we'll talk about a network of individuals a network of individuals is basically going to say well, I have some form of interaction with another party and I have this interconnected web of labor activity, exchange trade, whatever and my organization can be defined as essentially a network of individuals now for the most part I'm dealing with sort of open social and economic environments so an organization might be a community in the sense that we know each other or have people in common or it might be something more formal like a corporation or a community that you join or have to get permission to join in order to keep something formal and abstract we're just basically defining them as networks over agents and when you have a network over agents you need to understand what does it mean to have a link and a link is a function of coordination and for whatever the context is we can talk about well we want to do something together, whatever it is and I have some rules, requirements, limitations whatever and you do and then the feasible space of links that we could form between us is basically the overlap between these two things and if there's no overlap then we don't link and it's no big deal because the system doesn't require that everybody's linked to everyone we just have to have this idea that there's this network formation game embedded in the idea of an organization as a network that determines whether or not we choose to persist or a relationship and that is an abstract concept because all we really want is the graph at this point you need a specific problem space a problem to be working on where this collapses to a specific something specific like an agreement in one of the projects that I worked on was to teach a class it was a project called Odom it's an on-demand education marketplace and the agreement pattern was a multi-party someone offers to teach basically puts out a thing that says I'll teach this class for this much money if so many people will sign up, et cetera, et cetera and people can sign up and once the preconditions are met for an event it's essentially locked in and there are penalties for reneging and breaking the collective contract but that's a feasible agreement space followed by events that transpire and then ultimately if the conditions are met it's determined to be an agreement and at which point reneging it has costs but that's a specific example the point is that you can construct sort of arbitrary coordination problems of the form each participant has a set of requirements and there's an intersection and only the agreements that fulfill the needs of all of the parties would constitute a feasible complete agreement and then I'm probably not gonna try to go into this too much one of the biggest challenges here is that these things are multi-scale so you can't just flatten it always and look at one sort of community or one group a lot of the times you have to examine the way multiple communities interact with each other so it's like the network itself is got a network implied by the sort of co-participation and I use myself as an example individually I am sort of motivated by impactful science and engineering research but I also have sort of a context as a member of a family where I expect some physical health and emotional connection I run a firm, I have a professional community I'm part of a government and society I care about this sort of world system and it's sustainable health I ultimately at every one of these levels of scale I could be a participant in multiple communities and I have individual relationships but I also have firm to firm relationships and I have even professional community to professional community relationships I ended up here because one of my collaborators in the sort of engineering research domain around social and economic networks was invited and he lives in Berlin so he was like oh hey you live in San Francisco can you go speak to this community and so that at some level was a individual connection that was manifest as part of a professional connection so one has to be really careful even about slicing these networks to finally when there's multi-scaling going on this really though comes down to scoping problems well so if you acknowledge the sort of superscope then you can prune it down to find the right dotted line boundaries that help you solve the problem in hand without having an a priori assumption of here's the template, you just model it like this and I found that to be particularly- Then if I mentioned that then this network become more like a field, don't they? Like a school of fish, it's not a network. It depends on how you like to define your networks. In math it's like- It's just static, like you're writing the lines and structures, fields is dynamic. Right, so networks can be dynamic but the mathematical object isn't richer it's like saying time vary it's just a mathematical state object that contains essentially nodes and edges and even it can have multiple classes of node multiple classes of edges the presence or absence of a node or edge can exit or leave over time so I generally work with dynamical systems and optimal control frameworks having come from a much more sort of robotic AI decision theory background and so I basically assume everything is dynamic state dependent and stochastic but that's when I get into my math and then we start to collapse as much of that out as is appropriate but you start with the assumption that basically things are big honk and mess and then you try to figure out which things you can collapse out and retain good paradigm like paradigm fit you want the model that you're imposing to be as useful as fit as well to the problem at hand as possible but you actually start with something obnoxiously general and abstract and you collapse it onto the problem at hand rather than sort of start with a template and say how do I fit my problem into the template I have at least, that's an element of process for me I find it to be pretty useful. There's actually an area of math that I probably I'm sure you probably have some adaptive networks where it's like dynamic upon the network and then also dynamics of the network topology itself changing over time and so there's different layers of dynamicism kind of in the math to explain it on the network a couple more minutes. Yeah, sorry. And yeah, so that's like multi scaling in time in addition to multi scaling in space so when you talk about the multi layers of time scales you have to deal with much like we were discussing in the biological sense you have environmental evolution you have this network evolving essentially what I would have called the ecology evolving which is different even from the individual agents strategies or behaviors evolving so the issue is that you can't always handle all of those things at the same time so you need to figure out what things are have separable time scales what can I assume is constant because it's moving too slow what can I assume is constant because it's so fast that it's at equilibrium and then there's some temporal phase in the middle that you can actually focus on but it depends on the question at hand there's not an a priori absolute right scale you kinda have to have this really big complex view of the world that's too messy to work with and then collapse it onto the problem at hand if you wanna be able to sort of make meaningful progress that's the experience that I've had so I wanna talk briefly about what decentralization is because this term is also very very loaded especially in the technical space that I'm in right now we have decentralization in a bunch of different metrics so we can think of it in terms of peer-to-peer versus centralized it's decentralized if you have a more peer-to-peer architecture it's centralized if you rely on a central authority but the notion of a central authority or a bottleneck can depend on a lot of different things so in the sense of transparency this is accessed information the system is decentralized in the sense that anyone who is participating is sort of permissively access has access to information which is different from the way the decision authority is exercised you can have systems that have high degree of information access but highly centralized decision making authority and actually my favorite examples are around the evolution of things like Uber and Lyft and Airbnb as centralized technology platforms that allow for decentralized activity so you have open access to information at the level of who's available to say provide you a service you have individual rights to make a decision to say go out and drive and there's not a lot of intermediation but there's still heavy intermediation at the technological level and the blockchain community in particular is pushing to make this technological system more decentralized but often they sort of conflate this with the decision making authority decentralization because even if you decentralize the technology the social and political and economic behaviors can actually remain very centralized even though they're ostensibly structurally the information access is available the platform allows it to be decentralized but the behavior is still very much like oligarchy so you have to recognize the difference between something technologically decentralized and something where the actual emergent behavior is decentralized okay yes Lightning Moon Per位 place cool so I won't show these examples from my work page but later this afternoon yes