So, Stefan Penner, there isn't a hashtag of my name, that's just my IRC. As you may have noticed, I love open-source software. I believe in continuous reinvestment, like our previous talk. I'm also a husband of a very patient wife, and she's actually here, so if everyone give her a round of applause, we have birds, and they like to pair program. One of them matches my color scheme. We did, in fact, choose the bird based on my color scheme. We have a new feathery friend. Unfortunately, when I tried to pair with him, turns out he can like one-shot headphones and power adapters, so he can't pair with me. But he's lots of fun. He actually helped us navigate up to Portland. So, it turns out I accidentally washed my passport, can't fly here, luckily I'm on this coast, so driving up from San Jose was actually quite fun. So, announcement, I now work for Yahoo. They believe heavily in open-source, and a large part of the Yahoo team runs some pretty massive EMBRA applications. So this is pretty exciting for me. So at first, I was kind of apprehensive. Yahoo, I think my first email address 17 years ago was at Yahoo, and I was pretty apprehensive. But being there, everyone is smart, that I interact with, is smart, motivated, and excited, and it's really cool to see. So what am I doing at Yahoo? I'm fixing EMBRA CLI issues. This is awesome. I think my wife appreciates this, that I have a little bit more time to spend with her. And this is loads of fun. So Yahoo is hiring. If anyone wants to come join me and have some fun, we are riding the Canary Wave on as many applications as we can. Talk to me, or talk to one of the other Yahoo's. And let's see if we can work something out. Anyway, so I love discussion. Feel free to ask me questions. But we went a little bit over before.  So there's a warning. Browser internals are like French to me. Can understand a few things. I can say a few things. I can ask where the washroom is. Esque je peux aller aux toilettes. It is very useful. But I might be wrong. So this talk, we're going to talk about some performance. Myth, mechanical sympathy, and then Ember's misalignments. So we all know JavaScript performance is all about how you enumerate arrays. And just in case you're curious, those are all different ways of enumerating arrays. That's it. Talk's done. Turns out, Tom and Yehuda fixed all the problems. All the HTML bar guys fixed all the problems. We're done. Thank you. So although we're neck and neck with React, I think we can do a little bit better. So up until somewhat recently, this is what JavaScript performance looked like to me. I think to lots of you as well. Until I started getting involved with promises and there was lots of complaints about how slow they were, but they provide this fantastic mechanism by which we can abstract some complexity. Promises were really slow. There was actually a blog post by Spion who enumerated these problems. And then all of a sudden, there was another blog post by Spon saying, I'm switching to promises. And basically it was because of this library called Bluebird, promise implementation. And Bluebird's author, Petka Antonov, basically without changing the external API, made promises at least an order of magnitude faster. So at this point, I'm like, okay. I had done work on RSVP and I was like, how on earth has he accomplished this? So I expected when I opened the Bluebird box to find 12 weird tricks to double your JavaScript performance. When I opened the box after some investigation, what would I say next? Might shock you. What if I told you promises using normal, get this, normal for loops were actually fast. I love this picture. I've been like carrying it from talk to talk. It's fantastic. So basically the TLDR of why Bluebird was faster is it did less work. You want something to go faster? Make it do less work. The question often is, what is the work? So in the Bluebird case, it was two things. Allocate less objects and then underlie, align with the underlying primitive. So figure out what JavaScript runtimes are doing and try to not fight them but work with them. And now promises are fast. But the most important part is this was done without an external API change. A wild ember appears. Turns out we care about making things faster without breaking externalize or minimizing external API breakages. So this is very appealing. Stability without stagnation. And boom, you guys saw this pretty awesome demo which I was a little bit nervous about since I'm giving a performance talk after that. But I had early access and I spun up the profiler and I saw these things. I said, ah, this is something React doesn't have. We can do better. So even with this item poten re-render branch, the ceiling I believe is still pretty high. We have a lot of fun work left to do and we can get way more performance out than we have even with that branch. How much faster can we go? Who knows? So there's another part and that is when we're developing we actually want to be able to develop faster. We just don't want to deal with esoteric ways of making things faster. We also want to be productive. And it turns out the same ways we confuse ourselves is the same ways we confuse the runtime. And often realizing what the runtime is doing under the hood might actually encourage good programming patterns. So it turns out by reducing the confusion we can actually make Ember even faster than it is today. So who here played Pokemon? Who here was able to clone rare candies? Well, for those that don't know what that is there was a glitch. And it allowed you to clone items in your inventory. So there's this thing called rare candy which would allow you to level up a Pokemon. But you could use this glitch to get many rare candies and level up your Pokemon really quickly. Unfortunately, as you leveled up your Pokemons if you allowed them to evolve too early you would miss out on some of their important skills. So as we work on Ember we have to be sure that we're not jumping the gun and we're not throwing things away that are actually good in favor of something that looks a little bit better but actually might lead us down a wrong path. So we have some important choices to make but it's often not clear which choices we can make. So as Ember evolves how can we make a choice that both is productive for developers and doesn't screw us when it comes to performance? So often I feel this is JavaScript performance. Who here doesn't know what cargo culting is? Well, anyways, South Pacific Islanders around the World War II era recognize that there was a correlation between the arrival of cargo and things that look like runways and planes and people working. They just missed, they weren't quite sure why that was happening actually but so they tried to emulate this and they just couldn't understand why sometimes cargo would arrive and sometimes it wouldn't. Let's be honest, a lot of times in JavaScript performance we make the same choices. We often hear X is slow, don't do X. We fixate on the X and we fixate on not to use it but as we know, anyone that's, yes, X is slow is the wrong thing to say. The more important question is when is X slow? Not just that, when is X used? Relative magnitude matter. Sometimes a very slow thing will actually enable less allocations or less work being done. So the better question is when is X reasonable and when is it not reasonable? But to make this choice, we have to understand what X is without missing the connection. We end up trying something and then we end up with Mr. Aleve's performance calculus. Two patches, 5% improvement, together 10% regression and we have done this countless times in Ember. I am at fault for lots of them. I'm sure everyone who has committed to Ember has. Contribute to this problem and we need to fix this. So there's this cool term that I picked up from Martin Thompson of Elmax. Elmax is a high performance trading platform and they achieved their high performance not by scaling out but by understanding the underlying hardware and the underlying runtime.  Basically the best drivers had the understanding of how the machine worked so that they could work in harmony with it. Rather than working against the runtimes, we can probably work with them, get a little bit more oomph out of them. So by correctly aligning the cars with the driver, the driver with the car, you're able to utilize the car to its full capacity. Turns out F1 cars, V8 engines, same problem. Yes, they have V6s but whatever. And don't worry, although I'm gonna be talking a lot about V8, these common paradigms and patterns really hold true across most of the runtimes. So the world's simplest example, A plus B. I stole this from Petka. I'm sorry but it's a great example. So what V8 does is it looks at that source code and it immediately emits some assembly. This assembly is fast but could be faster but it's extraordinarily safe because we can be adding two integers together, two numbers together, two objects together, we don't know. But the important part here is when it generates this code, it also adds hooks to record the type information for later specialization. Then as code gets hot, the type information is consulted to see, hey, can we specialize further? So basically if a function for A and B is used often and A and B are always 32 bit integers, we can specialize. How does this happen in V8? There's a optimizing compiler called Crankshaft that keeps track of the control flow, portable assembly and then emits native assembly for your particular runtime. How does this actually work? This awesome diagram by Mr. Aleph, source comes in, we compile something that's quick to compile, has these hooks, as stuff gets faster, we consult the optimizing compiler which gives us new native code that is more efficient. Ultimately, after the optimizing compiler is done with it, we end up with ideally something like this which is many times faster, but maybe more brittle. So to review, AST comes in, we first generate something that is safe, not specialized, as it's used, we can generate more optimized code for that case, mad science. So how does this work? Basically, types and stability and mad science. But Steph, I do more than just arithmetic. Well, it turns out there's these concept of shapes in the runtime and they allow us to take these same types of optimizations and apply them to the rest of our code. So if we look at this ES6 class or ES2015 class, it is a shape of, in this case, two slots, a first name slot and a last name slot. Here we have a rect, not a react, that also has two slots, but these two shapes are entirely different, just like an integer is different than a string, same thing. So when we go and instantiate a few of these rects, we have one shape, but we have multiple instances. Great. So remember this thing where if we knew the type information of A and B, we could specialize? Well, if we have an add heights method that takes A and B, rect A and rect B and adds them together, it's awfully similar. So as the dynamic portions are used, as the function gets hot, type information is recorded, and if we're always dealing with the same shapes and those shapes always have the same numbers or values, rather than having to do a very expensive property lookup, we can ideally know the offset of the integer and we end up with hopefully something as close as this in the ideal search area. So what this boils down to is if the runtime believes the code is stable and predictable, it's able to make things faster. As also as it turns out, well-factored code that humans can understand and read often has these characteristics. There's another aspect to performance, and that is the time versus space trade off. So the previous stuff was time-based. Can we make something execute faster? And the second one is space. So space takes up space, but also space takes up time. Allocations take time.  And in Ember apps, this is a big place where we are causing lots of problems. Things that cost us in the GC and space world, closures, objects, unoptimized code. So it turns up unoptimized code, allocates more objects, turns out even compile code allocates extra objects, and if we have too many different shapes, the functions have to be specialized too many times, and we end up with compile code actually causing more garbage collector problems than our app data, which is just bonkers. So what we need to do with Ember is we need to do less work, allocate less, and also align us with the underlying primitives. I have an expectation that reasonable code should be reasonably fast. In some places, there's a bug in the runtime that we can get them to fix. In other cases, we are just doing unreasonable things, and we need to fix them. So I have three misalignments that Ember does today that we're going to cover. So the first one is, Ember just does way too much work. The solution is do less work. What work exactly? Well, we saw a great example of this in the earlier talk. HTML bars and idempotent re-render mitigate a whole category of extra work. This is fantastic. The other thing is, as we're moving to Ember 2.0, we are suggesting people use actions up and bindings down. Turns out that explicit data flow is also less work. We don't have all these two-way bindings everywhere, potentially wasteful, potentially not even used, or even worse. Often applications I see that we're relying on like sloshing between two properties that are bound actually happens and no one even noticed it. We're just burning time that we don't even want or don't even need. And another part of this doing too much work is Singleton controllers make this problem even worse. They don't really have an explicit life cycle. When we transition routes, we're causing change events that we don't care about. When I leave the user route and go to, let's say, the settings route, and I'm tearing down information from the user's controller, it doesn't know that we don't care about it anymore. It actually propagates the same change events. This is exceptionally costly. As we move to routable components and explicit state, we will just be able to delete the component. It goes dead and it costs us much less than if we allow it to live and be live bound still. So this basically means as we make Ember clear, our app will get faster, and this is absolutely the case. So the second misalignment is in a knit and super. A knit and super, I believe, is exceptionally hard to learn. Even, I like to think, I know a few things about Ember. And I'm often surprised. Who has tried to subclass an array proxy. Turns out you have to do things in very strange orders, but it's because we're misaligned with how super should actually be working. This causes us to allocate extra shapes, which makes the runtime not be able to specialize correctly. It results in more compile code that we're not going to use and just a big mess. And it's not quite aligned with what the new specifications class and super objects have. So the solution here is to embrace super. So who's written code like this before? Where we have first name and last name defined on the objects. No one's written code like this before? I, everyone in this room that has written Ember app before has written code this way. And it turns out that these shapes here, they come and sneak up and they hurt us here. Because what's actually happening is we create a new person. We create two new persons. We have the person proto, which represents the class on the left. We have the person shape and then two instances. They are of the same shape. But when we go to set full name, it turns out that first name and last name were actually set on the slots of the parent. We set first name and last name. We're actually creating a whole new shape potentially. Sometimes V8 and sometimes run times are smart enough to catch this. But as we have more and more properties, we run the risk of creating multiple different shapes, which just means that code that should actually all be dealing with the same person shape might have to deal with end different combinations and permutations of the person shape, which is not cool. Also, it is not clear to define these properties on the prototype, especially if someone defines an array on the prototype and all instances share them. So the solution to this, I believe, is to change init and to change super so that we actually pass args in, default args, we just use JavaScript to see, hey, was args on first name set? If not, let's set Joe. And then we'll call super. And at the root super, we'll actually set the properties to the instance. What we do right now is we actually set the properties before init is called. So there's no way for you to know if there's a default property or if the property came in via create or new. So another cool thing of this before, right now there's actually no set of rules that will define how to use super. With this change, there's two rules. We call super if we are overriding a framework method and before we touch the this in the method. And taking that moving forward, that is all you will need to know about how to use super. So not only is this easier to explain, teach and understand, but it's more aligned with the underlying runtime. Thoughts? Anyone? Please show me. I'm excited. Misalignment number three. And this one is rough, but I believe we have a solution. So basically Ember object reopen is super powerful. It allows Ember to slowly augment objects as you pull in new features. So if you add in the router, you we can add features. It also is a great way for us to add deprecations and to pull out existing parts of Ember and store them as add-ons, but mix them back in so that we allow people to fall back to old functionality. But it turns out it is kind of buggy. It requires complex internals and is the root cause for massive amounts of our allocations and shapes. Solution is basically, I would like to propose that we limit reopen to only work until the object has its first instantiation. So remember that chart I showed of Tom and Yehuda's branch? Basically the most expensive things that are left are related to this lazy reopen code. So who here doesn't know what meta is in Ember?  Who's seen it but doesn't know what it is? All right, that sounds a little bit better. So although meta and actions four are very related, meta is a good thing, I think. We can fix it. This is meta. It's the heart of everything that powers Ember. It's how the listeners, watchers, events, CPs, bindings, chains, everything works as via these meta things. And in a normal application, this is kind of every class has a meta, every instance has a meta and the meta's inherit the same way the class hierarchy inherits. It turns out that most of these metas are fine, but the metas for the instances are what kill us. The flexibility that we need to support, reopen after the first instantiation, basically means that we are grinding against the underlying runtimes. So meta is basically for live inheriting. It does some crazy things that we can totally change. Basically every O create is a new shape. If we create 4,000 records, Ember data users basically, we'll have 4,000 different metas, meaning any code that touches meta, which is all of the super sensitive code, can't possibly be optimized. It turns out that if we can get rid of this reopen after first instantiation, we can actually make every meta the same shape and we can now potentially benefit from actual runtime optimizations in these code paths. And one trick that allows us to do this is no one inherits from the meta on an instance. No one makes a subclass of the user instance. They maybe make a subclass of the user class, but this little detail will allow us to shed even more of that performance problems that we saw. We thought meta was bad. It turns out actions for, which is heavily entangled with meta, is a little bit crazy. I don't know. Who here has run into this code before? I don't know. You look at it and you're like, well, I don't wanna deal with this. But as it turns out, applying these same rules, we can totally make meta listeners substantially faster. And how does this actually work? Each meta, which already has some problems, has another object called listeners, which has all of the problems that meta has and more. Instances is kind of the graph of the Ember object. But as you can see, the medas and the listeners in green, they're pretty fine because we have few classes in a system. We maybe have hundreds of them, but we can have thousands and thousands of instances. So if we can optimize those last ones, those last pieces of profile, go away. So solution. We will work with V8 to handle this better.  We will optimize meta's for instantiation and listeners for subscription. So I have an early spike of this. I can't demo it to you because it is not quite ready, but the early numbers are substantially faster than what we have today. So I'm quite hopeful of this. And if anyone wants to help, Yahoo is hiring, come see me or come see any of the other Yahoo's and love to work with you. Also, when doing optimizations, turns out premature optimization is not necessarily a great thing. We should only do it when it actually matters and we should only do it through the code that will actually provide us performance. But it's fun, yeah, yeah, yeah. Another thing that I have learned is that benchmarks can trick you.  The only way to have reasonable certainty in your improvements are using all the tooling available to you and work with someone else that can nitpick your work. And remember, actions up and bindings down. That's it, thank you. Any questions?


