All right, all right, all right. Hello, everybody. All right, before we get started, since people are still trickling in. So... Nímen shǔ zhōnggǒrén zhǔ zhō. Okay, and if you're an English speaker, please raise your hand. Great. If you're super, super fluent in English, but Ní shǔ zhōnggǒrén, go ahead and raise your hand. Okay, so we have one hesitant person there. So what this means is that about two-thirds of the audience is Chinese and doesn't feel comfortable saying that they're super fluent. And the rest of you are English, or speak English probably close to natively. I am going to speak English during this talk, which is good for everybody, especially me, because we'll put on shǔ zhō bǔ hǎl. I speak Mandarin very poorly. So I will go a bit slower. And one other thing that I wanted to announce and say about this talk is, unfortunately, my co-presenter, Ding Ma, is not able to be here for family reasons. So I'm going to be presenting his part of the talk as well on confidential containers, something that I only learned about when preparing the talk slides and the talk presentations. So I'll go into much more detail with the Intodo project, which I was one of the creators of. Okay, so let's get started. So fundamentally, the Confidential Containers Project and the things that confidential computing in general is focused on is about trust assumptions. And there's a natural question of, what do you trust in the cloud? And in general, when you run code in a container, you're trusting really everything else running on that system other than maybe other containers. You're trusting the hardware is safe and doing all the right things. You're trusting that the kernel is doing all the right things. You're trusting that all the rest of the sort of infrastructure that's in place, container D, doing the right things that somebody at your hosting provider, if you're renting hosting from a provider like Amazon or Microsoft or Google or somebody, you're trusting that those people who work at that company are not going and tampering with your data or looking at things that they shouldn't look at, right? So what's really interesting about this concept about confidential containers and that project in general is it tries to say, well, what trust assumptions should we have? Could we make it so that we don't have to have quite so much trust in so many different people, in so many different technologies? And so the real goal of confidential containers is to minimize trust in the cloud provider so that even if there's an evil system administrator at whoever your hosting provider is, they can't go in and tamper with your containers and steal your data and so on. So with confidential containers, the items that are in blue here on the diagram have actually some protection against all sorts of malicious actions, which you don't usually get inside of a cloud environment. Usually if container D or whatever you're running that does those aspects of the container landscape for you are hacked, then all bets are off from a security standpoint. So I'm going to talk only a little bit about how this works because unfortunately Ding is unable to be here. But basically confidential containers and confidential computing in general builds on concepts from trusted platform modules. So what this does is this uses different built-in hardware protections that exist inside of many modern processors and it uses those concepts so that you get a root of trust and build up from there in order to have a chain of trust and to have what are called attestations, although we're going to use that word in a different way in a little bit, that go and describe what software is running in a trusted way. And so what this basically allows you to do is it allows you to really only have to trust your silicon vendor, your processor manufacturer, people like that as opposed to always needing to go and trust all of these other parties that we saw before. However, confidential containers does have a lot of trust assumptions that remain, which would make a lot of sense. It's a very hard problem to have a way to do computation that doesn't have a lot of these assumptions. And in general, the concept is focused on boot and startup time validation of the things that it is going and running. And a real question that you have in a system like this is how do you know that the thing that you're running is actually the thing you're supposed to be running? And that is the focus of the second part of this talk. And to really get into that, we need to talk first about how is software made? So in general, I'm just going to present a kind of silly, very simple diagram here. There's lots of different ways to draw this. But you can imagine that you have a version control system. You're probably using Git and some form of hosting for Git if you're like most software projects. And you might do some testing. You can do testing over things like your source code, like linting and stuff like this. Or you can do testing over the things that you build, like with fuzzing and unit testing and stuff like that. And many projects will have both of these steps. But in my very simple example here, I'm just showing you one of those. And then you also will go and you'll have a build process by which you turn your source code into something you're going to execute. And then you will go and package it up in some way. You'll containerize it. You'll do whatever, depending on your environment.  And a real problem is that attackers can hack basically everywhere in this diagram. And even in lots of places that I haven't described. So I'll show you some historical examples of these. So yeah, Free Software Foundation was hacked. VS FTP. This was kind of an interesting one where the FBI allegedly backdoored OpenBSD, which is really bad. Juniper was hacked. This is allegedly by the National Security Agency, the NSA inside of America. So even the American government and a lot of those agencies are going and potentially hacking into these kind of organizations. And of course, things that we all care about, like the Linux source code repo have also been hacked over time and so on. And so I want to say that if I wanted to, I could have put 30 or 40 examples of this happening. This is just kind of a quick selection. This is not an isolated problem. It's also very possible to go and hack the build system. And this has been known for a long time. Ken Thompson referenced this about how to put undetectable backdoors into build systems. Apple had a big problem with Xcode Ghost.  And I actually reached out to Fedora when this first happened. I saw some of the Fedora team because I had been doing work on package manager security at that time.  If you want, I'd be happy to look at or give you any thoughts I have on any security design you have. And the response that I got was basically, well, we could tell you about it, but we're afraid it would compromise the security of our design if we tell people what it is. And as a security person, that's always a really bad sign if people are not willing to tell you what their design is. But they were actually, I found out what it was because they were actually hacked about eight months later. And when they were hacked, they revealed what their design was. Basically they'd used a TPM to do signing in their infrastructure. And so when they got hacked the second time, rather than the hacker stealing their signing key and downloading it and using it to sign packages offline, they just uploaded the malicious software they wanted to sign to the build server and just signed it on there. So it really didn't provide them any protection. Yeah, so there's a lot of examples of this, including SolarWinds. It's another one that people talk about a lot where allegedly hackers from Russia went and broke in and actually changed code right before it went into the compiler so they'd inserted code that had malicious backdoors and things like this.  I'll just go a little quickly through this so we have time for everything else. There's a lot of really interesting security bugs here. And finally, testing is another thing that often gets overlooked. So I'm going to spend a little time trying to convince you that this is an important problem. The problem is that it's not uncommon for an organization to believe that they have run tests or to have a process for running tests and then accidentally release something that didn't go through their QA process. This actually happens quite a lot. Happened to Linux Kernel. Windows had an interesting situation where they released an update that only went to certain countries that do a lot of censorship and only went to mirrors that really served those countries. And so the security community was thinking that maybe Microsoft was pushing out a backdoor version of Windows for those users in order to let them be compromised by their governments. But like two weeks after that happened, they accidentally pushed another update to a different set of update servers somewhere else. So then people said, no, maybe it really was a mistake as Microsoft claimed the first time. But this has happened for other companies. Apple, other major tech companies have done this. Lots of groups have accidentally pushed out an update that was only supposed to be a beta update or only supposed to be sent out, you know, tested or something, but not actually a production update. And even worse than this, hackers can hack all kinds of other places in between steps. So in between your code and your build process, a hacker could interfere and take, rather than build the thing that came out of your version control system, have you built something different entirely? Rather than have you packaged the thing that was built by your build system, have you packaged something else? The question is, how do we fix this? And today there's lots of different solutions that work at different points of the design space. So there's a bunch of things here with Git signing and using other kind of version control protection mechanisms. In fact, we actually created the Git tag signing mechanism that Git uses. We found a bunch of flaws in the way Git was doing tag signing and work with their community to upstream some fixes there. And we're working and have been working since to upstream and work to address other issues inside of that part of the design space.  And there are a lot of really exciting things that people have done with build security. The one that I'd like to highlight the most is the reproducible builds project. And this is the idea that you can go and take and build software on two different machines with two moderately different configurations and actually get bitwise identical copies of the software. And this lets you go and do verification that your software supply chain, the build process part of it doesn't seem to be backdoor because you have perhaps even two different compilers, at least in theory, running two different operating systems, running two different pieces of hardware that build exactly the same thing. And there's also a bunch of work that's happened in the packaging step. We've done a bunch of work in this area. I mentioned I'd done a bunch of work with the Linux package managers. I also created, and one of the creators at least of the Tough project, which I'm not going to go into a lot of detail, but Tough is used. And there's automotive versions of it that are used in automotive grade Linux and other stuff like that. But that's not really what this talk is about. There's also something that you may have heard of called an S-bomb. Who's heard of an S-bomb before? Who uses S-bombs today? Okay, a lot fewer hands, but it's still good. That's a lot more hands than I would have seen probably a year or two ago. This is an effort to try to go and capture information about the software supply chain process. And it's quite a useful thing. It's kind of the way I think a lot of people think of it, is it's like the ingredients label on a package of food where it tells you what's in it. But the problem is that S-bombs in practice are often not very accurate. The S-bomb often doesn't match what is said. There's also a lot of missing information and so on with it. And while there's a lot of work going on to try to improve this, there's definitely still a big gap here. So at least today the way most S-bombs are generated and the way most things happen, it's perhaps better to treat them as informational rather than security-critical information you can rely on, especially in situations where you might have an attacker who's compromised parts of your infrastructure. So with all of these point solutions, the natural question is have we fixed the problem? And the answer is we'll really know we haven't. Because you don't know that these steps were all correctly followed. You don't know they were done by the right people. You're not resistant to situations where an attacker has compromised or modified or become part of your infrastructure. And so the goal of the InToto project and what it provides to many projects including some work that we're doing now with confidential containers, is working to secure the complete software supply chain. And so we want to verifiably define the steps of the software supply chain. We want to define who the actors are who do those steps, which in our system they're called functionaries. And guarantee that everything happens according to the way it's defined and nothing else occurs. So the way that we do this is we have a definition of what the software supply chain is supposed to look like. That's in a document called an InTotoLayout. And an InTotoLayout consists of a series of steps. So for our simple example we had before, we have our different steps that occur and it describes basically what happens in each of those steps. Which parties hold keys. In this case we have these functionaries. These could be people like a system administrator that has a key or it could be a key inside of a TPM or some other aspect like that. And then each step has something that it produces that comes out of the step. And also a step may have things that it takes into the step. So for instance, in a lot of projects, the way that you're going to make a production release, it starts with you tagging, creating a tag inside of Git, and signing that tag. Then the build system takes that signed tag version of your code and actually goes and builds it. And then the thing that the build system produces is binaries and so on. And then that's the thing that actually gets packaged and shipped off to your users. And so the rules inside of the layout actually link all of these different aspects together. And then this layout itself is signed by a party in our system who is, we call the project owner, basically serves as a root of trust for Intodo to say, you know, this is the layout that you're supposed to follow. And importantly, when you do each of the steps that you're going to do in the software supply chain, you generate evidence called links for every step. These are also called attestations. In fact, if you've heard of Salsa attestations or other attestation formats, they use Intodo attestations underneath. So Salsa is an opinion layer on top of Intodo attestation metadata. And so each of these steps, as they run, they create these attestations or links. And then what you can do for verification is you can bundle this all together.  You send it to the end user and then the end user can go and just check to make sure that everything works and is verified according to the policy. So see here, how am I doing on time? I have enough time to talk about this. Okay, so I'll go through this in a little more detail so that you can understand a bit more about how this works and what happens here. So the layout describes in JSON exactly which functionaries, keys exist, exactly what actions are supposed to pass at every single layer and how all this works. It also contains other information like expiration dates and so on. So for instance, a layout might indicate something like that a specific test process is supposed to return a certain error code. Like when you run the unit tests, you should have an error code zero instead of an error code negative one or something else like that. And this is all signed by the project owner for authenticity and it lists the public keys for all the functionaries here. You can do things like key rotation and revocation and change functionaries and handle compromise situations in all these other cases by using in-toto layouts to do so. Then the individual steps contained in the layout describe operations in the software supply chain. These are things like once again the build process and so on. And they're performed by different functionaries who provide signed linked metadata as proof the step was carried out. It's important to note that these don't have to be computational things. For instance, if you have a lawyer who performs a license review to sign off to say a certain open source license is okay, they can just create an in-toto attestation and say I've approved this and that will be linked to the actual hash of the license that they've approved and it will all be correctly indicated in there. And in general the steps limit the actions a functionary can perform. It describes things about what the functionaries able to do and also describes things like how the materials and products, how the sort of inputs and outputs from the steps all connect together. And so within a step you also limit the trust that you apply by having different rules about this saying for instance, maybe you're saying the build process is able to create a binary with this name. That would be a very normal step to do but everything is done in a least privileged manner. We don't just blindly give privileges to steps and just let them do whatever, you go and you specify this. And usually the way this happens in practice is you'll just run your normal supply chain and in-toto can watch what you do and then say this is what I see, does this look right and you can take a peek and tweak it a little if you need to. But you can do things like this prevents situations that you have today where for some Linux distributions the same set of keys are trusted. You're either a trust developer or you're not. And so if you're the person who's supposed to be doing let's say the Pig Latin translation, language translation, you shouldn't also have access to change the kernel source code and modify the kernel package but in many distributions today you do have that privilege. Not with things like in-toto where the artifact rules will limit actually what people are able to do in different steps. So you can ever process where like creation says there shouldn't be this thing to start with but it should exist after the step. And you link steps together using rules. Match says that basically this file has to have the same secure hash with the products that came from this other step. And so this is how you can ensure things like the things that came out of your build process are the things you package. The things that you tagged are the things that went into the build process. It does all of that. So yeah it ensures that in this case the VCS works this way. And then inspections can be used to verify metadata within every step. They're performed by the client and it can provide, it can use additional link and other metadata attestations and stuff like this. If you're doing normal salsa things today you're mostly doing just like isolated pieces of link metadata along with inspections. For the most part salsa installs tend not to use layouts yet because they require a little more work to set up. So for example here an inspection would do something like ensure that all of your commits are signed if you have get signing turned on. Verify that only certain people who are allowed are the ones who've done the merges to master. You can have those types of things be done in inspections. Okay so I'm going to wrap up and I want to leave plenty of time for questions and back and forth with the audience because I know when I go to a talk I often think that's the most valuable thing is to listen to the speaker answer questions rather than death by PowerPoint which is what sometimes it turns into. So to wrap up I'll mention a few things that I hope you take away from this. So securing the software supply chain is really important and absolutely confidential containers is a really important use case that we're really excited to be working with on this project. In total is a Linux foundation project that's widely used in industry so you'll see it popping up all over the place. Pretty much if you hear someone talk about a supply chain at the station what they're really saying is in total underneath. We were the first tool like we were doing this before it was cool. I don't know if supply chain security is cool now but if it is then we were doing it before it was cool. When we still had to convince people no somebody could really break into your compiler and stuff like this. And the my former PhD student Santiago Torres that is has done an amazing job with this project. He was in my office for many many months almost a year where we worked out on the whiteboard different approaches for trying to handle like a candidate set we take in I think I don't know a dozen or so real world software supply chains from different organizations and tried to work out exactly how to do a lot of the metadata signing and storage in a way that worked well for everybody.  And we're really pleased to see that a lot of people who've come after us it's been very common that they come and say oh well I like in total but I think I want to do the metadata this way. And almost always in fact I think to date it's always been one of the things we thought of and then tried and found it didn't work for some reason. So then we go and say oh well you have this problem if you do it and you have this problem and you have this problem. And then they say well what do you think we should do and it's like oh just use our just use our simple signing framework and so it's what a lot of folks have done. So yeah I encourage you all to give in total a try and let us know any thoughts or questions or things like that. We're really friendly community and always welcome participation from others. So with that I'm happy to take any questions. Yes. Okay let me answer it. Yeah let me answer that question first and then I'll listen to your second question but I'm going to repeat your question first because I want to make sure everybody heard it and it's on the recording. So your question is is that is it critical to record things from like a TPM or etc. as that are as part of the build process or do you really get any advantage if you don't have something like TPM recording or other kind of root of trust or your functionaries in a system like in total is that a good. Okay so you do you do get an advantage to recording it using in total. You do not get the same level of advantage by doing by using a TPM. TPM is much stronger basis for you to do attestations on top of but you still get a lot from just signing things with functionaries in the right places and we've actually gone and done an analysis using the software supply chain catalog of vulnerabilities that are maintained by tag security and the CNCF which by the way is another friendly community that I'm a member of and I encourage anybody who's interested to come to our meetings and join. Anyway so we went through and looked at a lot of historical compromises and a lot of them would not have necessarily been protected with you know TPMs or with other stuff like this. Things need to happen in the right place but you get a lot just by signing with functionaries. You actually get you know a very substantial percentage when TPMs are used in some environments that's just going to raise the bar and make those folks already so much harder to hack. So it adds value but right now the bar is low enough that attackers it's it's not clear how much of a difference it is between signing things and so on. As TPM is from my understanding TPM is a very complicated device. Should we use TPM or we should just use some like confidential computing technologies like TDS or other measurements just like the RTMR. This values to implement simple or simple measurements mechanisms. What do you prefer is TPM is TPM is too complex. So I will say that's a little more out of my area of expertise but I'll take a shot at answering your question which is to say in general you want to use whatever technologies you have. That are available but everything in security has a cost benefit trade off. And if the complexity is very high in using a system you also have to look at what it protects against TPMs tend to be good at giving you hashes of things at boot time. That tends to be what is fairly useful and they tend to also end up with a fair number of assumptions about the security of the things that are running. Like you know at lower levels that basically you don't have certain types of vulnerabilities and stuff like this. So it's really hard to judge. In general most systems that have TPMs and do these types of things haven't been hacked. But then we also don't see a lot of insider attacks at cloud providers in general. And I think that probably the answer to that is like let's say you heard that one of the major cloud providers had the administrators going and looking through people's cloud environments and stealing company secrets. What do you think would happen to that cloud providers stock price. What do you think would happen to their user base that would all just go immediately down. So they're all the cloud providers are very incentivized to play well and do a nice job in general. And so there's you know a question about how much effort and thought you know and work needs to be put into that aspect of it. So putting some protection in place probably gives you you know such a high bar that no one is going to cross it is my thinking. OK thanks for your answer me. OK. Happy to take any more questions if anyone has one. Just a moment. Just wait for the microphone please. I think my question is very simple because I do not know idea of the in total. Sorry. But I because I you and the previous speakers talk about many of the TPM. I do not know what's the Stanford TPM. OK. Just a trusted platform module. The way to think about it is kind of like it's a thing in inside your hardware that's like a secure processor that can do certain things. And what it can do depends on the type of TPM that exists. There's there's some variation. But in general it lets you go and either run code in a more secure enclave like environment. You might have heard of things like SGX and stuff like this are ways of doing that. Or it can do things like just have keys and stuff that it manages internally and then can compute hashes like secure hashes over parts of memory. And then often what you'll do is you'll provide that to a third party. So part of the dream of TPMs at least originally is that you would be able to walk into an internet cafe back when that was a thing. And this is before cell phones were a thing.  And the idea was is that how do you know that that computer is trusted. Maybe you want to look at your bank stuff and other things. And part of the original motivation behind TPM was it would boot part of the system. And then this hardware would constantly be checking to make sure that no malicious code had run as part of the boot process. No malicious code had run later as you're doing different parts of the bias and everything else. No malicious code was running as part of the operating system. You loaded all the correct things. And then you would know that OK now my application my web browser my email clients my whatever it is that's running on here. I can trust it because it's running all the right things. If you trust that you have to trust the hardware maker but it's a much lower barrier for that. But it's really morphed into something different in the last five to 10 years where it's been a lot more about isolating bits of computation on a big running system. Because one of the problems with just doing everything at boot time is operating systems are very complex. They have lots of bits and pieces. They have lots of bugs. There's lots of other issues and stuff like this that can make them exploitable. And so being able to do more with things later in the process makes TPMs a lot more valuable like makes trusted hardware a lot more valuable in practice. So I hope that helped. Thank you very much. Anyone else have a question or does anyone who's like a hardcore TPM nerd want to correct anything I said OK looks like no more questions. All right well thank you all for coming. Enjoy the rest of your conference.


