two foot jumps. You need a safe space to practice two foot jumps. Bend your knees, lower your hips and bring your arms back. Swing your arms forward and push from your feet to jump. Land on two feet and bend your knees to become stable. Now you need to go and practice so you can get ready for the challenge.


to boot up here. Look, it's booted up. Yeah, that's the ticket right there. Okay. Okay, when you have the toys and you have nothing better to do but fly on the airplane, deal with a lot of slow damn animation. Alright, this is going to be an introduction to computer viruses. I'm actually just going to ask this question up in New York, so I'm going to ask it here. By show of hands, how many people here have actually written computer viruses? Okay. Now, how many federal officers in the audience are actually keeping track of how many people wrote computer viruses? Okay, now how many hackers are keeping track of the federal officers? Alright. Hey, look, I can press the button again. Okay, this is the introduction to computer viruses. How many people made my talk last year on viruses? You don't count because you're my friend, but hey, thank you. Alright. This is actually the updated version with animation and some new information.  Alright. The things we're going to cover in this talk are boot sensor viruses, multi-par ties, file infectors, macro viruses, Trojan horses, fakes, and visual basic scripts. Why am I dealing with visual basic scripts? Well, it's obvious. How many people got hit by I Love You? Alright, now how many people aren't raising their hand because they're embarrassed that they got hit by I Love You? Okay. The I Love You virus when it hit actually was quite devastating. It did quite a bit of damage. Well, not damage per se. It just had a nice tendency of changing all your music files and your porn. Poor guys out there just lost like five gigs of JPEGs. It was like, oh damn, oh my god, I lost a whole redhead section. Jesus. Back to the news groups, down low, down low, down low. Yeah, it was pretty nasty. Not nearly as nasty as the variants that followed it the weeks later. But I'm ahead of myself. We'll get into that. Oh yeah, and computer viruses in the future.  That's how it was to it. At the end of this talk, when I talked about the computer viruses in the future, that's when I'm going to discuss what I discovered here by an individual. Steve in the audience? There you are. You're the man who told me the information. Okay, we're going to be talking a lot this year. You know that, right? Okay. I'll be introducing Steve here near the end of the talk here. Give me some troubling information and I'm going to be doing some serious research over the year. We're going to start with boot sector viruses. Boot sector viruses aren't seen as much as they used to be. Back in the days of DOS, boot sector viruses were extremely rampant. We're going to cover how they work, what to look for, ways to remove them and the animation. Really, boot sector viruses actually work. We have three parts of the boot sector. I've got my trusty laser pointer here. We actually have the code section here, the fat partition information, and the marker, which is 55AA. Now, what happens is the code sequence here on the boot sector, when the system works up, remember in the old DOS days, you don't see as much today as you did in the old DOS days where you type in the wrong command and it says syntax error or some type of error code or whatever. That was this right here, the code. That was telling the computer how to respond depending on what you typed in or depending on how things accessed memory, yadda, yadda, yadda. Okay? Make sense? Anybody lost? Good. Hi. The fat partition information kept track of all your directory structures. As you sat there and started going down the tree structure, it kept track of where the directories were placed on the hard drive. It kept all the memory allocations stuff up. Just everything, all your files, everything, it kept track of everything.  Think of it as a database. And this is the marker, which tells it where to start. Just probably push a button. You know, just this animation stuff, man. Hey, look, it's divided into three parts. Hi. On the record, PowerPoint just pisses me off. Hello. Okay. The virus first copies the boot code onto a different sector of the media. What happens is on the hard drive itself, on the boot sectors, you actually have multiple sectors. Several of these sectors are not used by other programs. They're actually set there and kept in reserve. And what the virus writers would do is they would have the virus copy the code sequence itself, just take that whole block. And they would copy that to, like, sector 7, 9, 12, 17, 22. These are common sectors that are not commonly used. So it was a safe area to go through this code because you need this code to boot up. Okay? Without this code, the system won't boot. Yeah, I know this part. Okay, like I said. At that point, it then copies its code, the new virus code, over this code. So this on the boot section portion is gone. This is now the virus code here. At the end of the virus code here, it actually points to the different sectors that it copied to. What some of these viruses would actually do is they would sit there and say, check sector 7 and see if there's any code there. If there is, copy over to sector 9. If there's code there, go to 12. Why would they do that? Can anybody give me a guess on why they would actually check for different sectors that these sectors weren't commonly used?  Didn't you go to school? Okay. Yes. Exactly. That means you can be mostly infected. What they would do is they would say, hey, there's already code in sector 7. Let's go to 9. Good rule of thumb here. If you're dealing with the boot sector virus and you boot from a clean floppy, because we would over spoof from a clean floppy and not trust an antivirus software that's infected, would we? I've actually come across machines where I've run a scan against them, found a boot sector virus, removed it and cleaned it successfully, and just for shits and giggles, ran it again and found another boot sector virus, and then again and found another one. I've been able to actually infect it four times with a single machine four times with four different boot sector viruses. The machine didn't run very well, by the way. I went for a different animation. The fat partition information of the NBR holds the data and partition information of the disk, which we covered earlier, remember? It has all your directory structure and your tree structure in there. Now, some viruses are particularly evil. Not just evil, but they're evil, right? What they'll actually do is they'll encrypt the fat and partition information. So the virus code would run and at the end of the virus code itself, it would actually de-encrypt the fat partition information and then run over to like sector seven or nine and actually run the boot sequence and then your system would boot up. So if you remove the virus incorrectly, the virus isn't there to decrypt the fat and partition information. So you go, I got rid of the virus and all of a sudden you're going, what do you mean you can't boot? You're going, oh, sure.  I'm saying that for his benefit. Because most of us would not have porn on our hard drives, right? We'll be back in a minute. Because you can't reinstall the virus because the drive doesn't exist as far as the operating system is concerned.  Monkey bee, anybody been infected with monkey bee? All right, repeat after me.  Yes, it is.  There's different ways of actually removing viruses without using antivirus software and the monkey won't let you do any of them. The monkey is just flat out evil, absolutely freaking evil. And I love it. It's just, I thought it was brilliant. What monkey does is it does that. It loads into the code, encurts the fat partition information, and it requires it to be removed. To remove it, it requires you to actually know the code key. What some of these antivirus software companies did, and I honestly was brilliant. It was a very great idea. What they did is they created something called a simulator. Anybody know what a simulator is? Good. Here, long hair. It doesn't work.  The number one rule for a virus is you must replicate. You have to replicate or you're useless, which is how you got the virus in the first place. So the first thing monkey would do is it says, right on, I'm going to replicate. It starts going through the de-encryption scheme to de-encrypt itself, because the code itself is encrypted also. Now what happens is the simulator would be watching the code go through the de-encryption scheme on the fat partition information. It would stop the process instantaneously, grab the de-encryption scheme, de-encrypt the virus, and remove it. Now I don't know about you, but that's impressive. That's brilliant. For a long time, McAfee, you would have the McAfee antivirus product.  I'm not really sure whether or not it's still that way, because I've only been infected with monkey once, and that was on purpose. We already covered that. Okay, we're going to go over some of the things to look for in case you think you're infected here. One of my favorite tools back in the old DOS days was Norton Utilities from Symantec. One of the reasons why I liked Norton Utilities, aside from that it had some really cool tools and people were like, hey, what's that? They had a thing called a disk editor. Anybody use it? All right. It worked. That disk editor was fantastic. It was a graphical description of your drive. I used a disk editor to go to the first boot sector, the NBR, and I would look at the code. And then I would use my right arrow key to start hitting the different sectors. And as you're going through the different sectors, those sectors should be blank, the code on the right hand, because you'll look at the box here, and then you'll have all those like hex code on the side here. And if you didn't see any code, then there was that thing on those sectors. Well, I'd go through the drive and I'd just start paging sector after sector after sector. And if I saw a copy of quote unquote code from the first sector, I knew I had a virus. The other thing to look for was changes in memory usage. If for some reason you were working away in the next thing you knew, your system is running really, really slow. And I know this is really hard to tell when you're dealing with Windows now. But for DOS, it was really obvious, you know? It's like, God, Windows is running real slow. And it's crushing a lot. Maybe I have a virus. No, you just have Windows. And the thing is, I really can't cap because I use Windows. And people are going, I'm going, hey, look, I use Windows, I use FreeBSD, I use Solaris and use Linux. Why? Because if you really, really want to know the ins and outs, you need to know all operating systems. Just a little paging. Besides PowerPoint, so the hex already leaked cool.  All right, look for strange behavior in the OS. I know, no jokes, we're dealing with Windows. The way I mean by strange behaviors in the OS, let's go back to the old DOS days. There was a boot sector virus that really only affected XTs and 286s, so you will never see it again, except for those of us who still have XTs and 286s in our lab because we're too damn cheap that don't need them or like using for boat anchors. This was a really cool virus. It was called the music boot virus, and it was really kind of cool. I loved it. When I worked for an antivirus company, I was testing all these different viruses, which was a blast. And I came across this one, and I was just dying to see what it did. You could not tell that you had the virus. You sit there and you'd be working on the system, typing commands, and then the whole system would just freeze, and then the PC speaker would go, do, do, do, do, do, do, do, do. And then everything would work again.  Okay, I'm up late. It's no big deal, and you'd be working around, and it was random, so it just wasn't happening on a regular basis. You could go like a day or two, and nothing was happening.  It was like, all right, it was no big deal. There was some glitch in the program. You'd be working on something else, trying to play some type of game freeze. Do, do, do, do, do, do, do, do, do, do, do. And you're going, okay, you know, something's wrong here.  You know, what is that with that? And you're going, now, I know the speaker is not supposed to do this.  It's Bethes. It's evil. You know, we're like, you don't mind. You touch it. Make me change the garbage. You know? And it was a pretty harmless little virus. After a while, it would actually just completely and utterly crash your system, and you'd have to reboot your system, which was annoying, but it really didn't do any damage. It was just cute. So that was my favorite back then. I just thought that was kind of fun. Just something to annoy the hell out of somebody. Does anybody remember the rapid virus on Macintosh? Yeah. I remember being at a company working on your Macintosh, and this little bunny goes jumping across your screen, and you're going, no, I didn't see that. And you think to yourself, no, no, no, no, no.  Okay, maybe I did see that.  You know? And it would actually go through the network and jump around through people's screens. It was pretty cool. But you know, hey, once again, it was, you know, Macintosh. All right. Different ways to actually remove boot sector viruses. One of the easiest commands to use for like New York boot or anti-EXE, well, anti-EXE is kind of like a different story because anti-EXE is a multi-part time virus that we'll actually get into that. But anything that has a solid boot sector virus that does not encrypt, all right, everybody repeat after me, does not encrypt. That was a cue. Come on. Does not encrypt. Right.  What fdisk slash mbr does, will anyone actually use this command? Well, you guys rock. You guys are awesome. All right. For those of you who never use this command, all it does is it says, I don't care what code is there. I don't care what it is. Just replace it with my new code. Okay, great. Game over. So the virus is there. You copy of the boot sector stuff is like another sector, and it says, I don't care about any of this. Boom. The virus is gone. Simple as that. You get up with a boot disk. Type in fdisk slash mbr. Virus gone. No problem. I mean, and it's gone. Be careful. Identify the virus first. I want to see what happened if I did it with monkey. I should have taken the data. I actually wanted off that drive first. Because I'm going, well, I picture I can still recover. I'm positive I can. And, well, you can. It was hard. Yeah. Would you be able to tell if it was encrypted based on whether or not you could access your code? Well, yes. Maybe. I don't know. I never tried it. I don't know. I don't know. I don't know. I don't know. I don't know. I never tried it. But now, damn it. I'm going to have to go try that. Yes. By theory, that would be true. Because if it's an encrypting factor, and you boot off of a clean floppy, you will not be able to see the hard drive. So, yes. Without testing, that's true. So, there's your test. Put it on a clean floppy. Try to access the C drive if you can get a directory structure. It's not encrypting. fdisk slash mbr. Woo! Get over. Man, I need more sleep. The other way to do this, if you actually want to take some time to do it, and you want to be like hax or elite kind of, you know, uberdude, and you don't feel like you want to type in fdisk slash mbr, all you have to do is find this sector that has your old code with a disk editor, copy and paste it back over the original code. So, yes. So, yes. So, yes. So, yes. So, yes. So, yes. But the original code, and that would do it also. fdisk slash mbr is a lot easier but that's the elite, slow life of time on my hands and my wife's out of town, and a way to do it. And of course, antivirus software. Honestly, antivirus software is your best friend. The viruses that we have today are a lot more destructive. A lot more plentiful, and I have a lot easier to spread than they used to be. Back in the days, I'm going to date myself here, a sneaker net. How many people here know a sneaker net? You old farts.  The kid. We have a small kid in our line. I don't know what a sneaker net is. I don't know around since I'm God. It depends on who you think God is. In the old days of sneaker net, basically to transfer files, copy to a diskette, pull out of the drive, walk over to your buddy and go, here's the file.  Boot sector viruses were amazing for this because the way you can infect a diskette with a boot sector virus... I just had to, I'm sorry. It's my talk, I can do whatever I want. Back then, boot sector viruses were the most prevalent viruses there were. 80% of the virus infections were boot sector viruses. This is not true today, but back then it was. Because all you have to do is do a directory on a diskette and you infect it. If the diskette is infected, all you have to do is say, A colon, hit return, so as it access the disk, your drive is infected. And the way you can actually tell a diskette was being infected, that's great. If you put a diskette in a drive now and you say, directory A colon, and it goes, and it gives you your directory.  It's actually grinding down in there. It didn't make that noise a few minutes ago. That's another clue, people, if you do a directory on a diskette, and it starts grinding and it gives you this horrible grinding sound. Oops. One thing I'd like to add here real quick, some of the questions that we can to the very end, so I don't get too far over time here, but all your questions have been absolutely fantastic, especially yours, that was a really good question. Start focusing on your anti-virus software. I would say the majority of people install anti-virus software on their systems, and they never update the DAP files. Seriously. How many people here, and don't be embarrassed, I really want to see any people here who have actually had anti-virus software on their systems and did not update them in a week? How many people in over two weeks? Three a month, six months, a year, several years, never done it. You know what? You're the majority out there. You're the majority. Those people, once they install it, they think they're safe, this is called security. You're not. I didn't go to the event. I felt like I'm working on my own system. I actually got infected by the Michelangelo virus and I was so embarrassed.  And I had a test machine, I had not updated it, that system, and well over a year.  And I was like, oh, these demos are old. They sure were. And so I actually tracked down the disc gate and cleaned the disc gate myself, but, you know, it happens. It happens. Right now, my system is set up to update my DAT files daily. Not a joke. I update my DAT files daily. And then I look at, like, virus bolting, and I look for problems with malicious code up in the wild, and I look for updating. There's a lot of really good talks going on, because I have money. There's a lot of really good anti-virus products out there. There's a lot of really crappy ones out there. I would recommend that you guys go to a thing called the virus bolting. It's actually a publication in the UK. It's brilliant. It's absolutely fantastic. It's expensive for subscription, but it's worth it. I get them monthly, and I just read them cover to cover. It gives you all kinds of information. And they also do product evaluations and they're neutral.  So keep up on it, guys. Keep up on it, because it's important. I actually use two different anti-virus products right now on my system. And I had to do the H2K two weeks ago. I'm going to tell you right now. I do not receive any money or any publications. I don't even get damn t-shirts from any anti-virus company out there today. Flat out. My opinions are my own. I have no endorsements. Presently, I'm using F-prod on my system, and I'm using Fingin Safe Surfing Shield on my system. I'll tell you why. This little other anti-virus product out there right now uses one scanning engine with their DAF files. F-prod uses three different scanning engines with their DAF files. It gives you that much more of a chance to find malicious code. Makes sense. I've had problems with F-prod in the past. I still have problems every once in a while. There's some flaky issues, but all in all, it's worth it. The reason why I like Fingin is that Fingin is actually not an anti-virus product. It's an anti-malicious code product that works in conjunction with your anti-virus product. You don't use it instead. You use it with. It works with anything. What it does is it takes anything that you bring in from an email, some type of executable code, and runs it in its own little DMZ sandbox on the computer. And if it sees malicious code, it stops it in its tracks. It was the Fingin software that was actually stopping it from spreading out a lot of companies. Everything else it went streaming through. So, double up and protect it. Can we hold the questions? Thanks. Fingin, F-I-N-J-A-N. Once again, no endorsements. I just happen to like them. Next year, I'll probably like somebody else. Yes. The first year will not work in that. It may fool by your whole system depending on the virus. Okay, let's move on. We're going to go over the different types of bootsector viruses. A lot of the old school people just came up with some really intense ideas. We have self-viruses, polymorphic viruses, encrypting viruses, and any combination of these. I got really messed with the animation. I'm sorry. Self-viruses hide in the upper memory block. And even with anti-virus software running, if you put the anti-virus software in there with the virus activated in memory, it won't see it because it hides. It hides itself specifically from the antivirus systems. You have to have an emergency boot disk with you that you please, people, right-protect this disk. Okay? How many people have an emergency boot disk for their systems? How many people can actually remember whether they right-protected it or not? Okay. That's good. I'm proud of you. I may be wrong.  What do I do? I was like, well, drop back six yards in front. I don't know. Self-viruses. Pretty cool stuff. Polymorphic bootsector viruses. All right. What polymorphic viruses do, and the reason why they were really cool, is each time they replicate themselves, they change the code. Yes. Now, by changing the code each time, it's not quite the same signature. The way the antivirus products work is they look for a specific signature. They don't see this signature. They don't think there's a virus. So if you have polymorphic viruses that are changing their code each time, this company is going, damn, I can't find this thing. And it makes it really, really difficult. The nasty ones are when you get the polymorphic-encrypting-selfing viruses. And there's a lot of them. Or the multiparty- polymorphic-selfing-encrypting-viruses. And by then it's better just to a little top out the window and buy something new and just say, oh, this. Or go to Munich. All right. Actually, who can tell me why there's not a whole bunch of unix viruses out there? That's right. You don't have super-user privileges. There's also another reason. Anybody? Sort of the answer I'm looking for is although everything is a file, everything is inherently executable. Right? If it's not executable, you can't spread. You can't activate it. Um, can anybody tell me right now, and this is a single question, and I'll answer it if the first person doesn't get it right, why is it that there's more viruses today for windows than any other operating system? And don't make a joke. Give me a real answer. Popularity. Popularity. You're 100% correct. Windows is the dominant operating system in the world. Which is, if you're thinking about the first rule of computer viruses, you need to replicate. Why would you write a virus for macintoshes if you wanted to replicate it? You need to write it for the most popular operating system in the world, which is Windows. Windows 95, Windows 98. I'm sure I think Windows 95 is still the most popular operating system in the world. If Linux tomorrow became the most popular operating system in the world, you would see viruses for it. And, actually, there are viruses out there. And, there will probably be more. Alright, encrypting viruses will encrypt data, or themselves, or both, making it more difficult to remove. They may also make it impossible to re-travel your data if you remove them incorrectly. As we mentioned before, the monkey was such a virus. We removed the file-infectors here. Like in my artwork. My wife's the artist. I'm the computer geek. And, she looks at the end and goes, I could do better. I was like, you know you could do better.  Would you just go, yes, it looked really cute Oh, damn, it went back. Okay, I thought I had more. The way it works is, this is the actual file itself.  What the virus will do is, I'll put a cap around the front, and a cap around the end. So what it does is, the very beginning of the of the file, this code now states, go over here to the very end of the actual file and run the virus code. And the end of the virus code then points to the beginning of the actual file during the actual file that you needed to do loading the virus into memory. The easiest way to identify that is, I used to have a script that I ran on my systems weekly that actually did a binary compare to my backups to the actual files that were relevant, executables, com files, so forth. And it found some files that were larger, that were executable than they were last week, that's a good indication. Can we can tell me the maximum size for a com file? What? 64K. What happens if you see a com file that's 1024? You have a problem. So start looking at these files and looking at the numbers. If you're sort of seeing, there were some actual viruses out there that would, each time you ran it, would actually increase the size of the file. And the purpose of this was to fill up your hard drives, and the next thing you knew was, kind of, I only have three programs and my whole hard drive is completely filled. These were back when there was like 10 and 20 gig, or not 10 and 20, 10 and 20 meg files, you know, hard drives out there. When people said, hey, I have a 100 meg hard drive and people were like, whoa, how much did that cost you? $2,000. What a deal! Can you get another one? Yeah, it's true, it happened. And what these files would do is each time you ran, you know, executable things, each time you boot up, it would actually start adding to the size of all your executable files, not just the files, but all of the files. So you sort of ended up as like, okay, now I've got a com file that's like 10 megs, you know, what's up with this, you know?  The size stays the same. Your antivirus offer didn't shrink your file back to normal. It just deactivated the code sequence, so it just ran the file normally, and all those extra code was left in the front in the end. So you still ended up with these huge files, and that was bad. Multi-partite viruses will infect both the boot sector and the files.  So if you got a file via email and you activated it, it infected all your executables, all your other type of files, plus it infected your boot sector. And then if you got a disk from somebody, and that was infected, it did the same thing and infected the boot sector and all the files. These guys were pretty nasty. That is really an annoying animation. Just thumb me on the head after the thing. The problem increases the spreading capabilities of the virus by disk, email, or any other way to move media. The multi-partite viruses are still the most popular. The anti-EXE and the anti-CMOS are two such files, or two such viruses. Anybody ever get hit with anti-CMOS or anti-EXE? Either one. Yes. Including myself. I got hit with anti-EXE. Those two are some of the most popular ones out there, and they're still alive today. Those are particularly nasty. I happen to know of a single virus that's out there that was a type of anti-CMOS virus. I never saw it in the wild. I've only seen it actually running, and I actually don't know if it exists in the wild, and I didn't even know what the hell I named it. But someone gave me a demonstration of it, and I think he was the one who wrote it, or got it from this buddy who wrote it. And what it did is it not only did it screw up your CMOS, but it changed the admin passwords on your CMOS. So you couldn't even get into your CMOS to fix it. And I was like, oh, that's evil. Can I have a copy? No. Whatever. Wonderful research, really. Sorry, it was just proprietary.  We need this proprietary. You got a copyright on this shit? You want to go to these guys and go, so tell me, what do paint chips taste like? It's like, whatever. That's game script kiddies. How many people have actually been hit by macroviruses? I see a lot of the same hands going, yeah, me again.  I have nothing but a huge busting PC of viruses, you know. What? On the corporate network? Are you responsible for the antivirus? And you're so employed. So you're actually not getting infected, you're just getting hit with them coming in. Okay, so you're doing your job. All right, I apologize. Good for you. You rock, man. I was saying, if you're in, you're getting hit with all these and go on. And you still work? What are you? Dad owns the company? Mess with the secretary? What's up here? You mean the president's wife? We're like this. Actually, we're like this on the one over here. Actually, you bought up a really good point. When I worked at the antivirus company, and I can't really mention who it was, and although I slipped last year and mentioned it, so anyone who was here last year actually knows. When I worked there, we would get on the average of 200 to 300 brand new viruses never before seen in the wild each month. These are not wild viruses. These are brand new, never seen, have to write debt files for. That number's increased to about 500 to 600 now. All right, the way macro viruses work is someone with a brand idea, hey, let's make life easy for all of our end users and give them programming capabilities in their Excel and Word spreadsheets and stuff like that. And we let them make everything easy. They just press one button and they'll do all this neat stuff for them, for all the lazy people. And then the virus writer stepped in and said, hey, that's a good idea. And he started looking at it and went, but we'll make it really easy. We'll use the numer.dot file. And everything will be kind of the starting place. They'll be like the MBR of your Excel spreadsheets. And the virus writers went, hey, that's a good idea. And they started using that against the problem is. Your numer.dot file is your startup. When you create a default Excel spreadsheet, it's the numer.dot file that gets run through first, looking for anything that it needs to do. So a lot of these macro viruses would just change the numer.dot file or replace it and add their own code. We were doing what it normally would do, but there's a little extra stuff there. Really popular one, actually, when the first one came out was the rainbow virus. Anybody get hit with the rainbow macro? Nobody? That was kind of cool. You know Windows, you know how you have your color scheme on Windows, where your borders are one color and the buttons are another color and the frames are another color and some flaming guy with a hard on for colors colors everywhere. Rainbow would do things like let's just make everything white. Let's make everything black or red or blue. Let's just make it, let's say with one color. You run the what and your text is like it's actually pretty funny. But it wouldn't just do like one color, sometimes they would just start randomly changing all the different colors.  Damn! Cheese!   Why the colors were there in the first place? I have no idea because nobody who's not on crack would ever use them. Alright, Trojan Horses. These are programs that are put onto the system by someone or you are tricked into activating them yourself. Most often these are backdoor programs like that. Yeah. Okay. Now, when I was at H2K and I was going to do this talk, a lot of people said they wanted because I hang out with a lot of people at CDC. Do we have anybody from CDC here? Anybody? An associate member is better? Okay. CDC guys, I hang out with them every once in a while and drinking beer. Just don't tell my wife. And people said that they were like, you know, which are feelings on the CDC? And I understand you think I think they rock. I think they're brilliant, Dill Dog, Deaf Veggie, Pond, you know, Kingpin, these guys. They're brilliant programmers. Do I consider them a product of virus? No, I don't. It can be used as a Trojan Horses, yes. But what they're doing is they're trying to progress people to like secure their systems and trying to get the people who like the operating systems to, you know, make a change, you know, and make a difference. The biggest argument is like, all right, what's the difference between SMS and BOTK? One's free, one costs a couple thousand dollars. So, I have absolutely nothing against them. As a matter of fact, I think they're fantastic people. An instrument. Bakes and false alarms. That was the slowest of these animations I can have on this whole screen. Yeah. Yeah, that was pretty bad too. All right, the fake and false alarms, they're spread by email. That's the biggest one. Now, the email itself becomes the virus. How do you tell whether or not the warning you're getting is a fake or false alarm? Any arguments? I didn't think so. Read this. Next line. It's important. This is amazing. First of all, I'd like to point out Microsoft does not send out virus warnings. This just came back from Microsoft. There's a horrible virus that's out there. No. And read this in huge caps followed by this. That's using my first name. Okay, click. But the problem here is All right.  Oh my God, it's a new virus. I better send everybody on my list this whole virus information. They got to know about it. And you'll send them. I know some of you guys have sent these to your sister admins. I know you have. You know how I know people are like I know you have. Because I've read them. I get them. And it's like No, it's not a virus. No, it's not a virus. And send this to everyone you know. So I like to send to Bill Gates. And Hey, this came from your company. Is it true? I don't get a reply. One question. I didn't catch a single word. I'm so sorry. I'm trying. I think I know what you're saying is you can actually go to different places and find the hoaxes. And that's actually what I was going to point out. Because I read the hoaxes. Oh, I know what he's talking about. Yeah, if you're worried about whether or not a fake or false alarm, whether it's a fake or a false alarm. Honestly, go to the antivirus companies and they have spots there on viruses in the wild and the known fakes and false alarms out there. And virus bulletin over in the UK is also a great source for that too. So before you start spreading these out to everybody, go check there. Oh, God. Okay. You have to die. All right. Yeah, but the problem is I'm probably going to make a bumper sticker on them and put them back in my car. Okay. Yes. Uh-uh. I asked Mom and she said, damn, that was right. Did anyone actually get the joke? Yes. Okay. Actually, yes, you're correct. And I have to be corrected by a kid. How old are you? 11. I get corrected by a 11-year-old kid. I'm camera. With the person in the audience. Okay. No, you're right. That is not the correct definition of damn. I actually did it as a joke. All right. The problem we have with visual basic scripts and this is the code of virus preferences right now because anybody can write these. They're really, really simple.  I talk about computer viruses but never once do I ever tell you guys to go out and write them. There's a reason for that. My personal opinions are and these are just my personal opinions writing malicious code that can actually go out there and ruin people's lives is not funny. It doesn't make you elite. It doesn't make you awesome. And you don't impress anybody but your close friends are in your only little tight circles where nothing but script kiddies anyhow. No one has to write under any circumstances. I don't care who you are. I don't care if you're the government, the guy next door, a gang banger, a script key. You don't have the right to ruin a person's lives under any circumstances. And that's why I stand on that.  Oh, damn, you got heavy. That's true. That's true. There was a difference between a virus writer and a guy who spray paints his name on the wall.  It was making sense to me. And for the record, no, I have never written a computer virus. I can. I have chosen not to. The overview virus when that came out was actually devastating. The problem I have was the press was going, this genius kid wrote this amazing virus and they're going No, the kid was not a genius. He was smart enough to write the virus. Says my mom. And says the maid at the company I work in, the guardsman, the kid that says, would you like fries or something? I mean, this doesn't make you brilliant. Visual basic scripting is immensely easy. You can take someone who's never touched a computer and six months later they could be writing visual basic scripts. It doesn't make a lot of sense. But the problem we have now is that we're going to see a lot more coming down the pipe. Now, before we actually go into the conclusion, Steve, can you come up? Tell me what the future of computer viruses is going to be and I'm going to tell you right now what the future of computer viruses are. And Steve, actually I met Steve here at H2K. He's a great guy, really brilliant man. Not a script kitty, a brilliant guy. And we were talking during the conference here. And I'll give you the description I gave at H2K. I met him the whole world staring at this big huge fan going really fast.  That's your future. Followed shortly by a shower. What Steve brought to my attention is research has been done to show that you can actually create a binary hostile code like boot sector viruses inside embedded into visual basic scripts. Where you don't even have to read the e-mail you just have to receive it and you could be hit with a boot sector virus or a Trojan horse like B2K and get nailed.  Yeah. It's actually live right now. You don't even have to read the e-mail. Now there was a thing with Microsoft where they actually had the vulnerability with Outlook and IE Explorer and for anyone who's curious the fix is real simple. It was just Upgrade IE Explorer 5.5 with the Outlook attachments unless you're running Windows 2000 and with Windows 2000 it's Windows 2000 Service Pack 1 which is released tomorrow I believe. And that's the fix and they're supposed to be coming out with a patch. But even with that version fixed you can still get nailed with some of these things coming down the pipe. So you could actually be working your system it used to be like hey don't worry go ahead and read the e-mails as long as you don't activate the attachments you're safe. This is not the case anymore. You want to go into more detail? Sure. Oh you're live. Basically inside a VBScript and some of the more advanced programming features that are available to you there you can treat a binary file like a boot sector or a Trojan horse as a blob of binary data saved to an array and you have the VBScript could save that information to a disk and then execute it like it would execute any other command. So the binary itself isn't executed within the VBScript it's carried there as a random blob. The VBScript itself doesn't know anything about it but it will write it to your disk and then execute it like it can execute any other type of DLL or command running on the system and actuate by the boot sector or BOTK but spread at the speed we saw I Love You and Melissa. Imagine hundreds of thousands of systems hit with like BOTK that's cool that's cruel I was like that's cool I guess it would be cool if you were the guy sending it but I'll give you an update for those who just a little spot here when the I Love You virus hit F secure identified the virus within two hours of it hitting the U.S. and within three hours traced it all the way back to the person who wrote it.  Anyhow, that's my talk. Thank you very much and we'll take questions. That's a really brilliant question. The question here is why won't they detect compressed executable code because it doesn't follow the signature file which is why I said use the FINGEN software if they ever go to a security conference other than something like this and FINGEN's there their demonstration is actually very brilliant what they do is they take BOTK and they have an antivirus product software and they try to activate BOTK and the antivirus software detects it in a heartbeat well then they run it through a compression process which doesn't decompress when it executes and then they run it and the antivirus software completely misses it and then they activate their software and they do it and boom their software hits it because it runs it in a ZMZ. It says hey what? This is a malicious code we'll stop it. That's why I said back yourself up but the reason why is because it changes drastically and once they figure out the signature for that one you can compress on these 3, 9, 12, 60 times and change the signature sorry how do they track it? I don't know I wasn't involved with that but I got to see some of the white papers you know so they weren't lying do you think that's the only vulnerability? yeah that's the only one that's been released yeah right the thing is that's exactly right the problem that we deal with right now is we'll discover our vulnerability but the moment someone else discovers another vulnerability it gets exploited immediately myself look out I like to go into the device mangler myself and play around in there too so next question anybody? I'm having when the scripting test is uninstalled we don't know yet it gets reinstalled it gets reinstalled I haven't heard anything but it wouldn't surprise me it sounds like a cool idea I'm going to research it if there's any viruses that attack the antivirus the antivirus software yeah the multiply tie yes the file infectors yes they'll actually attack the thing but the antivirus software products themselves actually checked their own executable before executing to see if they're actually done so I don't know if any viruses directly that actually prevent that how much time do we have I think I got about four minutes no? yes? I'll be off here in a second one more question then we're gone there are the products you can set it up in here like you said you can set it up in your send mail what I do is I actually I block viruses at the firewall using fsecures antivirus software at the firewall level so it hits the firewall and says hey you're out of here you're out of here also by the way for something like that with a firewall antivirus product really fast machine lots of memory lots of CPUs trust me yes it does yes it does anyway that's my talk thank you much