Okay, we are about to start topic about Turex toolkit and virtual virtual human interface so What is Turex interface is? it was introduced a Few years ago, I think long long time ago by open BTS project And it's a custom interface between layer one and transceiver. I Call it layer one because now it's not only a base station, but Osmocon BB may also act like a layer one and Yeah Basically, it seems to 3dp sockets be used Are it asking me not to call one of them control because it's already used It's a Turex control protocol. It's asking base and looks very similar to HTTP protocol You just send some response. For example, please tune to this particular frequency And you will get the response and even the response code like an HTTP but zero means okay, and there is also a clock protocol which allows you to get clock indications from hardware hardware clock indications and The last interface is data and here you send and receive uplink and downlink burst What is Turex toolkit is a set of tools I wrote in Python because I have been doing some development of Osmocon BB and Turex clone I will talk about this Later, and I had to test because at that time we had no We didn't support Transmit capabilities in TRJSM, and I had to test something Somehow test anything I wrote and This is why I written this and I Found out that it could be also very useful for different topics for example in general it's time to help with debugging of Turex interface and The first thing I wrote was to fake Turex, which allows you to connect Osmocon BTS it basically basically emulates transceiver And it allows you to connect Osmocon BTS and Osmocon BB together Without actual radio hardware So it's basically virtual UM interface because you're sending and receiving bursts here there's also some some supplementary tools for command ejection for example You can capture bursts on some interface but for example between base station and transceiver You can inject them you can generate random bursts just for testing And good news is that this part is more or less documented and now merged to the master branch of Osmocon Thanks to Harald for helping with this and The how can how can one use Turex toolkits? It's as I know it's now used by some testing setups in Osmocon project and In general it allows you to learn and research JSON without hard Yeah, I will try to repeat and In the bottom of this picture you can see the classical way of communication between JSM layer 2.3 application like mobile or ccch scan With the firmware where Osmocon is like a proxy between serial ports and layer 1 control protocol Which is carried over a unique socket and also connect TTC and 3 test cases to both Osmocon and Turexcon and Turexcon is also the application I wrote it's implement some parts of layer 1 for example like scheduling and burst coding and decoding and Then we get the most interesting part is here We have fake Turex application which emulates two Turex interfaces one for Osmobts another for Turexcon And for Osmobts, you don't need any modifications because it's like a regular transceiver like Osmobts in the Osmobts doesn't even know who is it and So one so yeah, you can connect them you can inject some commands using a simple tool called control commands you can for example Generate random bursts and inject them for example rage burst And also one interesting feature I have is Turex sniff It allows you to capture some burst on the existing Turex interface record and if you want to replay them using burst send tool and And if my use case of this tool was that I I had to capture I had to understand how basically TCH half-rate burst encoding works And I captured some flow of frames on some particular time slot and yeah and this is how it works in more details and fix Turex is also acts like a simple clock generator and as I already told control and data interfaces Ported The status of this project is we now have some simple simulation and randomization capabilities of both timing of arrival and RSS site we have support of burst capture burst sniffing and burst replay then and yeah The the future plans are Make a low multiple base stations to work with multiple mobile instances And this way we will be able to simulate some load base some I don't know stress test stress testing for base station or so on and then yeah bit Okay, thank you for your attention and if you're free to ask your question. This is a little story about my Way to the Osmo Defcon Yeah Feel free to append your questions to the array of questions and I will try to find the answer for you Well, not a question just some comment I think for testing there's much more that we can test using using this than what we do so far So at the moment we use it basically just to to generate valid messages mostly signaling messages from the TTC and three test case into the BTS and then we check whether we receive it on on the Aver side and vice versa and the other thing we test is I think timing advance and Receive power. Yeah, but it's not implemented. Yeah, remember. Yeah. Yeah, it's it's very basic there But I think there's a lot of things that we can test for example also in terms of DTX Testing Because it's very complex. It's I think the most complex state machine we have in the entire Osmo.com project is AMR DTX in BTS, so I think there it could could help us to really Test all the different cases and see how the systems behave in in in all these different state transitions So it's very useful Thanks Very easy question to answer for myself, but I'll ask it anyway. What what's What is this? CPU usage of the of the fake TRX is it is it heavy on? I measure this and one for example if you would Use all time slots of a single base station. It will be on my CPU. It's Intel Core iPad I don't know if I'm sorry. I don't remember. It is about 30 persons 13 Or about 10 persons not too much Yeah, I mean, it's because there's no upconversion and anything like that and no no actual RF samples But it's just the baseband burst bits. So it's basically the encoder and the decoder that are Mostly the decoder probably the Viterbi that's using the CPU. Yeah, the main application of Factorix it simply receives the utp packages Changed a few bytes and header and send them forward them to the beta BTS and vice versa Not too much to do If you want you can use pi pi or Rewrite it to see it's not required. I think no, I mean, it's not the fake tier X I think the question was more in general in the virtual setup, right where the CPU usage is all fake Trix specifically because Yeah Well, it's Yeah, yeah, it's because the the things that the TRX does are not done really here Right, it's that the the Viterbi decode and so on happens inside Osmo VTS TRX And that's the same whether you have a real network or not But all the the signal processing Sample speeds that is not done here in the setup Viterbi decoding is also happening in a tier X cone application, but it's now we support some SIMD instructions and it's works really fast any more questions So if I have some time I can I would try to put some One more small talk and it is about GSM audio packet knife Because it's also a little bit related to the work we did if you Because I used it used this in Osmo BB project and there was some discussions about transcoding in Media gateways, so probably it would help someone I hope yes So what is the JAPK many people here asking me about this what is Four letters and it stands for JSM audio packet knife. It was initially written by Sylvain Okay, I need to finish and It is it can it supports the formats in coding and decoding for example you can I Don't know use a mirror or GSM fails in different formats. It supports Classical GSM codecs like full-rate half-rate or AMR Some some work was done by Harald to make it support also So you can use your audio subsystem on your PC to play and capture sound and Also some work was done by Harald to support RTP streams, but it's unfinished. I think and The use cases for of these two is for example transcoding one audio format to another It's a I think it's kind of ffm pack but for JSM codecs and you can yes perform transcoding between for example full full-rate audio into AMR you can Listen for real-time RTP streams and do any transfer if you want What I would like to say About the previous state of the project is that it was just a simple command line tool and There was no testing coverage. We only had some samples which We And what we expect after conversation and that's all we had and We had no shared the libraries and it was a single binary and it was Not that useful for me personally. So here you can see the example how to for example convert one file to into another and Why not to turn this into a shared library? It's I think it's a good idea and Audio coding support you can for example use this library for audio coding in Osmocom BB mobile application You can we are currently doing some work of Implementing jr. JSM blocks for a new radio to support Audio coding for JSM and it could be also used for Osmo media gateway to Transcore streams and probably someone else would like to use this What was what was done by by me is I Created a new library called Osmo JPK We just just Some some some work to put headers in common for Osmocom Projects location. There is a separate directory Osmocom JPK All symbols all exported symbols Have Osmo JPK prefix now It's requirement. We have package config manifest so you can easily compile your programs together link against this library and Yeah, we used and now we use a TALAC subsystem for managing memory management and We have some little bit better testing coverage, but not not full yet And what was changed is that JPK was renamed to Osmo JPK because many programs Have this prefix and it is linked against Libosma JPK Now we use Osmocom login framework instead of a simple printer of course and Some basics about the architecture of Osmo JPK it is It looks like a new radio flow graphs So you just need to create a processing chain. It's called qui in terms of JPK and They are Not that complicated like you can create in new radio, but you have only source blocks Processing blocks and sync blocks and that's it. There is no scheduler You just need to iterate through the chain yourself There is some IP for that and you can allocate a few processing chains You want to work with them somehow and yeah Here is some example how to create your own block because for Osmo ComBB I have some little experience of creating my own block and I will show some simple example So all you need to Describe is how much data are you going to receive? from different blocks in case of source it's zero How much data are you going to pass forward to another to another block and We have some internal state if you want to store something for example file descriptors or Sockets in case of RTP There is output buffer where should we write data? We just finish which we protest and there are two or even three I don't remember exactly callbacks. So one is Prots. It's just like working new radio and there is some Distractor if you allocate some memory This function should be used to free it and some meta information for logging And here is a simple example of how to create your own block This is File input and What is block is intended for is it just read some data from file and nothing else and then first first thing you need to do is to just allocate memory for processing keytem item, sorry and Define the type of this block. It's a source block and You can put some name You don't have input lens because it's again, it's source block and you have some Output data land and you just specify two callbacks Which the first one is like work function of in new region the last is Distractor and here are some example of how these Prots function can look like You just read some data from file and put it into the output buffer and that's it It's pretty easy and I recommend everyone to try to run or write your own block for JPK and It's really easy to use this library because we have not that much headers for our processing quiz and blocks you have Separate the header file for format. I'm sorry here should be codecs For codecs, you can use this header and all symbols have some prefix was my JPK Simple processing key to handle your questions I have a question like why not using g streamer or ffmpeg or I mean I'm not sure they actually support all codecs of just but then again if we're implementing them Why not implementing them there and just It's just a simple project and Ffmpeg is too complex to just to do some basic audio in coding. It's my opinion No, I mean one of the fundamental differences I think to a lot of the codecs that you find out there is for example that We have not fixed size of Codec frames, so especially if you think of something like AMR I'm not sure. I mean at least that was I think that's that's that's the difference, but For sure something that can be looked at CBR is not the only way to do it and like it's just many VBR Formats out there and fmpeg perfectly works is that I mean the reason I didn't use these tumors because if you look at the original source code of gap Like 95% of the source code is like completely correct specific and the actual stuff I would have needed to implement and the framework part. It's like 100 line and I wasn't gonna introduce the dependency into just trimmer and Jlib and All the initialization code that I need to set up a G streamer flow graph just to literally take you know the 26 byte or I don't remember how much and call one function and And store the odd putter. I mean originally that too was mostly because I was dealing with the You know the format that is generated by the the Rackle test set and The DSP API of the thing where most of the stuff is not even correct stuff It's reordering the bits because they managed to put all the parameters in you know, 50 different fashion Basically every possible combination Somebody used it Just seemed overkill I think another advantage of this exactly why not say if I'm back to see it's much easier to embed this I think Probably we have For sure you can compile it wherever in any way you want you can only compile some codex That you need exactly Yeah, if we have some time We have about five minutes, I think and I'm going to try to show some real example of usage Jpk in Osmocon and Osmocon bb for example Yeah Can I also ask What was the status with Elsa and RTP streams like this would it be possible to capture RTP stream off the wire and play it through Also, this is exactly what I'm going to show you You can easily can try some simple live demo. I think Oh Jpk we have more or less Complete help for that and for example, you can capture capture frames from From also Default Just need to specify which device are you going to use for capturing you need to specify the input format and in this case It's a roll frame format and it was very yeah roll PCM Then you need to Specify which codec are you going to use and which format to be more correct For example, if we would like to use, I don't know JSON for it or AMR Yeah To write this to some kind of output file in temporary directory like Hey This Yeah, it's just starting and we can try to send something say something here and It should capture and Now we can use the same tool to play these captured stream If I didn't break anything it should work You need to input file It's input format which we used used here and format we are going to convert it to roll PCM back and Play to also sync also Yeah default playback device Simple example Yeah, I hear myself here. Yeah, and here we have some basic integration of how do we demonstrate is that the congress? We are only able to normally decode the downlink frames But not happening because it's my bet because I initialized the JAPK library at the beginning of execution of mobile application and I should do this when Exactly when we start call and we finish call, but it was like a hack. So And it sure is it? Yeah Visible Yeah, I will show this so what's the idea then to use it with Osmo-com BV or Like do you have something in mind or is already working there or yeah, I can even try to do money to show this in in action So here my body miss preparing So an Osmo-com BV originally you could make voice calls, but the audio would actually be on the phone right no No, they we have MNCC in Osmo-com BV exactly. That's what how Jolly did it So the traditional way of using voice in Osmo-com BV is then that you Have the the voice on the MNCC interface and you can attach LCR to it or something like that And this is exactly why I use Osmo need be because we have LCR they're working at best Until we require support And yeah, also here you can see the fake T-Rex in action, so we just start Base station and we have our own virtual network We need to switch to mobile Start T-Rex call and you start mobile application Yum you for example, I don't know Let us to show this Again, we don't actually transmit anything Here's our environment We put some virtual SIM cards with the money Then we can try to test This is exactly what I demonstrated at the congress I'm correct how it works together with Osmo-com BV Nothing special. We have some problem with uplink For example, there is another number 993 And The problem is that we hear sounds from the past when we started mobile It already started to record the frames and put them to buffer and we read them to probably sound of my keyboard and Yes from the past crazy and yeah, that's that's all I We still have some and we Do some source code, but I'm not sure we have Yeah, if you have any questions, as usually feel free to ask