So my name is Jeff Kolasnikovic. I am the WebSocket guy. We're gonna talk about WebSockets for the next hour ish As you know it figures as soon as I get in the room my demo doesn't work I just want to test it. So there might not be a demo Anyway, I'm a brand new speaker and relatively new. I've been speaking for about a less than a year now and I encourage you all of you to get out there. All of you know something that Is useful and valuable I wanted to put this this is my favorite of those O'Reilly really Images ever Exactly The good thing about being a speaker is you don't have to pay $1,500 to Sit on Slack all day. You can do it for free I'm kidding Kind of So we're talking about real-time applications with PHP I want to get a few definitions out of the way. It'll make the rest of it a little clearer. I hope So Ever since the dawn of the internet, we've been looking to find a way to update the web browser with real-time information As web pages have increased in complexity. We've changed the approach we've used to getting new data on to the browser and Real-time is the goal like you want to be able to open a page and get real-time Stock quotes or games scores. I'm from Canada. So everything's hockey. There's no sports. There's only hockey Anyway real-time is the goal and we want to update the the web page with new information as soon as it's available Now how do we do that? Here's a here's another definition half versus full duplex half duplex means Communication can go one way at a time So the web browser can send information to the server or the server can send information to the browser But it doesn't work both ways full duplex means You can send it both ways the client can talk to the server the server can talk to the client And there's that open communication between the two So maybe I'm I'm dating myself But this is the old way we used to do it the browser would refresh every so often and we get new information on the page That's maybe not the best approach and actually One of the I mentioned sports earlier and one of the sports sites that I read Actually still does this. That's that's how they refresh the page and get new scores on it. It's absolutely embarrassing So this is the old way Ajax and this is half duplex So over time your browser says, hey, is there anything new? And the web server says Maybe well no not this time, but you know ask again in a minute and there's this process over and over again of the browser requesting new information from the server and The server responds Now there's a few problems with this approach One is every time you do a request it takes Some amount of time to establish the the connection get the data back process the data and Go from there Another problem is that we don't know who's actually connected to the server and That's really important for games because these could be different browsers Well, not this the response is going to come back to the same browser but that could be a different browser from that and If you have that doesn't scale this this approach doesn't scale all that well If you have a thousand browsers looking for information, that's a whole lot of polling a whole lot of startup time and a whole lot of Waiting This is Another approach Long polling so your browser goes and requests the web talks to the web server says is there anything new and Once there is new information the server sends the data back So this is actually what Facebook uses or it did a couple years ago They use that they use this approach because Web sockets weren't all that There wasn't web sockets to use really so This time here the web server The web server request is just holding on to that Request from the browser and doesn't send anything back until There is an update Once once they get a response from the server the client makes another request The good the upside with this is that you do know who's connected to the server at least for this part when the browser Does the request you know who's connected? But after here, you're not going to necessarily know who's connected. So this is the This is web sockets. So your browser makes a connection to the server And then once that connection is established They talk back and forth because you have you have a persisting connection the connections made you've authenticated it So you know who's connected There's also no startup time for a request. You've already formed the the connection so All the server or the browser has to do is make a is make a request or send some information and The other thing that's neat and this is full duplex by the way The other thing that's neat is either side can connect can terminate the connection So the server can say okay, we're done. We're done here and then the browsers Doesn't work anymore. So let's talk about web sockets. They're part of HTML 5 and They're The w3c's attempt at real-time communication for web browsers. Now. I'm sure this approach is going to change over time As as all technology does but this is this is the the new hotness right now The good news is it's this has been around since about 2008. I believe So it's been adopted by most of most web browsers The first time I gave this talk. There was a big red eight here under IE and That's a that's that's a whole fun ball game You have to you have to have a workaround for IE eight But you can see a small sliver here. This is web browsers by Market share, I believe so Well, IE eight is disappearing. It's still not gone. So where our web sockets used social media is An obvious one to me. It's easy to implement a chat with web sockets. You want real-time communication communication between people Something like Facebook Messenger would probably use it Updating your feed not necessarily that like I said before that's that's for They use long polling for that online games is an obvious one You want to update the screen as soon as somebody else makes a move Something like chess maybe not but you know a real-time game between two people Absolutely collaborating documents Trello uses web sockets to push Changes to collaborators if they if they both have the screen open and it does fall back to Ajax if you're using Internet Explorer 8 and Tracking live data so stuff like sports scores financial tickers that sort of thing So with PHP the implementation is is such that you need a web socket server And that's usually well that can be written in whatever you want, but in this case we're writing in PHP And you have your browser JavaScript now since web sockets are built into your browser You have access to it Was anybody else like a giant networking nerd and in university to your college?  We're binding it to a port and an address and then we start listening and that's I Just wanted to show you how much Goes into building a web socket or sorry a traditional socket You can actually run this and I have a little more code that I'll share with you later and You can tell that to it and type some stuff and it echoes it out on the screen.  They're they're similar, but they're different So when you make a connection to a web socket, you're actually connecting to an endpoint. So slash chat and You you request slash chat and the web server sends back an upgrade a 426 upgrade and Then it sends Yeah, an upgrade Switching protocols and that opens the stream to the web socket server So you have a it's you have a web socket server and you have the HTTP server and They kind of work together here So really the main difference is the upgrade request for when you request slash chat Now since JavaScript has this Has web sockets built in Building something with node is pretty straight forward. We're not here to talk about node, but I Wanted to show you the six lines of code It takes to make a web socket server in in node and that's using Socket IO dot IO I believe yeah socket IO And so that is the server side JavaScript That feel weird to say so server side JavaScript still. Yeah, I know it's been around forever for PHP we have something called ratchet and This is web sockets for PHP It's a library It's got hooks for it has a web socket server built in it has an HTTP server to do the 426 upgrade and It's got all the events so We'll get into the events in a minute, but stuff like receiving a message sending a message So this is a really basic web socket server written that's written with ratchet and You can see the HTTP server is built in and then there's a web socket server and Then inside that is the new chat and that is the actual class that you're you build You would go and build as a as a developer and implement the interfaces So you're instantiating the object That actually runs the server the rest just gives you the functionality So don't worry if you can see if you can't see that I'll go into a little more detail in a sec But this chat class is implementing the message component interface So that means you have to implement those methods the on open on message on close on that error And I'll explain those in a second So You'll have to take my word for it, but there's an SPL storage object storage and When a New client makes a connection to the server It takes that connection that gets passed into the on open and Attaches it to the SPL object storage and so then we know who's who exactly is connected to the server And that's extra useful because I'll show you in a second. Well, and then on close is is In this case, you're doing the opposite. You're detaching it from the SPL storage So on message, this is this is a little more interesting So when we receive the message It's looping through all of the clients that are in the SPL object and If the from is not the client so if if the person sending the message is not in that list or As you loop through it the user who sent the message Doesn't get sent that message So everybody else gets the the message that was just received and then it fires it out to all the other connected clients on the other side This is so this is the client side and this is a whole lot simpler That website socket object is built into your browser So all you have to do is really implement the the on connect on open on close portions So you can actually tell if your browser is connected to the web socket server and you can maybe force it to try to reconnect or display a message to your users and all I'm doing on on message is On message is when it gets when a message gets received So all I'm doing is pre-pending something that says, you know, that's not me sending the message and then again from the client side And sorry for the jQuery. I know it's ugly but when you when you actually click the send button it takes the value of the message and Sends it to the connection. That's what con dot send is doing Now this is the part where I was going to do the demo, but we're on a flaming plane That's crashing into the ocean right now and my demo is not working So I apologize But what I wanted to show you is And I have a demo you can try this at home I'll give you the link at the end of the presentation But I have a Demo on github that you can try all this stuff out with So you fire up the the socket server and then you connect your browser to it and you know if it makes the connection great, if not it'll display an error and What's neat is if you kill the the server the web browser will actually say disconnected. I find that kind of stuff fascinating And Then you can actually open I have a client side version of that And you can open two or three different ones Connect to the same socket server and then they can all chat with each other But I don't have that so we're not going to look at that today The web protocol came about from Web sockets from the it branched out it came from the Sorry, it lost my train of thought Wham came from web sockets. They think it's a better approach to doing web sockets and What Wham gives you are two things RPC and pub sub RPC is making a specific Request to a Method that you're obviously that you're you're exposing So maybe you can say get me a list of connected clients or give me the store of the leaf game Whatever that is and then pub sub You can it's think of it like a chat You can publish things to a certain channel and everybody who subscribed to that channel will get those messages Now there's a Wham version 2 that came out about a year ago And unfortunately ratchet only supports rant Wham version 1 But that's still good enough to play with So this is what the Wham protocol gives you you get an on open similar to Similar to the other web sockets you get an on open on closed So you can still you know when somebody connects you can connect that attach that to the SPL storage or however You're you're maintaining your list of connected clients On call is for RPC calls. So if I make if I I get that information the topic means In this case that was confusing that took me like a day to figure out what not really a day, but a That's the method that's being called And then you get some parameters you can pass in so So I Let's say you call log in you'll in your topic You'll get log in and then you and then in the parameters you would pass in username and password and any other information you need to pass on subscribe and on unsubscribe so that's subscribing to a topic What do you want what do you want to happen if somebody subscribes to a topic or unsubscribes and on publish Published to a topic. So let's say I'm I'm sending something out to a topic that gets published and then we have an on-air So with RPC calls RPC calls our remote procedure calls you can call custom functions This is a one-to-one communication with a server. So this is for Instances where you need a User is going to be working On something differently from the rest of the users. So this is One-to-one communication This is stuff like communication between browsers and games and things like that and by sorry between by Communication between servers. I mean Sorry, sorry This is this is a bit of a new talk. I I rejigged it so I forget a bit of this The server can actually make a request of the browser and vice versa. That's the full duplex and Pub sub So one way to use this and I'm kind of getting into Bitcoin right now not Bitcoin But what's the other one? Ethereum and I've got servers communicating with each other and They're actually using web sockets to and They subscribe to topics so When each server Needs When when the configuration changes you can subscribe all of those servers to one topic and then fire out An upgrade request or a configuration change This is not limited to one-to-one communication. So this scales a whole lot better than RPC calls RPC remote procedure calls And this one important thing to note is that a client cannot request information outside of what's published So I worked on a Project, it's actually a game It's a training tool. I can show you later if you're you're interested But what it is is what it does is the way it used to work is it was built with Ajax and Every time every five minutes the game would save itself But what would happen between those five minutes is the browser would crash or the server would go down or you know There'd be some sort of problem and the person playing the game would lose their information So we attempted the idea was to make it so that a User could have Making it a lot more robust So we use web sockets for it so every time somebody did something on the game It would fire out a save request and then update your score The scoring would happen on the server not in the browser and it was real-time Ish because it was a whole lot faster than doing it with Ajax and there wasn't that five minute delay between the two So now that I've done that I have a few suggestions if you're looking to implement Web sockets in your application PHP just isn't good at running 24-7. I'm a PHP developer. Please don't think I hate PHP. I don't But we've had all sorts of crashes with it, and I hope to save you guys some some of that angst and and Late nights that I had We also had just random crashes and we actually had to dig into we we did a We had PHP core dumping And all sorts of fun stuff and also we had to deal with firewalls and proxies so I don't know if you can see that but that's a core dump and And That was not a fun day, but what the real problem was was the Redis read and write was the Redis server was dying and It wasn't dying. Sorry. That's that's not true There was a persistent connection between PHP and Redis and then Redis would time out because nobody was using that connection And then Redis would go away so we had to turn off persistent connections and Then if this that connection between the Web socket server and Redis went away it would reestablish the connection and We would be fine, but that that took a lot to figure out You limits anybody know what a you limit is What's a you limit excellent answer Yeah, it's by the OS Now does anybody know the default number of Files PHP can have open at any given time It's 1024 This is how many files the operating system thinks it can have open 65,535 So there's there's that disconnect between the two PHP only thinks your file handle opener high file And file handle can only go to 1,024 and so when it requests A file it crashes and sorry the reason this is an issue is because in Unix everything gets treated like a file Files or files directories are technically files And Certainly socket connections are files. So as you're opening more and more connections You need to pay attention to the you limit So the way to change that in PHP is to recompile PHP So we didn't want to do that so So Unfortunately right now we have a theoretical of limit limit of 1,024 connections per server what we did is we limited the we created a new user in on the server and we set the you limit to 1,024 to match PHP and You can actually create that those two lines in Slash ETC security slash limits Once we fixed that we had a whole heck of a lot of less problems the next problem we ran into was our game the game we built is for It's mostly used in universities and I don't know if any of you have dealt with university IT departments But they tend to be a little Yes They lock down their networks like anything So like I said before your WebSocket server is running on a port and in general Not in general a lot of the time The overzealous admins Will block anything above port 1,024 which you know makes sense But it's a problem for us So we need to we need to weigh around it So we had to be a little creative with that and I'll get into that in a second So engine X was came to the rescue We need to we want to we also wanted to load balance it We wanted to monitor it and we had to get around those firewall and proxy servers So our engine X Config is such that if you connect to if you request slash WebSocket on port 443 Engine X is actually load balancing three WebSocket servers And here's the configuration for it and we are going to switch one day to HA proxy It's just at the bottom of the list of things to do Here's the configuration for engine X so we define our Upstream sockets, so they're all on private I keys on 40,000 and If you request slash WebSocket, it's going to do a proxy pass to this upstream And it's also going to force you to do an HTTP upgrade and a connection upgrade You'll notice this line this line says if you can't see it it says least con and there are five different strategies for load balancing and least con is one of them It means the least connected Server of those three will get the next connection. There's also round Robin, which is the default one IP hash so I guess that I'm not sure what that one is Hash which again, I'm not sure what it is. That's my that's my system in job and Least time so that's the least latency whichever is the quickest You can also do stuff like server waiting So if one of those servers is be fear than the other ones you can send more connections to it There's there's all kinds of stuff you can do with that. I that's not necessarily my area So load balancing helps But what if one of those three go down it takes a certain number of failures for A node to actually be considered down by engine X So your users still might be getting down messaging So they might need to refresh or or try to reconnect We are monitoring our WebSocket servers by polling each one and we're sending just like a I built in a hello world RPC call And if you get a hello world back, you know, it's up But if you don't then we get then it sends a message to log glee and Enough log glee notifications and we know the node is down and we know to go know to go we know to go and reboot it now Because I like you guys everybody I'm gonna give you a business tip Nobody's doing WebSocket monitoring that I know of I'm sure somebody's gonna put up their hand and say I know some The big boys aren't doing WebSocket monitoring New relic supports process monitoring, but that's a little different from actually monitoring the port to make sure that the server is up So go start a WebSocket server monitoring business So that's new relic You can see our app is only using about 35 megs of memory and That's our CPU load. So that's actually that's actually from production. That's one of the servers and You can see it doesn't use a use a whole lot of resources Taking up my demo really killed only a half an hour in So WebSockets, they're you know, they're a whole lot faster than Ajax use them. They're they're a fun toy They there are some caveats Definitely use the server or sorry a library like ratchet. It gives you a whole lot of Functionality for free That code example of a Socket server that's a whole lot of work to implement that in PHP use the use ratchet use something similar to it Do know that you're running a separate server and you have to monitor that somehow if that goes down That's your connection your clients won't the the users won't be able to connect. They'll be unhappy One thing we do is if the server can't or if you can't connect to the server The application actually says sorry cannot connect and then we have a retry button So you can click that and it'll retry to it'll try to reconnect to the server Doesn't always work, but that's the idea and actually Since we implemented this, I think we've had maybe a half a dozen Incidences over the last two years of the WebSocket server being down of downtime that actually can be pointed at the WebSocket server So if you build this right You can get a whole lot of stability out of it So here's the URLs This is the WebSocket demo that I was going to Demonstrate unfortunately, I couldn't There's the link for ratchet more about the WAMP protocol and the Node.js library Are there any questions I can answer Yeah Like Sorry, I didn't explain that very well, right So the U limit The U limit is set on the operating system So you can actually change that So if you set it to 1,024, it's not going to go above a file handle of 1,024 So it matches PHP's 1,024 So what happens when PHP wants to open 1,025, want to still throw the same error about not being able to do that though? Loops around So it goes back to 0 for 1 So that's it, it'll just like if there's a file handle that was just not cleaned up, it'll go back and reuse that Yeah, it might not go back to 1, but it'll it'll Start over So the U limits by themselves don't like garbage collectors the problem and doing that will force it to try and go back around again? No, it's not garbage collection. It's It might try to hand PHP might ask for a file a file handle and You know the operating system might hand sorry And so it crashes I was thinking like even with the heart the limit there that force to go back to zero again It's like but what if zero is already hell? Well, it'll it'll increment it'll the operating system knows what file handles are open So it's it's gonna decide what file handle to hand PHP when it when PHP requests a new file handle If there were still like if it was still trying to open 1,025 Or had that open at once and none of them were free up to use again Well, that's why the theoretical limit is about a thousand users. No, that's a good question That is exactly where load balancing comes into play so we have three servers We don't come anywhere near 3,000 users at a given time. We maybe have a hundred on each server It would be Yeah, we should probably use this because of Since we're being recorded Thank you Yeah, so I know that people who were doing this a few years back With triple they were putting no JS in front of it. Yeah, and no JS Since it's asynchronous Seem to be pretty good at handling ridiculous and large numbers of Web sockets and Then there was some kind of proxy game that Went back to How exactly they did that Is that still a strategy that people use? so so I was doing some really researching for this talk surprise and Trello uses it and They found the there's a blog post by Joel Spalski about Web sockets And he talks about how socket IO can only handle about 10,000 users per node So they still have those problems with With node That was one of the things we considered doing When building our game is going through a node JS socket server. The reason we didn't is because We wanted to use some of the functionality in our legacy PHP app And we didn't want to build an API like that seemed like a whole lot of work to build an API just to talk to this back and forth and at the time the my SQL driver for node JS was Flaky at best it was still immature and I know it's gotten a lot better since then So that kind of limited us with what we could do it is a strategy if it works for you great It's picking your point absolutely it is I Don't like extra hops. I like as simple as possible one hop between the client and the server So that's why I took that approach I don't know I wasn't prepared for that question would I go for that You know what considering the success of the application and it does run and it runs really well I probably would and we haven't had a whole lot of breakdowns So yeah, yeah, I would Sorry So the application is the site so you send You send a request to the server and then the server says hold on I'm gonna I'll get back to you and Then once the server decides what information and that can come from anywhere can come from php You can come from cold fusion it can come from whatever you want, and then it sends it back It's just responding to other people so it's your that that request is going over and over again So you make the request it returns information you make the quest again and wait for More data Yes, yes, exactly anything else Yep Yeah, you do So this is server side and you're gonna get it'll trigger the on-close event I Think you would have to build that into the application Oh, so you know what sorry, that's not true You're gonna get You can get an on error message, and I'm sorry. This is tiny But you will get an error notification if something goes catastrophically wrong. Yep That's and actually this is at the top of my it's pinned at the top of my Twitter account. So if you Forget to do that You can just go to my Twitter and it's there It'll this will be up on YouTube So since your application's been long-lived and I was wondering if you ever had like the migration like it's 5-7 or We're still on PHP 5 Just because we haven't tested the code base on 7 yet, so I don't know yet. I'm a little anxious about that Yeah Yeah It could yeah, there's some interesting messaging going on behind the scenes and ratchet Did I miss anything anybody? All right. Thanks very much