Around 8.30. Good morning, good evening. Yeah, I'm good to see you. Good to see you as well. Hey Ricardo, I need to drop in a few minutes. I have a conflict in meeting, but I just wanted to come in and say thank you for the for the work that your new team did on evaluating Harbor. I much appreciate it. Hey, yeah, no problem. Yeah, so then it will be up to the TOC now you know to put it up for a vote for graduation. That is correct. Thank you for the recommendation. Yeah. Is it gonna go to a six storage now or is it? Six storage, complete the review. Sad did it. He added the comments on their PR, but he got busy and has not merged the PR yet. So we're waiting for that merge. Okay, cool. But they did complete the review. Okay. Awesome.  Thank you. Cool, no problem. So yeah, welcome everyone. So we have a you know presentation today, I think that's the main item for Kira. So did I pronounce that right? Kira or Kira or Kira? How do you pronounce that? Either works. We generally go Kira, but there's no official pronunciation guide. Okay, cool. Yeah, so it's Jeff. Yeah, and he's gonna talk about that and so yeah, take it away. Perfect, great. And I assume I'm fine to share my screen out. Yeah. I'll go ahead and do that so that I can show some of the slides and it's good to see we've got Anurid from Microsoft here, Tom from Kodit, Zibionek from Red Hat. I'm even probably missing a few other folks. So thanks. Thanks all for joining to help answer questions as well. So, as I was evaluating why videos things mirror my screen, but it looks like you don't see a mirror version only I do. This was my exploration this morning. All right. So we'll start with Kata, event-driven auto-scaler. This is something that we are making it. We've had a proposal open for the sandbox. So I just wanted to share a little bit about what it is and then answer any questions that you might have that can help in doing this. Previously, I think, as mentioned, we've made a similar presentation to the serverless work group to a few folks there across SAP VMware, whatever else, and that went well. But this was before the new kind of policy happened with the SIG. So some of this might be repeated if you were at that presentation a few months ago. So some background and history here. Kata was initially started by Microsoft in Red Hat primarily. For some background, so I'm Jeff, I'm a product manager at Microsoft Azure. And when I'm not focusing on open source and Kubernetes stuff like Kata, I'm helping manage and run the Azure Function Service. So Azure Functions is Microsoft's serverless offering. I can type AWS Lambda or GCP. And one thing that we had observed as a team is that we had developed some technology to help run functions and scale them effectively. But we had customers and users who are interested in using this type of functionality outside of Azure. And so we kind of looked at the Kubernetes ecosystem in general. We're like, you know what, there might be a gap here in terms of what's possible today and what we think is there. So we talked to a few folks and let me know too, if other people only see a black screen. Thanks, Tom. Yeah, we see a black screen right now. Black screen. Okay. Let me unshare. Thanks for flagging and see if resharing makes it happier again. Let me try one more time. I'm not getting any pop-ups from Mac telling me that it's unhappy. Is it still black? No, I can't see it now. Okay, great. Thanks for flagging, Tom. Okay, so we reached out to a few folks, Red Hat, and some of the folks on the call from Red Hat were like, yeah, this sounds interesting to do this event driven scaleway. So KdaEdit's core is a component that can be installed in any Kubernetes cluster that will enable your cluster to scale pods and deployments and jobs even. Not just based on CPU and memory, but based on metrics that are being pulled from the event source. So specifically in Azure Functions, we don't just scale based on the CPU of your functions, but we're actually proactively looking at the queue or the SQL database or whatever else it might be and helping really rapidly scale your functions as a result. And so KdaEdit is doing something very similar in a hopefully very seamless way. So we wanted to make it very simple to wire up metrics from event sources and plug those into things like the Horizontal Pod Auto Scalar. We wanted the ability to scale down to zero in the same way that Azure Functions users were akin to scaling to zero and saving resources. We released this last April around this time. It went GA1.0 at KubeCon in 2019. And we currently have about 20 scalars to different sources like Kafka, PostgreSQL, Nats, Prometheus, a bunch of sources out of Azure, AWS, and GCP. So even before I do anything else, I did want to show a quick demo just so that you can see what this looks like. This takes about 15 seconds. So I have a Kubernetes cluster that's already running and I have one container or one deployment that's in it and it's a RabbitMQ consumer. So this deployment, I've said, hey, it's consuming RabbitMQ messages. And the one thing to note, because KdaEdit is installed and doing all of its stuff, this is actually scaled all the way to zero because KdaEdit has let Kubernetes know there's actually not any queue messages here to consume anyway. So you don't even need to consume the resources or reserve the resources to run this thing because there's nothing to be done. And I can show you, if I just look at the KdaNamespace, you can just see it just there's a Kda operator and then a metrics API server that's running and monitoring the stuff. Now, if I go ahead and I watch the pods, this is my RabbitMQ server. And now I'm going to deploy a job which is going to publish 1,000 messages to the queue. So not just drop one message and it's actually going to drop 1,000 messages in. So we should see that job spin up and it's creating and dropping 1,000 messages in the queue. And what happens as a result then is now KdaEdit has seen, oh, there is work to be done. So now we have one consumer that's come online right away. But what's nice is that even before that sentence is finished, you can see because it wasn't just one message that I actually dropped in thousands of messages into that queue. That very rapidly, KdaEdit has actually driven this to say, hey, I actually need to scale this RabbitMQ function a lot to make sure that I drain this really rapidly. So this kind of very proactive, very event-driven scale is what KdaEdit is making possible. And if I waited here for 30, 45 seconds, it would finish scaling up, consuming all the queue messages and then scale all the way back down to zero again. So that's kind of what KdaEdit is doing behind the scenes. What's making it work is one of our core fundamental value that we wanted to do when we built this, that we set from the get-go and we continue to stand by with our communities. We didn't want to rebuild anything that Kubernetes already did. And so behind the scenes, how it works, I showed you there's that Kda operator that's running and also has its metric server, which connects to the Kubernetes metrics APIs. And then there's a number of what are called scalers. Those are all the different event sources. I mentioned like there's a RabbitMQ one, a Kafka one, a Postgres one, a Prometheus one, whatever, about 20 of them. And you end up having your event source. In the case of my demo was RabbitMQ. I think in the rest of the slides it's going to assume that it's Kafka.  So I just deployed using a Kubernetes deployment. And then there's a special CRD that KdaEdit exposes called a scaled object. And this is really the metadata of where you map your deployment, where you map your job to the event source that you care about. So in this case, I'm saying, hey, it's my deployment that I care about and I want you to scale based on Kafka. So here I provide a little bit of metadata for KdaEdit to use. I can configure things like how frequently should KdaEdit check to see if there's messages to be processed. I can also configure things like minimums and maximums. Maybe I never want to scale all the way down to zero. Here I define like, hey, I'm interested in Kafka. Here's how to connect to Kafka. I can set whatever info I need to there based on the event source. And even some values here, like in this case with Kafka, there's something called the lag threshold, which is more or less setting the target for scale. So in this case, 50 is saying, for every 50 unprocessed messages in Kafka, I want to target about one replica. And so if there were a thousand messages, it's going to try to do, what is that, 50 replicas? But if there's only 50 messages, it's only going to target about one. So if I make this number lower, KdaEdit is going to scale faster and more aggressively. If I make it higher, it's going to scale more conservatively. So you have a bunch of knobs there to help control this. So you go ahead and apply that to your cluster. KdaEdit picks up that scaled object. The KdaEdit operator knows about the scaled object. And you can see in the case of my slide, I've even graded it out because it's like, hey, I can scale this thing to zero now. Because I know the Kafka event source is empty. KdaEdit is just doing this by wiring everything up automatically for you to the HPA. So it's not using its own autoscaler. It's just augmenting the existing Kubernetes ways to do this. If a message pops in, oh yeah, during this whole process, now it's just up to KdaEdit to constantly be asking, how many events are being generated? So it asks Kafka at every polling interval and says, hey, are there unprocessed messages? And if the answer is no, then it keeps this thing scaled down. If the answer ends up being yes, then just like I showed you, you actually pop up and then potentially scale out very rapidly. So a few key features, kind of based on the demo and the architecture. You can scale any deployment or job based on event metrics by defining that additional CRD. And we're just using Kubernetes CRDs to drive the experience. It lets you scale to and from zero based on events, back and forth. It has 20 event source scalars built in. It's completely extensible. This is the largest area of contribution and interest that we've seen are people adding these additional event sources. I mentioned kind of in passing, you can also say, hey, maybe I have a long running job. Maybe every queue message isn't just a simple order I need to process. Maybe it's a video I need to transcode. And so you can actually use a scaled object mode where you say create a Kubernetes job for every event that comes in, which is a very useful model. There's ways to define authentication. So we have ways to integrate with secrets, with other sources as well. You can use pod identity if you're connecting to a cloud provider. So for instance, if you're using like the Azure queue scaler Cata integrates with Azure pod identity. And so you don't even have to pass in a password. It's just going to use its own identity to authenticate their support for that in AWS as well. And really this is about letting you focus on your app and not have to worry about the scaling internals manually wiring up the custom metrics doing the work to do this manually. Cata just makes it as easy as defining that scaled object. So in terms of community, we've been really happy and pleased with the amount of energy that's happened around Cata in its time. So we've got about 2000 stars on GitHub. A number of contributors. This is across large corporations as well. Microsoft Red Hat, IBM, Kota, Pupa, Astronomer IO. This is just the few that I pulled off the top of my kind of stand up sheets. There's much more. We have weekly stand up. So from the get go, Cata has, there's nothing in Cata that's branded Microsoft or branded Red Hat. This is something that we've wanted to be community driven. So we have weekly standups on Zoom. We actually have one coming up in about three hours. There's a website that has a list of all the scalars and a few users who are using it across their solutions to help add some more stuff. This was nice. I just noticed when I was preparing the presentation, there was even some folks who were just tweeting like, Oh, hey, Cata, this actually looks super interesting. This looks like what we're looking for. And then Richard chimed in and was like, Yeah, we've actually been using this in production for a while now. So it's very simple. Like we didn't want to make this a full complex doing 80 things. It's really just driving that event driven stale, but it does that very well. So the last slide I have is in terms of like, why are we interested in the CNCF? I mentioned already with Cata, our intent wasn't to reinvent the wheel, but it's really building on those standards and building on those technologies that are being developed in the CNCF like Kubernetes. So it makes it a natural home. Our intent has always been to do this open and community driven. While it started with Microsoft and Red Hat in a partnership, we really want to make this vendor neutral in every way possible. We feel like donating it to a foundation with CNCF is a way to show that good faith with the community. It's already MIT licensed where we're planning if this becomes sandbox to use things like the CNCF, CLA contributor license, all those things. There's no kind of we still want to hold on to this that are the other. This is really our intent to say we feel this is a useful piece of tech. We've been using tech like this to run the Azure function service. This has been in the open now for a while and we just want to go all vendor neutral now. Cata also integrates very seamlessly with a number of other CNCF projects, things like the virtual kubelet to scale out into virtual nodes. Nat scalers, Prometheus scalers, StreamZD scalers, Helm is the way we use to deploy it. We're really looking for that vendor neutral home for a key serverless capability, specifically in the serverless space. I think serverless has this connotation of being very vendor locked in and there's been some heated discussion about CNCF and serverless in general. We're really hoping that Cata can be one of those very nice pieces of serverless in addition to things like cloud events that would tie in very neatly with the CNCF. So that's all I really wanted to share. I'll stop sharing here. I saw a few comments. I think most of that is handled. So I think I'll just pause here if there's any questions or anything that you could use from us. I'm more than happy to share more. Yeah, questions on scalers. So is that a single process or is it multiple processes running in Kubernetes? Yeah, so today we have it can run in both modes. Today, the majority of our scalers are just running in that single process. They come out of the box. They're fairly light rate like each scaler is about 30 lines of go code. We have a way to make them all external and this is actually something that we've had discussions about even as recently as last week stand up, which is like there's a world that you deploy Cata and that you kind of like check all the boxes for all the scalers that you want. And now instead of getting just those two pods, now you have 15 of them and each one's doing its own scaling thing, but we didn't want to make it too over overloaded so far. So right now the majority of them run in the shared process. We do have ways for you to plug in external ones. There's a few that only run externally. And this is something that we're still kind of evaluating with to make sure that we don't get the footprint too large or we need to start to version these more independently. So we have the capability there. There's some scalers that take advantage of it, but mostly for convenience we ship most of them just in the same process today. I mean that's not necessarily a bad thing right so just because I mean if you end up having multiple processes for each scaler then you're using more resources but but like you said they're lightweight right so so maybe yeah if you add more processes there then it wouldn't affect too much. Yeah. The workload in in a Kubernetes cluster. Yep, great. And I see one question in chat from Jay real quick. Integration with cluster autoscaler not just the HPA. So there's nothing directly we do with cluster autoscaler as far as I understand though, and I invite others to chime in. How the cluster autoscaler will work is it will look at what the HPA is scheduling and the resources that it's trying to schedule. And then based on that, it can scale the cluster. So I believe indirectly Kato would cause your cluster to scale, because Kate is going to be telling HPA you need to add more resources the HP is going to be scheduling those. And then at one point the scheduler is going to be like I don't have the space to put all these things that Kate is telling me to schedule and that would kick in the cluster autoscaler, which would then scale my entire cluster so I believe they work directly. This is a common question though so I am pausing a little bit in case if you're neck or others want to. The reason I brought this up is because cluster autoscaler only has the one catalyst for scale up right which is that pending pods are queued up. And that obviously we'll talk to the underlying cloud provider and cluster autoscaler and ask the auto scaling group or node node group or whatever to expand. One thing that we hear a lot in cluster autoscaler is support for more predictive or scheduled based scale up events. So I was thinking maybe since Kata seems quite flexible in that regard and it's a wide choice of sort of the events that can trigger an action. So I was thinking maybe it would be possible to integrate Kata with cluster autoscaler and use the Kata event sources as the triggers for cluster autoscaler instead of just the pending pods queue but I don't know it's just a thought. It makes a ton of sense I mean even just briefly looking at the cluster autoscaler stuff and it does look that they are some metrics that maybe these are metrics that it exposes but yeah I think that makes a ton of sense and even to your point of scheduling. One of the work streams that we've been funneling some resources into recently is kind of along the like I mentioned it's predictive in the case or it's less reactive because it can actually see that hey there's a thousand messages in the queue let's do something and it makes maybe you set some thresholds like look if there's 10,000 things in the queue yeah go start scheduling stuff but also go go scale there at the cluster thing. Right or if you know yeah if you know you're doing you know 100,000 batch jobs starting at noon you know like you could just predictively go and and increase the number of worker nodes you know. That's the that's the one that like Microsoft research right now is partnered there they're helping tweak some algorithms where their hope is that. In addition to that like if it is every Friday at five o'clock there's a thousand things that drop in the queue or I'm running some batch. So Kata ideally would be smart enough that Friday at 455 to be like look the queue still empty, but I've seen this too many times to know the storms coming. And so now let's go and crank up the cluster auto scalar quick up the HPA in advance so I think that makes a ton of sense I'd be interested to know what integrations exist today to do the cluster auto scaling stuff but there's nothing. There's nothing fundamental to how Kata works that would prevent any of that so I think that's all within the line of thinking of how we've been approaching Kata as well great conversation. Predictive scaling of the cluster for example would would you be interested in having a history of all the scaling that we've triggered. Or do you just want to have a source to scale on at this point in time. Are you asking me or Jeff. Yes, no you sorry. Generally I'm referring to being able to change the trigger for scale up from the single thing that currently is supported by cluster auto scalar which is that there are pending pods in to be scheduled. There are alternate events for cluster auto scaler scaling down. So you can do like custom metrics and stuff like that to trigger a scale down event. But for scaling up meaning you know increasing the number of worker nodes in the auto scaling group there's only one event trigger as far as I know. So that's that's what I was referring to. Okay, thank you. Yeah, I think you you need both right so. So one of the problems when you auto scale is that you end up thrashing or you may end up. You know with more resources that you actually want. And then but, but also you when just before you scale down you want you want to know if there's something maybe, or coming up or some event coming up in the next maybe 10 minutes. So you will want to keep your cluster up and running, because let's say if it's 10 minutes, your event comes in and you've already scaled down but now you're scaling back up right so we end up kind of thrashing in a way right so scaling up down and depending on this event so if you have a way to predict some of the workloads that are coming in a little bit later, you might be able to smooth that out. And so I think that's one of the concerns. So, so how I see data for now is that it's purely focused on application auto scaling, where we then rely on the cluster auto scaling to make sure that there is enough capacity. But maybe we should indeed also have a look if we can help on the cluster side of things. But yeah, we don't really have a plan at the moment. And I see there's a nice question for you Jeff on k native. I was busy creating a GitHub discussion issue around this conversation. Okay, any relationship with k native so a few things here. That's worth noting in, in general, I think the short answer is k native is a entire that the idea of it is to be an entire serverless platform. And that's with it does about 20 things out of the box. Kata is just a very single purpose thing that's like, I'm just going to be doing event based scaling based on this kind of pattern that I talked about so it is a much smaller scope just a single use component.  There's a poll request right now in the k native repo that says hey if we actually took a dependency on kata, we could scale that thing down to zero when Kafka is empty. There's interesting stuff there and just this pulling pattern general and integrating it more tightly with k native but directly. They're they're not really overlapping too much because kata is this very single use thing and k native is trying to do a bunch of other stuff but it is one important piece to a serverless platform that we feel. And there's additional things that k native is trying to accomplish in addition to that if that if that helps. And thank you Jay for a flagging the AWS team I might ping you afterwards there's there's someone on our site to who's interested in some of the deeper Kubernetes integrations. So I'm going to see what we can do with this cluster one so hopefully class that answers on the k native stuff to let me know if there's any other questions there. So if you have k native and k they're running on the same cluster, they can you auto scale functions in the cluster or not or this is not supported yet and yes. So there's two, there's two kind of ways of doing scaling I guess I'm trying to think of the k native today does auto scaling. So as its own custom auto scaler can also integrate with the HPA and how k native generally works is that everything that it's scaling is an HTTP request. So it's either going to be a cloud event over HTTP or an HTTP or g RPC request from an application or from a client or from other worlds. So k native primarily optimizes scaling on today by looking at things like concurrency of HTTP requests, and then driving scale that way. There's this thing behind the scenes as well that's taking Kafka events and turning them into cloud events over HTTP or g RPC that kata might scale. So, kata approaches things slightly differently, and that kata does not look at HTTP requests kata is actually looking at the end event source. So kata will look at Kafka or Rabbit MQ or Prometheus or wherever else and drive scaling that way so you can auto scale today I think the reason that there's interest from both sides but k native and kata and understanding how we can bring things together is that the differences in the trade offs between both of those models of scaling only on HTTP and scaling based on the event source have some differences both are valuable. The kind of long answer to your question is, you can do auto scaling and k native today, but there are ways that you cannot auto scale and k native today that kata can enable, and the k native team is interested in lining that up. And there are a lot of case in that sentence. It's almost a tongue twister. Actually, I could also speak to that one a little bit. So I was originally so I work on Apache airflow and originally we were looking to use k native as our as an auto scaling system. And what we found was that for long running tasks, k native is kind of not an optimal solution because you have to keep an HTTP request open the entire time that a task is running. And I find that kata was a lot better suited for a more asynchronous or worker based auto scaling system. Thank you, Daniel. Perfect. Yeah, that's that's an example to have like the one when everything's HTTP base versus the events first base. That's one of those trade offs is like long running becomes a lot harder when you're trying to hold open an HTTP request for 20 minutes or whatever you might need it. Or hours or hours. Yeah. Sorry, can you hear me. Yeah, that's great. So if, if, if one user has such kind of scenario so for example, they would like to scale out their deployment based on some events. So they, they may didn't know the details of their full kid are all kinetic.  I know there may be some technical detail may be different. So problem. So what's the way, what's, what's your suggestion to this user, which case. He should use the key, kata or which case he should use a kinetic, you know, he didn't know the detailed of, you know, detail of some technology for the more HTTP connection something like that. Yep, yep. And if I, if I understand correctly, just to kind of repeat the question, it's with Knative since you're connecting directly to the event source, the developer has to have knowledge of that event source. And so what do you do in the case where you don't want to have that direct knowledge of the event source that I think there's a few different answers to this one as well. My initial thinking to is cloud events, I feel like is a very good way that this has been solved even in the CNCF of being able to say hey at the end of the day we're just going to have events that you can subscribe to and scale from that kata could help scaling that indirectly through some of the things like metrics of the amount of cloud events they're being generated. In some ways, I'd almost say that there's, there's a few ways this could be solved as well. So Knative definitely can do that part like Knative eventing specifically is all about letting you subscribe without having any knowledge of the event source. There's a way that the Azure function service like that we built our serverless service where we abstract that within the SDK that you actually deploy. So there's something called the Azure functions runtime. It tracks a lot of the details of the underlying event source and enables you to just write code, but it's the container itself that's doing the abstraction it's not some cloud event behind the scenes. Then the final answer is just cloud events in general so I think there's kind of three ways that you can cut it different SDKs like the Azure functions runtime, Knative and Knative eventing, or at the end of the day just using cloud events so it's a trade off because it's one of those things to this is this is one of the interesting discussions in the service community in general which is there's a push for how much do you abstract away the underlying event source from the developer and the benefit of it is the developer doesn't have to worry about the underlying event source, but the downside of it is the developer can't take advantage of something that's not a common denominator across multiple event sources. So I think both are important. Sometimes I want to know it's a Kafka stream that I'm connected to, because I need to have a point and I need to do in order processing and I need to do things that are Kafka specific. Other times, I just know that there's a notification that happens to be coming from Kafka but I just need to post something to Slack cloud events works great there. So there's room for both, which is why I think there's room for both the K to style and the cloud event Knative style. I don't think it's going to be a one size fits all. Okay, okay. Okay, thank you. Yeah. Do you, do you have integration also with some of the big data frameworks like spark and flink, or has there been any discussions about that? I think I know one of the someone doing big data stuff today is using kata but they're using it before the like the spark layer and they're scaling based on, I believe in their case like Kafka is the theme that is filling up all of the data and then they're using Splunk to process those events that originated from Kafka but then are going through a different pipeline. So they're using kata to grab it from the Kafka side and not from Splunk directly. So there's nothing direct, there's no scalar today directly that grabs any of those from something like a big data processing pipeline but the event source that's probably funneling the data to that big data processing pipeline, whether it's Kafka or something else than that that is a supported scalar, if that helps. And I just wanted to add that we've added integrations with two databases, MySQL and Postgres. So if you're, but yeah, we don't, as Jeff said, we haven't yet added integrations with spark and flunk but with rather the event sources that may be funneling data into those. Cool. Any other questions? Silence. How do we proceed after this meeting? Do you guys have to vote or how does that work? I think you need a consensus of two people from the SIG? Yeah, so if you can create a PR with recommendations, I mean, based on what I see from years ago for Sandbox, so I don't really have any major concerns but there's a template that we follow. So I can show you what the template is. I think there's another PR that we did for Volcano and then so basically we need to fill in all the details and we'll go from there. And after that we'll take it up to the, we'll recommend the project and the TOC will take a vote to put it in Sandbox and it needs a two-third vote. And after that it will be in Sandbox. Okay, so I thought the issue was the new approach but basically I just take what is in the issue, open a PR and we'll take it from there. Yeah, yeah. And let me know if you have any questions, I mean, about the template or anything about any item that's in the template. So it's a new process. I mean, we're just starting to use it. So we're just kind of like trying it out and if there's any suggestions or anything that might not work out or you have any concerns, just let me know. Yeah, if you could maybe go to the issue and post the latest template that I'm certainly using the correct one and then I can create the PR tomorrow. Yeah, and I pasted the PR for Volcano because I know that's the one you reviewed two weeks ago. Do you want us to open this poll request or is this something that the leads of SIG runtime need to fill out this template? And then we open the PR and then you folks can add comments and then close it. Because I see the ones they did in terms of it's more or less kind of our PowerPoint presentation and markdown which is great. Like we've got the info, but I don't know if we need to put this together. Yeah, you can open the PR and then people can chime in with comments or anything that any questions of them may have. And then the PR gets approved and basically, yeah, and then we send it over after it gets approved and Merckz, then we send it over to the TOC. Okay, so it's a PR to the SIG runtime repo, not the TOC. Right, right, right. Yeah, okay. Okay, yeah, I'll bring this up today in our stand up and then Tom and I can probably have this open by the end of the day today and it would be, I don't know how long the TOC and stuff works but I know anecdotally we've been hoping that this is something we can make some noise about assuming all goes well and we get sign off at KubeCon. Yeah, but I know that's a month away now and I don't know how quickly the wheels turn in this new process. Yeah, so. Yeah, hopefully they can put it up for you for KubeCon, but yeah, we'll see we'll see what I mean sometimes. So the TOC just got new three new members so you might actually need more votes now so so but Oh, no, wait, wait, wait, sorry, I'm talking about graduation, my bad, my bad, my bad. So for Sandbox, you need three sponsors, that's what I remember. So, so there won't be a vote, right, so so you need to find, so after we do the recommendation and we're filling the PR, then you find three sponsors in the TOC and then they'll basically say, okay, we want this project to be in Sandbox and they take it from there and then they put it in Sandbox. I don't know if it really needs a vote, I know that graduation needs a vote, right, because we're just, we're doing harbor right now for graduation, but yeah. Do they have to be a TOC representative or contributor? They have to be a TOC member, right, so so I think we have we have two liations, Brandon Burns and Brian Grant, so you could reach out to them and see if they want to sponsor the project, right, so and then do you want us to, do you want us to reach out, because I know one of the things and I know that's a new process, initially they're like, hey, if you go through the SIG process, that way you don't have to just go and poke TOC members directly. Once this goes through, do you, do you, is it best if we do kind of go find three members of the TOC and we're like, hey, we presented for SIG runtime, here's the PR that got closed, they gave us the recommendation, would you be willing to sponsor, or is that something that you have names in mind that you'll flag and we can just kind of help answer questions? No, you guys can go, actually, you guys can go in and ask TOC members, right, for sponsors, right, so it's, yeah, I mean we can, I mean as a SIG, we can help out too, and in terms of finding some more people, you need more sponsors based on our recommendation, but you can also go and contact some of the TOC members and, you know, and they can look at the presentation, this recording, and based on that, you know, they make a decision saying whether they want to sponsor the project or not, right, so. Does that make sense? Yep, it does, thank you. Yeah. Yeah, so that will be the next step, so, and yeah, just follow the PR, and then so we can get that move in, hopefully we can find a sponsor for KubeCon. Okay, thank you. Well, thank you guys, so I think the other items in the agenda are, the volcano that is already merged, and so that's looking for TOC sponsors is what we're talking about, so if you know, if you know anybody who would like to sponsor volcano, I think, reach out to the TOC member and to help out. So we reached out to Brandon and Brian Grant, who are our TOC initiations, but we haven't gotten a reply yet. And then, yeah, and there's some new TOC members, I find that some of the new TOC members are a little bit more receptive to us, because they're, you know, they just kind of want to learn more and they might be able to sponsor some of the newer projects. So, I think Harbor has already completed the review from sick runtime and so that will be set because it's a graduation so that will be a TOC vote tonight so Michael Michael will review from sick storage and I don't know if it needs a review from sick security but after that it will be sent out for a TOC vote. So cool, anybody has anything else that they want to talk about anything related to runtime, to KubeCon, to community, anything? Hey, recall, this is Tao from Kata community and you introduced sick runtime last week in the Kata AC last week. Sorry, I wasn't there but she told me that this is a very interesting working group and I'm here to learn about it and we might have something new to present to show for the sick runtime Asking for simple thing but it's not reading right now, so we just heads up and learning the process and see and prepare for myself when it comes to that. I'm happy to learn to watch the Kata sandbox review and it's very helpful and the process is helping. Thank you. Yeah, thank you for joining. Yeah, so if you if you want to present anything or anything or you want to add any agenda topic, you know, feel free to add it to the doc. So we meet every two weeks, not exactly the first and the third Thursday of the month, right? So, yeah, any item that you want to add or feel free to add it there and then we can discuss in the meetings to be a presentation or any concerns, any concerns about projects. I know, I mean, we're just getting started. This is, you know, it's been around for maybe month and a half. Six security, for example, has a lot of other stuff, you know, for example, they have a security security reviews for projects. But then that I mean that's outside the scope of this group, but anything maybe related to runtime review or, you know, maybe AI type of workloads, high performance type of workloads, you know, it's within the scope of the group. Okay, thank you. Is there any documentation on how they process the entire process for entering sandbox stage for project? Yeah, that's that's documented all on the CNCF TOC GitHub page. So there's plenty of documentation there on how the sandbox incubation and graduation process works. And then, you know, how you take it up to the six now. So it used to be before that it will, the projects will go directly to the TOC. And the reason they're creating this six is because they're there's a lot more projects so they're trying to scale into different areas. So obviously they have runtime, they have observability, they have security app delivery and storage. So, and I think there's another group in the works called contributor experience. And that double deal more about how I mean, helping out contributors in the community. Yeah, that is. Thank you. Yep. All right, guys. So anything else? No, thank you very much for your time. And we'll open up here. All right. Thank you. All right. Bye guys. Thanks. Thank you.