I'm Lieutenant General David Crum, I am the commander of Alaska-Norway region, Alaska Command 11th Air Force. It is to bring us all together as a joint combined and allied force to think about how we can defend the Arctic, how we can work together to not just survive up here but thrive and be able to protect our homeland. We've got a lot going on this winter. We've got cold response going on in Norway, icex underneath the Arctic Ocean, Arctic Edge, CSO 5, Noble Defender. And what this really is is a demonstration of how we can use all of these different operations to weave together how we can support our country to protect our nation's interest and of course defend our homeland as well. And it's just a really amazing way to do this incredibly vast geographic span of area and coordinate all of those military responses. You can't do it unless you've been here. And you can see by the whiteness around me that if you're not here, you don't really understand. And what the extreme elements, you know, we talk about the climate change and it is, it's creating more access but the environment is still really, really hard to deal with. And so the equipment has to be brought up here. It has to be serviced differently. You have to get the right equipment. You have to have the right training and you have to know the right techniques. And to be here and to do it in this kind of environment will make sure that we're ready for the future. Because you can't do it alone. Every single service, every single unit, every single person, they all bring something different to the fight. And we need that combined effort to get our nation's business done. No, this has been a great exercise. I think we've learned a lot. Our nations, both Canada and the United States working together, we've done an incredible amount together. And I look forward to the future.