When studying CRTs, you may come to notice that most of the gold standard CRT displays for analog video are from Sony. Sony dominated the CRT landscape with their legendary Trinitron sets. Some of the best Trinitrons are the professional video monitors or PVMs that Sony manufactured in the 1990s. Today we are featuring one of these Sony PVMs, the 504-1Q. This unique CRT was one of Sony's smallest PVMs ever made. It has a 5-inch full color screen, but also supports RGB and component video in addition to composite video. However, one of the biggest features of this monitor is its portability. It can easily be moved from one place to another since it only weighs about 12 pounds.  It can run on AC current, DC current, and even has a bay for a proprietary battery that was rechargeable. The inputs on this PVM are in the form of B and C. You can input composite video and output that signal. The PVM is self-terminating, so you won't need any terminators. The PVM will automatically detect and display NTSC, HAL, and even CCAM color video for ZEZ. The PVM does support the superior video signals of RGB and component YPBPR. It also will handle almost any sync you can throw at it. I paid $210 for this one, but I had to take a risk if it worked or not because it was listed as untested. Thankfully, it does work, but it still should be serviced. Let's go through that process. We're in the servicing lab, and this 5041Q has been completely serviced and adjusted. I've got a nice scrolling pattern there from the 240P test suite going, and I'm going to give you some ideas on what you need to do to service this level of a CRT because I always like to service these before I really go into depth on featuring them. To start things off, you always want to inspect inside and clean everything out. That's one of the most important things on these old monitors is just cleaning out all the old dust and debris. Over on this side is the deflection board, and there is a cap kit available for this board. I've already replaced the capacitors in here, which is an important thing to do if you intend to use this for any amount of time and have good adjustments on there because these potentiometers down here, these adjust all your geometry settings, and I'll include some photographs of the cap kit, and I think it's about 19 capacitors and all, so you take out the old caps, install the new caps, and then you can go in and reflow solder on some of the vital areas like these chips, ICs, really anything that would get a lot of heat, and again especially the potentiometers. From the other side of the monitor, we'll look at this block right here. This is actually the power supply for this CRT, and it needs to be removed, and then you can service it. I'll include some photographs of how to do that, but there are three capacitors in there that will go bad, and when they do, they spit out a bunch of juice. Thankfully the ones in this one did not go bad, but I went ahead and replaced those with three fresh capacitors, and then again I reflow the solder on the entire board for this power supply. Now if we step down from the power supply, this is our color processing board, and it is the B board. There is one issue on this board that you do need to consider, and that's these two potentiometers right here where my finger is. Normally, if those are orange, then they should be replaced, so if you open up your monitor and you have orange potentiometers right there, I've replaced my orange ones with these white ones, and I'll include some pictures of that process, but again you need to remove the old potentiometers because those are prone to failure, and when those fail, you will only have a black and white image on composite video for this monitor, so you need to replace them. Then after you replace that, you'll install these two capacitors right here on the back side of it, and I'll include some better photographs of that because I've already insulated it here. The rest of this monitor is normally just cleaned, and unless there's an issue, we're not really going to do any more hardware rebuilding on it. This is one of the more interesting pieces of this monitor, that being the bezel, and if you look underneath, it's all pretty much one plastic piece here, and this can crack, but thankfully this one's in pretty good shape with no cracking, and it's been cleaned up here. I did leave those two posts on the top, and then I removed the side posts right here, which connect into these rack mount pulls, and then I also removed the actual screen coating, which is tinted, if I show you, it's got a tint on it, and this one's in really good shape. It's been cleaned up, and sometimes you'll find these with a lot of scratches or even cracks in them. You can remove that. The screws are nothing more than a hex pattern, so you can remove them and just remove that overlay if you want, but since it's tinted, I actually want to keep that overlay, and it's in such great shape, but this is just a closer look at the bezel, and you have very limited options on the front here just due to spacing mostly. Here's our finished bezel. It's been cleaned now and put all back together, and it's ready to just slip right on the front of the PVM here. Just go right over top of that, slip right over everything, and it can be screwed right back into place. Now that we have the monitor serviced, let's talk about the tube. This PVM uses Sony's A13JZV00X Trinitron CRT. This is a P22 phosphor picture tube with a resolution of 250 TV lines, and it utilizes Sony's patented Trinitron electron gun technology. But how does it look? It is simply stunning. 240p video is sharp and bright. The colors are visually stimulating. Composite also looks surprisingly great, but it does look better in RGB or component. The monitor performs amazingly well, but can you really game on it? Alright, I know exactly what we need to do here. We need to get on the old personal computer and see what Twitter has to say. Alright, let's just fire up the old VIC-20 and see what the internet has to say about the Sony PVM 5041Q. Dear Twitter, who can game on the Sony PVM 5041Q? Now what we need to do is sit back, relax, and wait to see what the internet has to say. Are I Twitter a true place of reason? Who'd have thought the VIC-20 would come through so great on our post? Graphics gear? Cool little picture? No one. Anything less than 8 inches is too small. Anything bigger? And I feel emasculated? The kind of people that try to undo them on a pregnancy test. Just some little guys.  Oh man. Alright, that's enough. Well, surprisingly helpful there, Twitter. Anyways, the question still remains, can you comfortably game on this 5 inch PVM CRT? You can comfortably game on this PVM. Thanks to some of its features, the screen has an anti-glare plastic layer to help improve the picture. This plastic layer also prevents the screen from being damaged while moving the PVM. The CRT includes an amazing kickstand. This can be used to angle the viewing area up to your eye level and as a feature Sony should have kept on the 8 inch PVM models. So if you sit at the correct angle and distance from the PVM, you can comfortably use it to play single player retro video games. Gaming on a CRT this small won't be considered a great experience by many, but it is still plenty enjoyable in short doses. It's a great collector's piece too, since it's so small, it can fit on most desks. It's also a great conversation piece for your normie friends. Originally Sony created these devices as a way to solve a problem. The problem being a lack of good performing and reliable video monitors that were able to be portable, durable, and usable. The PVM 5041Q meets and even exceeds these marks. It is a fun and beautiful piece of antique hardware. Is it worthy to game on? Well, I believe so, but what do you think? Let me know in the comments. Alright everybody, thank you again for joining me today as we went through a deep dive on this Sony PVM 5041Q. I just want to say a special thank you to everybody who supports this channel and all my endeavors on Patreon without you I could not do it. If you did like this video or this kind of content, please make sure you're subscribed to the channel and do hit the like button for me on the video. I also want to let you know that I do have more information on how to service this set available. I'll have a post linked below that I've written for RetroRGB.com on how to specifically service the color boards on here and I'll also include links to a live stream I've done in the past where I did the cap kit on the boards as well as that color board repair so you can see a good example of how to complete that process and there's plenty of pictures in the post for RetroRGB. But that's going to do it for today. Thanks again for watching everybody and I'll see you all next time with some more retro content.