here, the SID display week with Kikso, and who are you? Hi, I'm Sang, and I'm the CEO of Kikso, and we built machine learning based user interaction platform. So today, I'm presenting a solution called Touch Tools. It's a solution that allows conventional multi-touch devices to understand your intention just by looking at the pose of your hand touching the screen.  But rather than doing that, what if the device can understand that you're looking for an eraser just by looking at the pose of your hand that's touching the screen? So now I'm imagining that I'm holding an eraser, put my hand down, and I get an eraser. But what if you want to draw a straight line? In order to draw a straight line, I need to use a ruler. So ruler is about this big, right? And I can hold my ruler with my fingers and then draw a line. Or if I want to change the color of the line, I'm gonna open up my color palette, which is like a dial, select color, I'm gonna go, let's go with white. I can draw a white line. Or what if I want to measure the distance of this line? In real life, I'll be grabbing a tape measure and then pulling out the tape measure to measure the distance of the line. Or if I want to capture the image, in real life, I'm gonna be grabbing my camera and putting it down on the screen, grab a camera, and then I can do a partial screenshot of that part. So it's basically a very intuitive way to summon the virtual tools without having to come out with a cumbersome gesture or even going to the toolbar. You can come out with, you can summon those virtual tools on the spot, just imagine that you're holding the actual physical tools and putting it on the screen. So it works on an iPad also or an Android? Yeah, it can work on interactive wipers or even on a tablet. So this is a demo to show you how touch tools can work on an automobile environment. So if you're driving a car with interactive surface or the touch screens. Typically in a conventional cars, you use a dial to change the volume or change the music. But on a touch screen, you actually have to focus on the screen in order to operate. So rather than doing that, what if you can summon a dial, like a big dial, just by changing the hand pose of grabbing a dial anywhere on the screen, right? You will get your dial. Or if you want to change the station, I'm gonna grab a smaller dial and turn the knob to change the station. Or if I want to open up a sun shade, typically I got a sun shade that, you know, some roof that I can slide to open. So I'll slide with my finger. Are you able to have this functionality on top of any Android app? Is this Android? Yes, it can work on top of any Android app or even an iOS or even. iOS also on top of anything. Or do you have to run your app to make way to? Our solution is a platform, is an interaction platform, so it can work on top of any app. Or if we want to customize our functions for a certain app, then we can build our engine into the app. All right, do you show a different demo on this one? It's the same demo. It's a demo that's running on Windows. All right, cool. So is it licensed? No, our business model is a software licensing model. So we work with component manufacturers and OEMs to embed our solution into their device. And so how soon is this already shipping? People are having this? So this platform, TouchStools, will be available in the market towards the end of this year. All right, cool.