Hello, and welcome to this episode of The Security Angle. I'm Shelly Kramer, Managing Director and Principal Analyst here at theCUBE Research. And in this episode of our show, we are going to talk about a CISO's take on the rise of AI-enhanced fishing and fishing. So to set the stage here as we dive into this topic, according to Deloitte, 91% of all cyber techs begin with a fishing email and 32% of successful breaches use fishing techniques. This is not really news to anybody that's paying attention. I mean, fishing is the number one threat vector that a lot of cyber criminals rely on. So we've talked about this a ton before. It's a given that I don't always feel bad when I say this, but this really is true. You know, we're the weakest link in the security chain. And so as we all rush to embrace AI in various ways throughout our organizations, threat actors are also wasting no time in leveraging AI-powered tech to help them, you know, supercharge their efforts at wreaking havoc, getting access to data and infiltrating networks.  And we're seeing them use things like automation and machine learning technology. This allows them to send large volumes of customized fishing attacks. These are called spear fishing attacks to target enterprises. And this increases the likelihood of infection. They also use three primary methods of fishing attacks. These are link-based attacks, malicious attachments and natural language threats. Today, I am thrilled to be joined by my colleague, fellow analysts and member of the CUBE collective community, Joe Peterson. And our special guest today is Bill Harmer, the operating partner in CISO at Craft Ventures. Welcome. Thanks for having me. So excited to start my week off with the two of you.  This is my move to learn something that surprises me. All right. So I have been in the IT industry for 30 years. I've been in security for 25. I started my security career in the adult content industry. So in building some of the largest porn sites in the world back in the late 90s, we were being attacked regularly. You know, when in 1997, you can make $20 million a year in pure internet business. You've got people coming after you. We were running dual DS3s at the time. And I love the way this comes out. I was running 90 megabits a second to the internet in 97. Everybody talks about gig off their phone today. But I was the single largest consumer of internet bandwidth from Bel-Canada, even beyond their entire home internet systems. So yeah, that's where I learned to craft. Back then, there was very little. There were no tools. We had to build our own firewalls or our own defense systems. We had to learn how this worked. And the only way to learn it was to actually do it. So we learned how to crack into stuff, how to break through defenses, and then start building off of that. I turned that into a career in startups. I went to Docspace, single largest, I believe it's still to this date. It was an $800 million acquisition by an American company of a Canadian startup. I went through the banking industry. So I did some time at Manulik Financial. And I very specifically say I did some time at Manulik Financial because that's what it felt like at times. A little different ends of the spectrum. Foreign industry and your financial services. Yeah, very different. Exactly. Yeah. And then I went back into the startup. So I was the head of security and the Global Privacy Officer for Success Factors. Pre-IPO went through that public offering into the acquisition by SAP. They acquired us for $3.4, $3.6 billion. Went from there to Zscaler, Pre-IPO. I was there for five years. Spent a couple years at Secure-Off. Most recently, I joined Kraft Ventures in 22, two years ago actually last month. Excellent. One of the things that, so thanks for delivering. I didn't know in advance what your answer was going to be. Thanks for bringing the porn. And somebody listening to this will be, what? But what so many people don't realize is that the porn industry has a long been on the cutting edge of advancements in technology. And so it doesn't surprise me at all that that's where you hone your chops and it makes perfect. It was the only thing that was making money back when building infrastructure was out there. So it literally paved the way. It's, I love to joke about it. For years I couldn't talk about it. Couldn't I? I was just a taboo. But nowadays it's one of those whatever, been there, done that, got a t-shirt. But we were doing things like live stream broadcasting. What we're doing today, this recording, we were doing live streaming back in 1998 because we had the money to buy the licenses, which were really, they were like $15,000 a license. But we would turn that around and try something like, I think there was a company in our building called 2x4. And they do like these annual general meetings. So they put on the stage, the lights, the cameras, and they do all the orchestration. I was sitting talking to the guy one day, I said, so what are you doing? He told me and I said, well, what about streaming that to the internet? And he was like, you can do that. I said, well, I can. I got, you know, two $10,000 cameras up in the office. And I got a couple of streaming licenses. We got some ISDM drops. We'll hook into the hotel. Went to downtown Toronto, set it up and broadcast one of the first annual general meetings to the internet in, I think that was like 98. So it gave us those abilities and, you know, the cutting edge, you could really try and push the boundaries on a lot of stuff. Yeah, absolutely. Well, that's fascinating. So let's dive into our conversation now a little bit and talk about generative AI. Oh, do you see phishing attacks getting a big boost from junior AI? So if you go back to like some of the original phishing attacks, you used to see those ones that had like misspelled or poorly worded. And for a long time, I honestly thought that it was just because it was bad Google translations, but it turns out they were actually being crafted that way specifically, they were looking for somebody who was not aware enough to pick up on the grammar or the spelling mistakes, and they were more likely target. And just because you said earlier that you don't like saying that humans are the weakest link, I don't like saying it either. In fact, what I prefer to say is that they're the easiest target. Because when you think about cybersecurity, even professionals trained in cybersecurity, it's difficult to stay current. And you know, if you were to put me into a CFO role, I'd be fired in two weeks. Like I just, that's just not what I do. And what we expect is we expect everybody in our organizations to be as good as us at cybersecurity. But on the AI side, the ability to now ingest enough data around tone and cadence and words that are used from say, a CEO, or understanding what people respond to by pulling their Twitter feeds or their LinkedIn or whatever, you can craft these things really, really well. And you can craft very specifically to the target, but you could do it at scale and at volume, right? So before, when you were hitting, if you're going after CEO, you see had one person sitting there working on it, manually creating it, working it. Now you can almost say, I want to target all CEOs across the oil and gas industry, and start building those fishes and start firing them out.  Absolutely. Absolutely. So I know that we've talked about this before, Joe. You and I talk about this all the time. But Belle, will you explain to us, to our audience a little bit about, you know, what we, so we talked about fishing, but there's also fishing and smishing attacks. They're also on the rise. Will you just tell us a little bit about those two different kinds of attack vectors? Sure. Absolutely. So, you know, fishing is the usual, send the emails, smishing is doing it across SMS, right? So the text based attacks that you get in, where you get the hello, hi, or more likely now what you're going to start seeing is something from your boss saying, I need you to do this. I'm not at my computer, right? They create a sense of urgency. They create a condition where you can't reply to them correctly or in the normal try to get you to break protocol. And fishing is voice based. So voice based or voice generation has been going on for quite a few years. One of our portfolio companies resemble AI, they build artificial voices for the movies, video games, stuff like that. So you can record voices and you'll get these now you get these calls where you'll be saying hello. And the key with this, I find is to stick with one word. Don't start using different words. Hello, hi, are you there, right? You're giving them different tone, different intonation, they're recording those things.  And what'll happen is they'll leave a voicemail.  I need money, right? I've got an accident. My phone's dead, I'm borrowing the truck drivers. And that's where they're going with this. And it's just it's going to become faster, cheaper. And those are the two pieces that are concerned. Once it becomes really cheap and affordable, then the attacks start to really rise. That's kind of crazy. You know, we talked a little bit about the ways that fishing is going to change. How have you found that AI has changed the fishing attacks? You can, you can now do live. So instead of just creating a generated message that fits out and either is left as a voicemail or just plays through. There's actually, I believe there's a security company, I think it's called Juniper, that will call you with this British sounding voice and they'll say, can I have 30 seconds of your time? And they got me. Honestly, I'll admit they got me because it sounded good. I was in my car. I had about three minutes to go in the drive. I said, yeah, I got 30 seconds. And I, you know, they had asked the question and I'd give an answer. And then I started to notice this strange, very specific two to three second pause at the end of every sentence before they came back on. And I was like, that was AI. That was definitely AI. And so I got the call again said, hi, you know, this is so and so from Jennifer. Can we kind of take 30 seconds of your time? I said, you're an AI. Phone went dead. Like literally, so they've even they're, they're working and they're using this. I'm willing to bet they're using this to absolutely make it better and better. But what you can now do is you can actually do deep fake voice live, right? So I could fire up an interface that my voice would go through.  If you can just get enough samples to build it, you can then create it. So that way, when people say, well, what about this, you can answer and it sounds okay, well, it sounds like a real person. I recognize the voice and it makes it more real to them. Yeah, this technology, this technology is getting so scary for video video fishing. So the video is coming as well. Yeah, it is all coming super quick. Well, and I think what I think about when it comes to things like this, you know, people like the three of us, we are public personalities, you know, I mean, in some ways we're kind of making it easy for people because we've got a ton of videos out there on the internet. So people have access to our voices and our intonation and all of that sort of thing. And so I think it's it is interesting. And I certainly it certainly gives me pause. Well, you know, go back to two factor, right? Think of the concept of two factor and go back to old school shared secret. Family members, especially kids, I learned this when I had, when my when my child was young, we had a shared secret. So if somebody was going to come pick them up at school, right, and it wasn't mom or dad, and it wasn't scheduled, we hadn't told them beforehand, if you know, I got stuck at work, even if it was, you know, granny and grandpa, they had to have the word, right? They had to have the shared secret. And we're going to see that more. I think you should see that more. It's a very easy defense for it. So if you get that mother calling, I've been in an accident. Sure, what's the secret word, right? And they're either going to hang up or say, I don't remember. And if they don't remember, call back at a band, right? Find a way to get a hold of them through your usual channels. That's clever. That is clever. But you know, as I think about this bill, is it fair to assume that given the sophistication of the of attacks enabled by AI that the only viable approach is to rely on more machines to sort of identify signals that are indicative of anomalous behavior, like a machine to algorithm or to watch for algorithms? Are we seeing that happen? Absolutely. Absolutely. So that company I meant to resemble AI, that's actually what they're doing. A couple of years ago, they started thinking about, you know, if we can build these things, can we detect these things as well? So they actually have an algorithm that can detect, I think with something like 90 to 95% certainty in under 300 milliseconds, a real or a deep fake voice. And you can use those in places like call centers where you can patch in and you could, you know, these calls are recorded for training purposes, you can now feed this into and see if you're being fraudulently scammed on that side. So, you know, no, that is not Bill Harmer. No, he did not, you know, authorize the bank transfer, et cetera. And then you can use it sort of after the fact to find out, you know, in the investigation of the forensics, what happened, you'd be able to do it there. It's difficult when you get into things like cell phones, because Apple and Android are very protective about getting in between the user and the phone call. So actually doing it live for the moment, I think, is not going to be there. But as we see sort of the advent of more small models where you're less carrying around a phone and more carrying around a small AI that handles tasks, because if you think about the whole concept of your phone and all the apps on it, right, your phone is there to make calls, the apps are there to read email, do banking, find directions, blah, blah, blah. They're all task based. When we get to the point where you're running a small model on your phone, you don't need the apps, you just simply need your model to take your instruction.  It knows how I pay my credit card, knows how much I pay, typically whether I pay clear or whether I pay minimum, blah, blah, blah. And it will go through those types of changes for you. And at that point, I believe it will be able to also listen in on the phone calls and be able to take action. So when you look at a Zoom or even a thing like we're doing right now, we could have an outside recorder that's doing note taking, those types of pieces. And I think you'll start to see come through on the phone calls where it would then fire up and maybe even, you know, maybe then the telco do it AT&T or Verizon would then, then you've got them listening in on your calls.  Right. Right. That's, yeah, that's a, that's a great question. Um, so let's talk a little bit about phishing emails. They tend to use specific linguistic patterns, um, you know, things like a sense of urgency, use of a bulk greeting links to malicious websites and attachments. I'll be one out of percent transparent here and tell you that I trust nothing. I don't trust anything from anybody when I get a link. I mean, I am looking so carefully about whether or not I should click on it. And I know, I mean, part of it is when you're immersed in the space, of course, you bring that knowledge and expertise to the board, right? But anyway, in addition to linguistic analysis, can you share an example of how an AI system can use NLP to extract and analyze entities that are included in our email content? Sure. Um, you know, you're going to see, um, patterns that are not typical of humans, which is really interesting. Um, at least for now, um, you're going to see patterns that are more grammatically incorrect or grammatically correct. And most humans aren't grammatically correct. Like we tend to have slang involved in, in the way we do it. And we're starting to see that in typing, right? Like you can actually type, I think wana or you can type, uh, you know, gotcha and, and it treats it as a real word nowadays. But I think what you're going to see is you're going to see that in combination with things like the headers that are inside it as well, right? That's, that's the thing about email is we could eliminate, I think a fair amount of this to a certain degree by implementing DMARC across the board, right? If everybody implemented and we would start to have some ability to manage around the fake email accounts or the overlays that sit in front of it to look like, because we use the, the, um, the, um, sort of the convenient, uh, email address, not the full email address. Um, and if you've got an AI that's able to read through these things and find them, find the ones that don't match, find the, and, and start to pop them up. And Google, I think, you know, Microsoft both do a fairly good job of this where it says, you know, it throws up the warning and says headers do not match or email does not match or this is coming from one that is internal and it's come from external. Those things, it takes that load off your plate so that you don't have to try and figure it out. Um, but yeah, you've got, you've got to start looking at the, the, the, uh, email as a whole. And that's why I think, truthfully, I think they'll get out of the email game and start getting more into the SMS and into the voicemail because it gets you out of the corporate governance. SMS is not very well governed even today. Yeah. And then it's easier to click the link because, you know, the, the email card, the SMS comes in and you can't right click it and look at it the way you can, right? So sometimes there's, you know, even I'm doing the, the select all copy pasted into a notepad and try to see what's beneath it. Yeah. You know, I have been deluged with smishing, um, at, at tax and in the last couple of months and it is so interesting. And it's from people, all kinds of people throughout my organization and the same, you know, this is John and, you know, like need a huge favor and it's a language, isn't quite right.  But, you know, and I'm gotten to where, and it's like, there's no reason for me to respond, but every now and then I'll just, you know, because it makes me feel good.  I'm on it. Obviously, you know what you've done? You've given them a live end to that number. That number is now ticked. Put it into another category where they can resell it. So yeah. Not to do that. Yeah. Never respond. Never, never, even as much as much as you like, and you see it with, uh, spam phone calls, right? Spam phone calls comes in and they're pretty good about, you know, warning you it's spam, occasionally not paying attention as soon as you hit it and you get no answer. You get three more calls after that because what you've done is you've confirmed a validation of the number. It's live. There's a person on the other end, right? And they, they can resell those to somebody else on the, on the dark web somewhere. Yeah. All right. So learn from me, people. Right. Right swipe. What is it? Right, right swipe, delete and report junk as to this possible report junk. Learn from, learn from my mistakes. So talk with us a little bit, if you will, Bill, about AI powered risk based authentication and why it matters. Well, so I'm a firm believer that there's nothing in this world that AI will not make better or worse depending on how we touch it, but it will touch everything. And authentication today is problematic at best. I don't know if you guys were aware a couple of weeks ago, it was revealed that the single largest database of compromised credentials was found in the wild, 26 billion. Yeah, it's, it's literally, it appears to be 10 years worth of compromised credentials brought into a single database cross referenced and indexed beautifully. And of course, you know, next, you know, I'm seeing people with Twitter accounts getting popped because yes, they have a complex password. Yes, it was very long. No, they didn't put two factor authentication on, and they've had years to brute force this thing. So the concept of using AI around authentication, it allows us to move faster and to always authenticate. That's going to be the future, right? We've been talking about multi-factor authentication. And for anybody listening, I strongly recommend you turn on any form of multi-factor. SMS is probably the lowest form. If that's all you have, do so, but otherwise, you know, Yubi Keys, Google authenticators, any of those. But until we get somewhere, until we get to a point where systems don't require passwords, we have to do this. But the AI can come in as we bring it in to the authentication and start to authenticate at all times. Like for instance, during this conversation, you know, perhaps I've got email running in the background and it's going, well, he's not paying attention to email. Why is he authenticating? Maybe I'd better check to see if it really is. And we've done this in light forms with improbable speed, which would be, we call it the Superman effect. You log in from your, I log in from my hotel here in Toronto. And then five minutes later, I log in from Kazakhstan. Improbable speed. Superman can't go that fast, right? So we know that, and that's a little bit of machine learning that says, oh, okay, that's not probable. We're going to block the second one or maybe we're going to block both. We don't know which one's right. But we're going to start seeing that from authentication perspective because right now we fire and forget on authentication. We authenticate somebody, we let them in, and then we hope that the permissions control what they do. And what we need to be doing is we need to be watching what they do and then adjusting their, their authentication as those things happen. So if they, if I suddenly clicked on an HR link, even if it's by accident, oh, wait a minute, he's done something that's anomalous. Let's re authenticate. Maybe we're going to buff the authentication where you go to factor, we're going to go to third party, we're going to escalate to a supervisor and confirm, right? And that's the kind of thing that we'll get to. Well, we need to get there quickly. Yes. Absolutely. So, so Bill, you know, you and I chatted a couple of times and during one of our conversations, you shared this really interesting concept of a digital identity that acts as a single truth. And we might get there. So can you take a minute and share your thinking about this? Yeah. So there is a convergence happening, right? I've been on the internet for 25 plus years. I have fingerprints and footprints all over the internet from me as a person. Um, and we're getting, you know, AVP, Apple Vision Bros came out and everybody's wowing about the augmented reality. The meta quests have been out and we are moving towards that, that immersive digital identity. And that's where I believe this goes. We have historical things in the US social security numbers in Canada, social insurance numbers, all fully compromised, every one of them. I don't think anybody and it's a single factor, right? It's Bill, he's this nine digit number, right? That's, that's all it is. We need to get to a place where we have a digital identity that is tied inextricably to the human. And I want to be very clear in this because it, it borders into the world of anonymity. I'm not saying we do away with anonymous access to different things. Freedom fighters, whistleblowers, journalists, people in duress, they need access to, to services through anonymous methods. But what I'm saying is there should always also be a way to absolutely say when I want to, yeah, this is me, you're seeing my video, you've got my email and here's my digital identity to validate it, right? And I think we will get there. Um, there's, there's talk of it in, excuse me, in both the US government and Canadian government that I know of. Yeah. But I, I think it's just, it's, it's, it's going to come. It has to show up somehow sooner or later. And I'm hoping sooner rather than later. Yeah, absolutely. No, no argument for me on that front. So, um, I know that you see a lot and, and hear a lot in your conversations with other CSOs and in their teams. And you know, what do you see the biggest challenges that CSOs and their teams are kind of struggling to get their arms around these days? Interestingly enough, I just did a panel this morning on, on one of the topics. And right now it's the legal impact of being a CSO. There is a lot of question in the industry of, could I do this? Do I? Yeah, do I belong here? We've had a couple cases. Sullivan's case has been, I don't know if he's appealing. I'm assuming he will be, but he, you know, convicted misprison of a felony and obstruction. Tim Brown, SolarWinds has been named by the SEC. He wasn't even CSO at the time. He is now. And it's, it's, it's tough. I mean, I say, I'm, I'm partially glad this is happening. I don't wish this to happen to anybody, but it is happening. It is legitimizing our profession a little bit more. We're showing up at the table now because we have skin in the game. Yeah, that's good. And I think a lot of CSOs are now trying to decide, well, I don't report to the CEO. I report to a CIO or farther down the chain. Why should I carry a chief title with the responsibility and the liability that come with it if I don't have the authority to manage it? Right. And I think, I think that's really what we're, we're, I'm seeing a lot of conversations around that. Everything from renegotiating employment contracts to include limitations on liability, D&O insurance, if you're an officer, parachutes, right?  Yeah. Oh, well, and I think about Bill, I think about the fact that I feel bad for some of the systems that I know because our hands are point blank tight. They'll go to the CIO and they say, look, dude, we're, I can think of a big retailer than I know. And he went to the CIO and said, we're at risk. The CIO said, yeah, we don't have to punch it. Yeah. Well, yeah. I think that's literally the crux of the Solar Wind's case against Tim Brown said, you know, he was saying, we don't have the resources to, to, to do what we say we do. And they went ahead and did things and didn't fund it and then put out statements to the SEC and put statements on their website about the efficacy of their security program.  Like, I think he was head of security or he was director or something at the time, like, does he go to the press? Maybe? You know, and one of the recommendations I said this morning was that I think every CISO should have a year salary banked so that way you can walk away when that situation happens because every, I didn't get every CISO will sooner or later find themselves in that I don't agree with it and I'm being told to shut up and move forward with it. And at what point do you just go, no, we're at crossroads. I'm not crossing that line because to me may not be a, you know, there may be a legal gray area, but do you want to be in a legal gray area when the SEC comes back or the FBI come back or any of those? Well, and I think that also, you know, it puts a huge onus on people in those roles to come from a place of paranoia, you know, and to document everything. And you know what I'm saying? I mean, because because that the potential for liability is great.  And, you know, I mean, I think that when you say something like have a year salary banked, I would guess that you say that realizing that for most of us, that's not something that's all that easy to do, right? So it's way easy for us to say it's not not sorry about that. It's not that easy for us to do. And so, you know, therein lies the rub, you know, one of the things that Joe and I have talked about in prior episodes was another challenge is, you know, you mentioned now I feel like I've got a seat at the table. Well, that's great. But part of what we're seeing happen is or the reality of this landscape is that, you know, few boards are comprised of people who have any kind of security experience or who former CSOs or anything else. So they're in a position where they're making decisions about this company and about keeping us safe without really having any, you know, it's kind of like, I think of it a little bit sometimes when you look at the congressional hearings when they're talking about, you know, TikTok or social media or whatever. And some of these guys and women have no idea, you know, what's happening really in the technology sector. So it's, it really is a very interesting challenge. And quite honestly, I mean, how CSOs sleep at night, I am not sure. It's a really hard job. It really is. And I feel for my colleagues, because the more this goes on, the more I'm seeing it almost divide in that summer, just like I'm done, I'm getting out. I don't report up. I'm going to ditch the chief title. I'm just going to be head of security and report to the CIO. And the CIO could be on the hook again. That is one, honestly, that's, yeah, that's a, that's a very viable option. I think the others are simply going, no, we're fighting to change the reporting structure and get myself in there. I'm going to take the responsibility. And I'm going to demand the authority that goes with it. The two need to be, they need to coexist in every situation. So it's, yeah, it's, it's, it's an interesting one. It's an ever evolving. And I think when you look at what the SEC did, when they left off, the one requirement that everybody thought was coming with the new regulations for disclosure four days after material breach, that there would be a certified security personnel on the board, independent, just like serving doctor when they had to have independent financial on the board, that they would put a security person and they left that one off. And I don't know why they did it. Like I can make guesses at why they did it. Personally, it seems like they're setting it up for somebody to fail horribly. Like that's the only thing it makes no sense. There aren't a lot of CISOs out there. Like there aren't enough to fill all the roles, I think. And maybe that, they were worried that would be a problem. But to put the control in place that said, you have to define a material, disclose a material security breach within four days of determining that it's material. So they gave them wiggle room in that. And he's been six months deciding if it's material, you watch that will. Oh, I need to see what the next revenue is to see. But again, it's coming down to a board that has zero cybersecurity expertise on it, making that decision. Yeah, it's scary. And they wonder why, what is it? They'll keep me honest. Two years is the average life of two years. Yeah. Well, that is not surprising in any way. So as we wrap the show, I'm going to ask you, Bill, to give us one piece of advice that you will leave our audience with as they work to get their arms around AI security and the challenges that that presents. What's your best advice? Oh, so best advice I can give somebody on getting their arms wrapped around this is don't sweat the small stuff. There's everything's going to break in life. Everything's going to go this always thing. But you've got to find your true north where where you're headed. And the way to do that is to immerse yourself in the business side. If you understand your business, um, you're able to speak to the executive team at a business level.  Vulnerability is not coming out of your mouth. Patching is not good. That stuff's all gone. If you're able to talk to them about your business and stay on your true north with that business talk, you will gain a lot of respect and a lot of understanding that will help you make headway into it. But you can't sweat the small stuff. Lots of things are going to fall by the wayside. They're going to fail. Um, you've got to keep your true north moving because otherwise you will be, you know, like a hamster on cocaine, you'll just be all over the place trying to do all sorts of stuff that really has no meeting in the end because we're all in business to make, well, I shouldn't say to make money, but most businesses are in business to make money. Others have some altruistic right, but there's always one goal for the business. And if you know what that goal is and how they achieve it, you can help them achieve it by reducing their and mitigating their risk to that business. And that's what our job is. That's what our job is. Well, perfect advice and a great place to wrap our show. Bill Harbor, thank you so much for joining us today. And Joe, thank you for hanging out again. And it's always a pleasure to start my week with you and with our brilliant guests. So Bill, we will definitely be revisiting this conversation because you shared some terrific information and we really appreciate it.