Irritable bowel syndrome is a chronic gastrointestinal disorder that affects about 1 in 10. You may have heard about those low FODMAP diets, but they don't appear to work any better than a standard advice to avoid things like coffee and spicy and fatty foods. In fact, you can hardly tell which is which. But most IBS patients do seem to react to specific foods, such as wheat, dairy, soy sauce, or eggs. When you test them for typical food allergies, they may come up negative on the skin prick test.  Enter confocal laser endomicroscopy. How cool is this? You can snake a microscope, down someone's throat into their gut, and drip on some foods, and watch in real time as the gut wall becomes inflamed and leaky. You can actually see the cracks forming within minutes, but it had never been tested in a large group of IBS patients until now. Using this new technology, researchers found that more than half of IBS sufferers have this kind of reaction to various foods, what they call an atypical food allergy, that flies under the radar of traditional allergy tests, exclude those foods from the diet, and you get a significant alleviation of symptoms. But outside of a research setting, there's no way to know which foods are the culprit without trying your own exclusion diet. And there's no greater exclusion diet than excluding everything. A 25-year-old woman had complained of abdominal pain, bloating, and diarrhea for a year, and drugs didn't seem to help. But after fasting for 10 days, her symptoms improved considerably and appeared to stay that way at least 18 months later. And it wasn't just subjective improvement, they took biopsies that showed the inflammation go down, directly measured her bowel irritability and stuck expanding balloons and electrodes and erect them to actually measure changes in her sensitivity to pressure and electrical stimulation. Fasting seemed to kind of reboot her gut, but just because it worked for her doesn't mean it works for others. Case reports are most useful when they inspire researchers to put it to the test. Despite research efforts, medical treatment for this condition still unsatisfactory. I mean, we can try to suppress the symptoms with drugs, but what do you do when even that doesn't work? 84 IBS patients, 58 of whom who failed basic treatment, which consisted of pharmacotherapy and brief psychotherapy, 36 of the 58 who were still suffering underwent 10 days of fasting, whereas the other 22 stuck with the basic treatment. And those in the fasting group experienced significant improvements in abdominal pain, diarrhea, loss of appetite, nausea, anxiety, and interference with life in general, which was significantly better than the control group. The researchers concluded that fasting therapy could be useful for treating moderate to severe patients with IBS. Unfortunately, patient allocation was neither blinded nor randomized, so the comparison to the control group doesn't mean much. They were also given IV vitamins B1 and vitamin C, which seems typical of these Japanese fasting trials, even though one wouldn't expect to get vitamin deficiency syndromes, berry barrier, or scurvy to present within just 10 days of fasting. And they were also kept isolated, and maybe that made the psychotherapy work better. It's hard to tease out just the fasting effects. Psychotherapy alone can provide lasting benefits. 101 outpatients with irritable bowel syndrome were randomized to medical treatment, or medical treatment with three months of psychotherapy. After three months, the psychotherapy group did better, and the difference was even more pronounced a year later, a year after the psychotherapy ended. Better at three months, and even better at 15 months. Psychological approaches appear to work about as well as antidepressant drugs for IBS, but the placebo response for IBS is on the order of 40%. And that's whether we're talking about psychological interventions, or drugs, or alternative medicine approaches them. Essentially, nothing, a sugar pill, improves symptoms 40% of the time. So I figure one might as well choose a therapy first that's cheap, safe, simple, and side-effect-free, which extended fasting is most certainly not. But if all else fails, it may be worth exploring under close physician supervision.