You saw some of our special effects. Today, we're going back to Mark Twain on the Chamber Street Theater. And of course, Mark Twain is wonderful. There's no question of it. And it's a delight to read his work. Today, we're going to be reading Mark Twain, The Pony Express. Now, Mark Twain has a tendency to jump around a little bit, so I'll try to help you and make it clear what we're jumping around to. And then, of course, we're going to follow it up with my own story about the Pony Express from The Weight of Gold. That's my book. And it's, I've got a Pony Express story too, but it's with the widow chambers. So we have a male's perspective, and then we have the female perspective. So it should be, what, a male-female show? Okay, we have lots of special effects. And we want to thank our people in the control room. It's just the three of us, you know. Alex Silver-Satter and Bryce Parker. And they've worked very hard to make this as interesting as possible. So we're going to give it a go. Now, The Pony Express, during the time of The Pony Express, the people did not know they were going to be part of history. So the records aren't very good. And you'll hear a little bit of, one thing is one way, and in another place it's another way. And you just have to sort of roll with that, because whoever is speaking is speaking the truth for that particular place. And it could be the scenery or the activity in the area. But things will be different from one station to another. And that's why some of the records are different. Well, let's start off with Mark Twain. We're going to be reading from Roughing It. This is a wonderful book. It comes out in paperback. A lot of people think Huckleberry Finn is his best book. I love Huckleberry Finn. Huckleberry Finn is great. There's no question. But my favorite Mark Twain book is Roughing It. And it is available in paperback. So it's not as expensive. OK, we're going to start off here in Chapter 8. In a little while, all interest was taken up with stretching our necks and watching for the pony rider. The fleet messenger who sped across the continent from St. Joe to Sacramento, carrying letters, 1900 miles in eight days. Think of that for perishable horse and human flesh and blood to do. The pony rider was usually a little bit of a man, brim full of spirit and endurance, no matter what the time of day or night his watch came on, and no matter whether it was winter or summer, raining, snowing, hailing or sleeting, or whether his beat was a level straight road or a crazy trail over mountain crags and precipices. Or whether it led through peaceful regions or regions that swarmed with hostile Indians, he must be always ready to leap in the saddle and be off like the wind. There was no idling time for a pony rider on duty. He rode 50 miles without stopping by daylight, moonlight, starlight, or through the blackness of darkness, just as it happened. He rode a splendid horse that was born for a racer and fed and lodged like a gentleman. Kept him at his utmost speed for 10 miles, and then as he came crashing up to the station where stood two men holding fast a fresh, impatient steed, the transfer of rider and mailbag was made in the twinkling of an eye, and a wave flew the eager pair and were out of sight before the spectator could hardly get the ghost of a look. Both rider and horse went flying light. The rider's dress was thin and fitted close. He wore a roundabout and a skull cap and tucked his pantaloons into his boot tops like a race rider. He carried no arms. He carried nothing that was not absolutely necessary, for even the postage on his literary freight was worth $5 a letter. He got but little frivolous correspondence to carry. His bag had business letters in it mostly. His horse was stripped of all unnecessary weight too. He wore a little wafer of a racing saddle and no visible blanket. He wore light shoes or none at all. The little flat mail pocket strapped under the rider's thighs would each hold about the buck of a child's primer. They held many and many an important business chapter and newspaper letter, but these were written on paper as airy and thin as gold leaf. The stagecoach traveled about 100 to 125 miles a day. That's the stagecoach, 24 hours. The pony rider about 250. There were about 80 pony riders in the saddle all the time, night and day, stretching in a long scattering possession from Missouri to California, 40 flying eastward and 40 towards the west. And among them, making 400 gallant horses, stirring livelihood and see a deal of scenery every single day of the year. We had had a consuming desire from the beginning to see a pony rider, but somehow or other, all that passed us and all that met us managed to streak by in the night. And so we heard only a wheeze and a hail and the swift phantom of the desert was gone before we could get our heads out of the window. And I've got two pages stuck together. But now we were expecting one along any moment and would see him in broad daylight presently. The driver exclaimed, here he comes. Every neck is stretched further and every eye strained wider. Away across the endless dead level of the prairie, a black speck appears against the sky and it is plain that it moves. Well, I should think so. In a second or two, it becomes a horse and rider, rising and falling, rising and falling, sweeping towards us nearer and nearer, growing more and more distinct, more and more sharply defined. Nearer and nearer and the flutter of the hoofs come faintly to the ear. Another instant, a whoop and a hurrah from our upper deck, a wave of the rider's hand and no reply and man and horse burst past our excited faces and go wingin' away like a belated fragment of a storm. So sudden is it all and so like a flash of unreal fantasy that but for the flake of white foam left quivering and perishing on a male sack after the vision has flashed by and disappeared, we might have doubted whether we had seen any actual horse and man at all, maybe. And now we get back to the stage. We rattled through Scott's bluff's pass by and by. It was along here somewhere that we first came across genuine and unmistakable alkali water in the road and we cordially hailed it as a first-class curiosity and a thing to be mentioned with a lawn in letters to the ignorant at home. This water gave the road a soapy appearance and in many places the ground looked and as if it had been whitewashed. I think the strange alkali water excited us as much as any wonder we had come upon yet and I know we felt very complacent and conceited and better satisfied with life after we had added it to our list of things which we had seen and some other people had not. In a small way we were the same sort of simpletons as those who climb unnecessarily the perilous peaks of Mont Blanc and the Matterhorn and derive no pleasure from it except that the reflection that it isn't a common experience. We crossed the sand hills near the scene of the Indian robbery and massacre of 1856 wherein the driver and conductor perished and all the passengers but one it was supposed but this must have been a mistake for at different times afterwards on the Pacific Coast I was personally acquainted with 133 or 4 people who were wounded during that massacre and barely escaped with their lives. There was no doubt of the truth of it as I heard it from their own lips. One of these parties told me that he kept coming across arrowheads in his system for nearly seven years after the massacre and another of them told me that he was struck so literally full of arrows that after the Indians was gone he could rise up and examine himself and he could not restrain his tears for his clothes were completely ruined. The most trustworthy tradition of ours however that only one man a person named Babbit survived the massacre and that he was desperately wounded. He dragged himself on his hand and knee for one leg was broken to a station several miles away. He did it during portions of two nights lying concealed one day and part of another and for more than 40 hours he suffered unimaginable anguish from hunger, thirst and bodily pain. The Indians robbed the coach of everything it contained including quite an amount of treasure. About two hours and a half before we arrived at La Porelle station the keeper in charge of it had fired four times at an Indian but he said with an injured air that the Indian had skipped around so to spile everything and ammunition so blame scurse too. The most natural inference conveyed by his manner of speaking was that in skipping around the Indian had taken unfair advantage. The coach we were in had a neat hole through the front reminiscent of its last trip through this region. The bullet that made it wounded the driver slightly but he did not mind it much. He said the place to keep a man huffy was down on the southern overland among the Apaches before the company moved the stage line up on the northern road. He said the Apaches used to annoy him all the time down there and that he came as near as anything to starve into death in the midst of abundance because they kept him so leaky with bullet holes that he couldn't hold his vitals. This person's statements were not generally believed. The tiresome minutes and decades of minutes dragged away until at last our tents forms filled over with adult consciousness and we slept. For it was a sleep set with a hair trigger. It was a sleep seething and teeming with a weird and distressed confusion of shreds and faggants of dreams, a sleep that was a chaos. Presently dreams and sleep and the sullen hush of the night were startled by a ringing report and cloven by such a long wild agonize and shriek. Then we heard 10 steps from the stage. Help! Help! Help! It was our driver's voice. Kill him!  I'm being murdered! Will no man give me a pistol? Look out! Head him off! Head him off! Two pistol shots, a confusion of voices and the trample of many feet as if a crowd were closing and surging together around some object. Several heavy doll blows as with a club a voice that said appealingly, Don't, gentlemen! Please don't! I'm a dead man! Then a fainter groan and another blow and a way sped the stage into the darkness and left the grisly mystery behind us. What a startle it was. Eight seconds would amply cover the time it occupied. Maybe even five it would cover. We only had time to plunge out a curtain and unbuckle and unbutton part of it in an awkward and hindering flurry when our whip crept sharply overhead and we went rumbling and tumbling away down a mountain grade. We fed on the mystery the rest of the night what was left of it, for it was waning fast. It had to remain a present mystery for all we could get from the conductor and answer to our hails was something that sounded through the clatter of wheels like, Tell ya in the mornin'! So we lit our pipes and opened the corner of a curtain for a chimney and lay there in the dark. Listening to each other's story of how he first felt and how many thousand Indians he first thought and hurled themselves upon us and what his remembrance of the subsequent sounds was and the order of their occurrence. And we theorized, too, but there was never a theory that would account for our driver's voice being out there nor yet account for his Indian murderers talking such good English if they were Indians. So we chatted and smoked the rest of the night comfortably away, our boating anxiety being somewhat marvelously dissipated by the real presence of something anxious about. We never did get much satisfaction about that dark occurrence. All that we could make out of the odds and ends of information we gathered in the morning was that the disturbance occurred at a station and that we changed drivers there and that the driver that got off there had been talking roughly about some of the outlaws that infested the region. For there wasn't a man around there but had a price on his head and didn't dare show himself in the settlements, the conductor said. He had talked roughly about these characters and ought to have drove up there with his pistol cocked and ready on the seat alongside of him and begun business himself because any softie would know they'd be laying for him. That was all we could gather and we could see that neither the conductor nor the driver was much concerned about the matter. And that ends the Mark Twain story of the Pony Express and a stagecoach ride and I think we should add that by the way the Apaches never broke any agreement they had with the White Settlers. It was the White Settlers who broke the agreements and so the massacre that they refer to as the massacre done by the Indians was in retaliation for something the White Settlers did. And by the way White Settlers or anybody around there could get cash money for bringing in the scalp of an Apache whether it was an adult male a woman or a child. And now we're going to read my story about the Pony Express from The Weight of Gold. Oh, I got a little out of control about living history and recreating the time period and I wound up writing a book. And here's the chapter on the Pony Express and the person telling the story is the widow Chambers who's out here in Sacramento City earning her living by selling fruit pies on the street. April 13, 1860 was the day the Pony Express came to town and we were all so excited. The streets were lined with people waiting for William Hamilton the first rider between St. Joseph, Missouri and Sacramento, California. Now that doesn't mean Will rode the whole 1840 miles. He rode the last few stations worth and that was rough enough. As I stood there I thought back to before and how I took a letter down to the Sacramento River and to a ship's captain. I'd asked the captain to take my letter to Nantucket with him on his trip. I figured four to six months time would make the voyage from here down the South American coast and up the other side and on to Nantucket. Captain Dodd told me it would take a long time and I said I knew it would so he took my letter and I felt good that my letter was on its way. I thanked the captain and gave him a freshly baked fruit pie for his dinner dessert. I thanked him again and started to cry. It sounds silly to say it but I did. Family and friends being so far away. I was standing on a ship that would soon set sail again on a terrible and wonderful adventure. The truth was the ship may not even make it round the horn of South America. My letter could sink to the seas floor with saltwater washing away my words with the current. Enough of this and all the awful things that can happen. My letter is off to sea with Captain Dodd. All this was going through my head as we heard the first shouts greeting the rider Hamilton. There were celebrating riders coming in ahead of Hamilton and leading him in in truth poor tired Hamilton and his poor tired horse couldn't keep up with the celebrants and was eaten dust all the last mile. Here he is now. It took the Pony Express 10 days to make the trip from St. Joseph, Missouri to Sacramento. Later I learned it took my letter two years to get to the East Coast. Captain Dodd had gone to the Sandwich Islands later called the Hawaiian Islands and many other places before returning to the East Coast. Also he had many misfortunes. Ships don't carry people one way and go home empty. They load up with whatever can be sold and return home full. I didn't think about this but I knew it was true. It must have been wishful thinking to believe my letter was just months away from the East Coast. When the Pony Express first set up business in the BF Hastings Building on 1000 Second Street they put an ad in the papers. They wanted orphaned young men slight of frame. The pay was $100 a month. On the more dangerous runs the pay hit $150. The youngest rider was 14. Most were around 18. They didn't need a gun. They could outrun any Indian or bandit. Pony Express riders had the best horses and were fed best and cared for best. Weight was everything so these skinny young men often didn't wear their boots on the ride. Boots could be heavy. So off they came. Well here was William Hamilton just a handsome as a handsome as a rider should be and there was the first male just 10 days out of Missouri. We were clapping and shouting. The male was here. The Mochella was taken off the saddle and the horse led away but William had just gained a city's worth of new friends patting him on the back and leading him to the nearest saloon for a refreshing bed beverage. There still weren't a lot of women in Sacramento but the few of us were cheering. One 72 year old woman cried out I love you Mary. Let's make this clear. It wasn't me. I wasn't that old then. Of course that day I love the handsome rider too and I probably would have married him as well but that romantic 72 year old was ahead of me. And now I'd like to tell you what a Mochella is in case you don't already know. There's the horse and there's a saddle and then on top of the saddle is a Mochella. It's not tied to the saddle. The Mochella is basically a rectangle of leather with pockets in it for I think we're showing a Mochella now. There it is and you see the pockets and you can see the horn of the saddle and the back of the saddle sticking through the Mochella. The Mochella has the hole so it slips over the real saddle. So when the rider comes to a station he gets off the horse pulling the Mochella with him that's not tied down and he throws it over the next horse and over the saddle that's already on the next horse jumps on top and off he goes. So that's the Mochella. I'm glad we have a picture of that. Well, that's our show for today. If you have any questions be sure and let us know. We'd be glad to answer them. We've got Alex Silver-Satter in the control room and Bryce Parker and me. I'm Ruth Chambers. I'm the reader of all the stories and the author of some of them but not all of them. Mark Twain of course is a really fine rider and we read a lot of Mark Twain because he's a fine rider and that's our show for today and we'll see you next week. Bye bye now.