Hi, my name is Bethany Kiefer. I work with City Arts as a youth instructor. We partner in the Trees for Life about sharing art lessons that we do with youth students. This is meant for children anywhere from ages four, really to adults, enjoy this project. Sumanagashi is what we're going to learn about today. Sumanagashi is an ancient Japanese art form that was about marbling color, doing transfers with floating ink on water onto paper. Now we have changed that a little bit by using watercolor. We use watercolor and then shaving cream. So I'm going to walk you through how to do this today. First off, a good way for teachers to relate this to students is to talk about their culture, what kinds of traditions that they may use or have grown up with as far as their culture goes. I know I have a Syrian background and through our heritage, ornate tapestries done through fiber art and weaving is a tradition that we have learned. So I'm going to go ahead and continue with the project. If the students don't know about their heritage, please encourage them to talk to relatives to find that out. A good way to relate back to the project. Here are some examples of Sumanagashi after it is dried. This is a kind of end product we would like to have. It's a great project because there's no right or wrong way to do it and I feel like students really enjoy it whether or not they have had practice in it. So materials that we'll need for this project is shaving cream, watercolor, watercolor brush. We're going to actually use the end of that. Paper towels, a tray for us to do the work on to help contain the mess. Paper to do our transfers on. It doesn't matter what kind of paper. You can use computer paper or thicker watercolor paper. And then also some kind of scraper to scrape the excess off. You could use a thick cardboard to do that as well. So we're going to start by putting some shaving cream down on the tray. Don't need a lot. And then I'm going to mix that up with my hand and teachers. You want to help the student get the shaving cream out on the tray but then encourage them to use their hands as a sensory activity to get that moved around. You can use a paper towel to clean off the excess mess. Then we're going to select a watercolor and help the students with this. They only need just a few drops. I'm going to choose a different color. I'll do blue. And I would encourage the students to try a few different colors. I'm going to do purple. Okay, next you're going to take your watercolor brush. We're going to use the end of this. And you use this as kind of like a mixing tool. And we just move it around. You want to cross through as many lines as you can. And you're going to see it's going to start to make a pattern.  And then pick that up as easily as you can. This is what it's going to look like. We'll take our scraper and scrape the excess off. Look at what a cool picture that makes. Look at that pretty marbling it does. The wonderful thing with this is you can just keep reusing it and use many different pieces of paper to make different products. I think the kids will really enjoy it. That's it for today's lesson.