Have you ever wondered how to almost perfectly fake an email? Then you might be actually in the right talk here. We have our next speaker, Andrew, who is currently working for the National Cert of Latvia as a security researcher. And he's going to talk about email counterfeiting and strategies for modern anti-spoofing. The stage is yours. So greetings. I'm Andrew, and I work for Latvian National Cert. One of our current goals is improving the state of email security in our country, which we mostly do through raising awareness about this issue and communicating best practices. And of course, we are not the only organization that is doing that. There are many more sets in other countries, and there are various non-governmental organizations that are doing the same and commercial entities. However, so far, frankly speaking, our collective progress has been quite underwhelming. So for example, here is one stat, which is the usage of one specific technology, DMARC, which, as you will learn in this talk, is quite important, and I hope that everyone will start using it. So on the left, there are 20,000 domains across all the world, which are important domains for important organizations that really should know better. And on the right side, we see top 500 EU retailer domains. And across both of these groups, two thirds haven't even configured DMARC yet. And out of those that have configured, majority hasn't enabled strict policy yet. So if there is just one key takeaway from this talk, I hope that it will be that everyone should start using DMARC. It is important to use it even for domains that are not supposed to send email. So one explanation for these low adoption rates, I think, is that there are seemingly too many competing technologies. This is contents for my talk, and I really tried to do my best to trim it down. But as you can see, there are three abbreviations, well, and SMTP. And out of this SPF, DKIM, and DMARC, actually, two are, I don't even remember the whole name for them. But still, they are all important. And of course, this problem that there are too many buzzwords, too many technologies, and it's not clear which ones we should use, it's not specific to email. And we have this across the industry. And as a security industry, I think by now, we have found at least one way to solve it. And it is penetration testing. So when the penetration test has been run properly and the results have been published, then we can start talking. We can shift the conversation from talking about whether your organization prefers technology A or technology B. We can instead start talking about the questions that really matter, such like, is it possible for someone, for some third party, to spoof your organization's emails and to send such emails to, for example, customers or your partners or media organizations in such a way that they will think that the emails really came from within your organization. So that's why penetration testers have the key audience for this talk. However, I hope that any blue teamers in audience also will find this talk interesting. I'm sure that you already know all the basics about the email and about these technologies. But looking at a problem from the different side, from attackers' perspective, sometimes can really put things into perspective. It can help you understand what you should focus on when protecting your environment. And finally, the SMTP protocol, the technology that runs underneath or email conversations, is actually relatively easy to understand. And also, the lessons learned from all of this journey from SMTP, how it became, and how it's possible to spoof it, and all the technologies that are trying to prevent spoofing. I think it's an interesting case study, and it should be interesting to follow even for people who are new to email. Finally, threat landscape. So email security is quite a wide topic. And so today, I will only focus on one small part of it, which is successful spoofing of emails, tampering attacks. And I know that many penetration testers already incorporate some part of phishing or spear phishing simulation into their engagements. But as far as I know, they mostly do it from the social engineering perspective, using such tools as social engineering tool kit, for example. And I don't want to argue that it's important to do that and to demonstrate to the customer that what risks are in regards with social engineering. However, I think you're doing the service to the customer if that's the only thing that you are testing from the email perspective. Because from the customers, from managers, for example, perspective that are reading your reports, if they only mention social engineering attacks, then the logical conclusion is that the best way to mitigate these threats is by educating your personnel, especially those that are least technical. As you will see in this talk, there are quite a lot of attacks and many organizations are susceptible to them, which are much better than that. And no amount of user education will help here, because we can't expect users to check headers, for example, manually. So we actually need to improve our email infrastructure nowhere around it. And finally, before we move on to actual technical stuff, there's a little secret which I think might help people that are not working in the email industry understand why we have such problems. And it's that for email admins historically, they value availability of their system and reliability much more than security. And that's because that's not an ideological decision. It's a very pragmatic one. So for example, if you are an email admin in an organization and some of your customers stop receiving invoices, your management will find you and will inform you about it and will ask you really nicely to fix it as soon as possible, even if it's not your fault. If it might happen that the problem is on the other side of email, not on your server. And for example, if some of your employees can't receive email soon enough, for example, to restore the password or to verify the email or to use the multi-factor authentication token and they can't log into some important systems, again, they will find you and you will need to solve that. But if your system has some security vulnerabilities, if it's susceptible to spoofing attacks and so on, then not users nor management will normally notice it. You might not notice it, but you have this vulnerability. So that's why, obviously, penetration testers are important. OK, now we can finally start talking about the technical stuff. So and we will start with a short introduction to SMTP protocol. SMTP is the protocol that underlies all email communications. And it's actually pretty easy to follow. So here's a data flow of what's happening when one person sends email to another person. For example, Alice is sending to Bob and they are working for different companies. They use different domains. So what's happening here is that both of them, let's say, use email clients, such as Outlook or Thunderbird. And Alice is sending email. It's going through this protocol, SMTP, to Alice's mail server. But the important to note is that this is an outgoing email server. Usually, organizations will have two types of servers, one for incoming transactions and one for outgoing. And for smaller organizations, it might be one server. But again, it's important for penetration testers to think of this as different systems because they will have, even if it's physically one machine, it will have different configuration for outgoing mail and for incoming mail. So as a penetration tester, you need to check both of them. OK, now when Alice's server tries to send email to Bob's server, there's sort of a problem in that the server needs to somehow automatically find what is the right server to send email. And it is done through this blue box, Mx, which is a specific DNS record type, Mx. So that's something that is maintained by Bob's organization. So Bob's organization, if they want to receive email, they create this DNS record. And they say that, OK, if you want to send email to us, please use this particular server. So it should point to Bob's server. And now Alice's outgoing server, knowing Bob's incoming server address can communicate to that. And then later, Bob will receive its email. So the part that we as penetration testers will be trying to breach is actually between this between Alice's server and between Bob's server. And then we need to think about the second example, which is the opposite way. And you might think that it's a pointless example because we are just basically changing the direction of traffic. But the important part here is for us as penetration testers to understand that our client only controls part of this transaction. If our client, let's say, for the rest of this presentation, is Alice, or Alice's organization, then in the second example, when we are sending mail from Bob to Alice, then we'll be sending emails only, basically, part of this transaction will go through Alice's servers. And the first example, if we were sending email from Alice to Bob, it wouldn't be so. So if it's a bit confusing, that's OK. We will return to that a bit later. And finally, there is a third example, which looks similar, but not quite. And that's if Alice is communicating. Alice is our customer. And if she is communicating with her coworkers, which are using the same organization, same email servers, same domain, in that example, again, there will be two, at least logically, two email servers, outgoing server and incoming server. But both of them will belong to our customer. So right now, if you are not familiar with email, you can, it's interesting to try to think which of these scenarios, three scenarios, which of them are easier to protect. And a bit later, we will see how it's actually happening. OK, and then we need to look at what actually is being sent when email is being sent. So again, it's using SMTP protocol, and it's a really nice protocol. As you can see, it's just text. So it's plain text protocol. And it's very easy to play around because you can just open a Telnet connection to a write server, and you can try writing down the commands just with your hands. So you can try mangling something, or modifying, or trying different types, and see in real time how it's going on. So on the left side, we see here two parts, which are defined by SMTP. So first of all, there comes SMTP envelope, which is basically you connect the server, say hello, then you specify the sender of email and recipient. Mail from his sender, recipient is Bob, for example. And then the second part starts with data and ends with quit. And that's the part, which is called content message. So just if you want to play around with this a bit more, this is defined by a different standard, which is not that important for penetration testers. But if you want to look into details, it might be important. And this internal message, which is called either content or SMTP message, again, it contains two parts. One is headers, and another is body. And I think some people might not be familiar with email, but probably everyone is familiar in this audience with HTTP, and this looks quite the same. So easy to understand. But the interesting part here is that you might have noticed that we have Alice's and Bob's addresses twice, right? For example, Alice is specified on the second line, mail from. And then we have the same address, Alice at her organization, in from header, dread ones are the headers. So and the same goes for Bob. So why is that? Well, it comes down to how we see email. I, as a, I think, normal, regular person who has used email in past quite a lot, I usually see them as described on the left side, which is sort of postcard. So on the postcard, there is someone who has sent it, the sender, there's recipient, that's usually me, I'm receiving, and then there's some message. So at least that's how I perceived it before I learned a bit more about it. But email admins and the standard bodies, they see this situation as the one which is shown on the right, which is there is an envelope and inside the envelope then there is this message or a postcard maybe. So you have two addresses in this scenario. You specify the address from and to whom you are sending the envelope, which is the part that post office, for example, will look. But post office won't look generally inside your envelope. And inside the envelope there is another message and that internal message is actually meant for recipient. So actually you could do even more and you could even put the whole envelope with the message or with the postcard inside another envelope. And this sounds crazy to me as a, I think, regular person, but actually email allows that. And in the RFC, in the standard document, there are some examples why that would be necessary, why such things are allowed, but they are confusing. And so as a result, it is that here in this first example we see that we generally, we are specifying the same address twice. But as a penetration testers, the question that we should be asking is, so is that required actually? Is that always true or is it just like wishful thinking? And it's actually wishful thinking. So standards specifically do not say that you should be specifying the same address for a recipient or from the sender on envelope and inside the message. So you could actually tweak them and send different stuff. So actually, there are much more headers than what I showed. The ones I showed, I think, are just the ones that we all have experienced, because if you are just using email, that's usually the stuff that you see.  And there might be, of course, more recipients. And, oh yeah, and another question is, which one's actually, if we have specified for some reason, by accident or especially, if we have specified different addresses in this envelope, in the message, which one the user will see, the recipient. And it's actually the headers. So inside, the message is the one which is intended for a user. Okay, so, and as I was saying, there are actually standards allow a bit more headers and there are actually three headers from send and reply to, which are semantically really close. And in the standard, it's actually explained when you should be using which one and the funny thing for me is that, for example, from header, which is usually the one that we see, it might contain, by reading the RFC, you will see that you shouldn't have more than one such header, but the header itself might contain multiple addresses. Personally, I've never received an email which would come from different people, but that's allowed. But the important thing to understand here, again, is the backwards compatibility that I mentioned before. So even though standards explain how you should use the issue header and that you shouldn't have more than one of each of these headers, in practice, actually you can send malformed email. You could send email with multiple headers, the same header from header multiple times. Or you could send header, which does not contain from, but contains sender. According to RFC, that's incorrect, but in practice, it will work. Most organizations, most email servers will try their best to parse your completely malformed email because they really are concerned about lowering the support cost. So if something does not work, then you will come to them, so it's better to make that everything is working most of the time. Of course, for penetration testers, that means that you can play around with this because there are different implementations and it's exactly which header, for example, if you have two headers, will be shown or will be used for some algorithm, it depends on the particular implementation. So because there are so many implementations that are interconnected in different ways, you could and you should, as a penetration tester, try various things, for example, add the same header multiple times. Okay, now that we have covered these basics, let's actually look into how you would try to spoof an email, for example. Yeah, and here we again, we are coming back to these diagrams that we've seen before and, for example, in the first example, well, Alice is sending email to Bob. Let's say we are Chuck, so we are the third party, we are penetration tester, licensed, we have an arrangement that we are allowed to do this and we are trying to send spoofed email to Bob and in this example, we are trying to spoof Alice's message. So our intention is that once Bob receives email, it should look to them, to the Bob, that email was sent by Alice. So risk for this, okay, I will not cover the risk, I think you can imagine that, so for example, you could do fake news is one of the problem that we have seen in Latvia, it's one, this was used against government bodies and when someone sent fake news email to other people, organizations and so on and we're trying to impersonate some government person. And of course, you could imagine yourself how it's not a good thing if it's possible. But the interesting thing here is that even though Chuck is doing attack, it depends on your perspective, it might look like attack on Alice or on Bob, but in this case, email won't go through Alice's systems. As you can see, Chuck is sending email to directly to Bob's incoming server. Now there's second type of attack that we looked at. If we are sending email in other direction from Bob to Alice, and our customer is Alice, so we are testing Alice's server. And in this case, we are trying, again, we are Chuck, we are sending email, in this case, email will go through Alice's systems. So interesting question is, which is easier to protect. It might seem that since in the second example, email is actually going through Alice's systems, it means that Alice has more power to do something, to do some additional checks on balances and so on. But actually, as you will see in the future, it's easier to protect the first example. So even though our customer is Alice, we are trying to protect Alice, but it's easier to protect in practice. This example where someone is sending email, trying to impersonate Alice. Okay, oh yeah, and then there's the third example, which is if Alice is communicating with her colleagues inside the same organization, again, we are Chuck. In this case, again, we will only send email to Alice's incoming server, not to outgoing server, right? So important thing to note, and again, in principle, this third example is the easiest to notice because Alice's organization presumably knows that her emails always should come from this particular outgoing server, right? Like if we are sending email from Alice's colleague, then incoming server in principle should have all the power even without any standards and stuff like that. But in practice, sometimes, actually quite often, there will be a specific whitelist for Alice's own organization. So some checks won't happen if incoming server for Alice is receiving email, which is coming from, again, Alice. And by the way, there's this example. We've seen that for the past few years. I think it's not specific to Latvia. So here, for example, it's Canadian address, if you can see, and these are these emails which are fake, like ransomware stuff.  So these emails, interesting part about these emails is that they are usually, in order to prove to you that they have access to your email account, they are sending email from your address to your address. So, and for many people, that works. So they see that someone has hacked their account, obviously, because they received email from themselves. So as you will see a bit later, it's actually easy to spoof such emails if they haven't been, any protections haven't been put in place. So the important thing, I hope that no one in this audience is falling for such scam, but if you have some friends or colleagues that have contacted you and told you about such emails that they have received, that one of the things, besides checking the passwords, starting using multi-factor notifications on, is just maybe you could tell them that they should contact their email administrators or IT team and ask them about anti-spoofing protection, because obviously, if they are able to receive such email and it's not filtered, something is wrong. Okay, and now let's see a spoofed SMTP conversation. So that's an example similar to previous one, but in this, now we are actually Chuck. So this is sent by Chuck to Bob, but we are pretending to be Alice. The question is, can you see the difference, how this is different from the previous one? And it's hard to see the difference because there's none difference. That's the same conversation. So the point here is that SMTP protocol by itself, it actually doesn't have any protection. So yeah, you could just, for example, if you are that guy that is sending the fake ransomware letters, you can just write down this text and just dump it to Telnet and it will work for many organizations, not for all. And of course, email admins know this stuff, know that SMTP is not very reliable in this regard that it's easy to spoof and so on. And there have been many attempts to add some protection just like ad hoc way. So no standards just run some, add some additional filters and stuff into your own mail. And some of these protections actually break RFC, if you read it, but who cares? Like RFC is not a sacred text, so it's absolutely approve this, for example. So yeah, go on. But the problem is that there is not enough information. So if you think back here, if we are Bob and we are trying to protect our systems, so we are Bob's system administrator probably or Bob is a system admin, and we are trying to add some additional rules and stuff, then what actually can we do? So one example that I listed here is doing this SMTP callback. And that means that we are just, when we receive email from Alice, we actually check, does that email exist at all? Because many spammers, what they will do, they will just send email from non-existing emails and it will work by, if you are just running your own SMTP server. So SMTP callback is basically you are, when you are receiving email from, for example, Alice, you are trying, you are running, spawning a separate process, which will try to connect back to Alice's server and it will try to send email here. If a server says that, yeah, that's okay, such email exists and so on, you are not, you actually stop the conversation, you don't continue with sending email, but then your system can automatically find that actually this email really exists. So another way to do this is through checking this hello, hello, and this is the first line and the first line, normally it should tell you the host name of the server that is sending email. Interesting part, so according to RFC again, you shouldn't check it and you shouldn't verify and if it doesn't, if it's random string, you should accept email still. But what many servers will do is, they will try to verify that first of all, this host name, which you are telling that you are this host name, first of all that it really points to the same IP address and then they do the opposite. So they will take IP address and try to run reverse DNS, PTR query and they will try to find whether that IP address really responds to this host name. So again, as a penetration testers, we should be aware of these protections, ad hoc protections, because they are, if you don't know about them, you will try running something and it won't work for you. But they are easy, if you are aware of them and if you have identified that this organization uses them, they are easy to bypass. So they don't offer a good protection, they are meant to protect from mass abuse from spam. Okay, so SMTP as we've seen by itself does not offer any protection. So which additions to the protocol actually can be used to protect ourselves. One of such protocols is SPF and what SPF does is it's trying to be like mirror Emix system, Emix system is the one which basically Alice can use to, Alice's server can use to automatically find the server that belongs to Bob and it's incoming server. So SPF is the opposite of that. So that's idea is here to run the system automatically on the Bob's incoming server. And now when Bob receives the email, they can run again DNS query and they can find what IP addresses actually should belong to Alice's outgoing server, right? So it's, I think it's easy to understand, it's actually a meaningful way, it sounds meaningful. Addition. And yeah, and the one field that is checked in this example is this envelope sender. Okay, and here's an example of a minimal SPF syntax and as we can see it's, I think it's easy to understand even if you don't know the syntax, it lists IP address which should be IP address of outgoing server, legitimate outgoing server and then it says that's minus all which again is easy to understand. In this case it means that that's the only one. So if you receive a message message comes from this IP address, that's cool. I accept it, if it's something else then just drop it. And there are multiple ways to specify the IP address, you could just specify the IP address, you could specify IP subnet, you could specify DNS hostname. So it's just for admins, basically for penetration testers doesn't do much difference. For admins it's just easier to maintain these systems. And then there are these qualifiers. Qualifiers is something which you put before the methods. For example, here in this example IPv4 doesn't have any qualifier, there's no plus or minus or something. That's because plus is assumed by default. So by default everything that is listed in SPF record will, should match some legitimate SMTP server, outgoing server. However, there are other options you could use minus which is fail. And that means if something matches, this record for example minus all is the one which is the most often used. It means if it matches this one, so that's the usual with the last one, then please drop the mail. It's not real, it's fake mail. And then there's this third option which is soft fail. And that's meant for testing period. So when you are just starting to implement SPF there might be some, so the problem is that you might forget for example, to add some SMTP servers. So because you haven't done that before, maybe you think you have only one SMTP, actually outgoing server, but in fact you have multiple of them, multiple ways to send email. So in that case, if you were to start set the SPF record with fail, strong policy, then your users won't be able to send a message anymore. So that's why testing is good. However, yeah, and here are some other examples that are a bit more complicated. One of them is with include. So instead of defining the policy yourself, because you are using third party, for example, Google in this example, then you will just include whatever Google has published. And the interesting thing is this usage of SPF. If we just look at the amount of domains that have defined some sort of policy, then the number looks pretty okay, I guess. It's for example, for most popular domains, that's around 70%. But the problem is that majority of them are either poorly configured or they just use the softfail option. And what softfail practically does is nothing. You still can, even if there's policy with softfail, you can, in most cases, you can spoof your email and it will still go because the recipient side will think that it's just in the testing mode. You shouldn't drop email automatically. Yeah, so actually the percentage isn't that great. However, the most important thing for us as a penetration testers is to understand, so what do we do when we see this SPF? That means that now we can't spoof mail. And no, it does not that it's game over for us. We can do some stuff. So first of all is this softfail that I mentioned.  So if we as a penetration testers will try spoofing from some unknown IP address that hasn't been listed in the previous rules, then do nothing. Do nothing, I mean, don't drop email. That's good for us, right? That means that we can actually spoof just in the same old way and it will mostly go. So the one note here is that some systems are not using just this binary classification, whether something is good or bad, they are trying to run some scoring. And then it might be that even if you have this softfail, they won't automatically drop your email, but maybe they will add some suspicious level to it. But the important thing is that it's not automatically game over. Another thing is this include. So include is very convenient when you're using third parties. But the problem is that it's not what it sounds. To some people, at least even in the standard, it mentions that it was poorly chosen name. And the reason for that is that it's not a macro. So to understand what's happening when this include is, you shouldn't just copy paste everything from inside recursively to the top level. It's not how it works. It will try running all the checks inside this include. But then if it fails, it won't automatically drop the message. It will go to the one level top, and it will try running the other rules. So the problems with that is that two cases that are the most common is either if you just forget to add this minus whole to your system administrator has forgotten to do that. And in that case, even if the include has minus all, it won't work. Because when the recipient will be checking it, minus all inside include does not mean the same as it does on the top level. And the second would be if they have added all, but it's soft fail all. And some admins might think that, but that's OK, because I'm including Gmail, and Gmail has this hard fail. Doesn't work that way. And then one which actually is, I think, maybe the most common case is that often you actually see this type of SPF records where there is lots of stuff inside. There is IP addresses. There are these air records. There is a mix. There is a pointer. Basically everything that admins could think of. And the reason is that most commonly, they are just not sure how it works. They are not sure what they should put inside. So for example, one thing that points that out is if there is a mix record inside the SPF. Most commonly, most organizations, unless they are very small and just have one server, they will have different servers, different IP addresses for outgoing mail and for incoming mail. That means there is no practical, for these organizations, there is no practical reason to include the mix into SPF because no mail should go out through their incoming mail server. And another case might be that admins understand how it works. But it's really truly their architecture is really messy and they are sending mails from many, many different points, which is good for penetration testers. That means that they're not well organized. And then there is another flaw, which is that granularity isn't very well suited. So the only thing you can do, there are multiple record types. But all they do basically are resolved to IP address. But as you can imagine, in many cases, IP is not linked just to a mail server. So on one IP, there might be mail server and web server or database or something else. And that means that as a penetration tester, you can exploit this something else, not mail server itself. Because mail server usually is pretty low key. There's not many vulnerabilities there. You just patch them and that's it. But those other systems, for example, web, it's easy to exploit in most cases. So then you can elevate, in some sort of privilege, by gaining access through some other server on that IP address or IP range. You can start sending mails and they will pass all SPF filters. OK, so one example is shared hosting, which is the very common case. And the problem with shared hosting is that in this case, OK, you have IP address of SMTP server. Maybe that's server only used for sending mails. But the server itself works not just for you. It works for many domains, maybe hundreds or thousand domains. That means as an attacker again, you can exploit at least one of them. Or for shared hosting, you can just buy. You can become a customer of that shared hosting. You don't even need to exploit anything. And then you can potentially start sending mail, which will look as far as SPF is concerned, just like the real one. And another one is this checking run identifier. And this is probably the worst problem with SPF. It is that, as I mentioned before, there are at least two identifiers, typically envelope sender, the outer one, which lists the sender. And then there's internal one, which is usually from header. But out of those two, SPF only checks, if SPF is the only technology that you are using, SPF only checks the first one, envelope sender. And as I mentioned, in most cases, actual users that will receive the mail, they won't see envelope sender. They will see this other one from, for example, or one of the other headers that I mentioned. So this behavior is fixed actually by DMARC, which is the technology that I mentioned. But majority of SPF installations, domains that are using SPF do not have DMARC. So they are not protected by this. So even if the SPF is completely great for attacker, it means that you only need to, what you need to do to pass SPF is to set envelope sender to something else. For example, your own controlled address, which will pass all SPF checks. But then inside the from, you can show the header that will match this organization that you want to pretend to be. Okay, so then there is another technology which is supposed to fix this, and it's de-kim. As we have seen, SPF is not enough. So de-kim, sorry, the wrong letters, but yeah, domain key is an identified mail. That's the de-kim, and you don't need to remember the long name, just the short name. And what it does, basically it uses cryptography, which is nice, right? It's math, it's hard to break for attackers. And what it does is it signs every mail. So every mail that is going out through the de-kim enabled server will get signature, which you can, as a recipient, you can cryptographically verify. So as you can see, how it looks is actually pretty hard to see because it's not meant to be processed by humans. It's cryptography, it's meant to be processed by computers. But the important part here is basically the yellow stuff is the cryptographic signature. But the green part is what's called domain identifier. And the red part is what's called, I don't remember how it's called. But basically it's an idea that you can have multiple keys for your organization. For example, your organization might be sending mails from your original SMTP server, then you might have a backup one, or you might be sending some messages from Google or some marketing companion and so on. And then each of them might have different red, this parameter. The problem is, and then recipient will need to run DNS query, which is the second example using this combination of green and red one. And then they will get the public key. And they can use this public key to verify the signature. So it sounds really nice. The problem here is, no, not a problem yet. So how to use it? I think it's easy if you understand the public cryptography. So on the center side, you need to first generate public and private key pair. Then you publish the public part in the DNS. Then you use private key to sign each message. Now recipient does sort of the opposite. They, once they receive the email, they figure out through this red and green part, they figure out the correct DNS record to run, run it, get the public key, and then compare whether this public key corresponds to the signature. So it sounds really nice, right? What's the problem? So customers, yeah, selectors, that's the name. So the problem with that is that the selectors, there might be multiple selectors. As a DKIM when you are doing configuration, you can select as many custom selectors as you want. And the recipient doesn't know whether you actually should have used a selector and what selector you should have used. So the problem is that while, if we are talking just about the vanilla DKIM, modifying existing signature is hard for penetration tester or for an attacker. But it's easy to just remove it because if you have removed DKIM at all, the recipient doesn't know that it should have been there because in order to check, they need to, so here for example, in order to check the signature, I need to know this green part and this domain identifier and the selector, which are part of this header, right? So that's a huge problem. And that means that, yeah, that means that we can actually, while we can spoof DKIM itself, we can just trim DKIM, send the message without it and if the DKIM was the only thing which protected this system, it will work. So it might not get the green check mark or whatever, but it will get to the recipient. So and another thing is this domain selector, why do we even need to set that? Because the best practices of course is that you have envelope sender equal to from header equal to this DKIM domain selector, right? So if I'm sending from Alice, then all three should be Alice.org or whatever. The problem is that it's not mentioned in RFC, that that should be the case. So what exactly happens when it's not that way? For example, on the right side, there's some real domain which was using Gmail, Google apps, Google suit. And in that case, the default, by default, Google suit will sign all messages. But if you do not do your own configuration, it will sign them with the domain it controls, which is this gap, send some TP. And what it means is that although technically something has been signed with DKIM, it wasn't signed in the way that you can trace back to your organization, it's something completely else. What exactly recipient should do in that case? Should they just ignore it? Should they reject the message or something? So the correct way would be not to reject it, but to just consider it not valid, at least not a valid DKIM. But it actually depends. So some validators will just see any DKIM, will validate it and will say that's cool, that matches the RFC. So, but now the interesting part, modifying DKIM, which I don't have time for, but the idea is that in some cases, this is not always, but sometimes you actually can modify. The easiest part to modify in the messages are headers. Because DKIM, since it's placed in headers itself, it does not automatically sign all the headers. It's like chicken and egg problem. So by default, it only signs one or two headers. And you can specify more headers that need to be signed, but it doesn't happen automatically. So the easy part for attacker is to add another header. If that somehow helps you in your plan, then that's easy to do. You just add another header. An interesting part is, although the RFC, as I mentioned before, mentions that some headers, such as subject or from, should only be present in one copy. Actually, you could add more than one, for example, from header. And what happens in that case is pretty interesting. DKIM will match, if you have told to DKIM, that from header should be, for example, signed, that it will match and sign first from header from the bottom. But quite a lot of email software, email clients, will actually only display to the user first from the other side, from the upside. So what it means is that attacker can mangle or overwrite headers by just adding new headers to the top. And this actually problem is mentioned in the DKIM RFC and the protection that they propose is this code of assigning, so you can go and read the RFC, but not everyone is doing that actually. And however, that only goes to the headers. So sometimes that is good, sometimes that's not good. Modifying message body is actually much harder to do. Basically, the naive way we do through the cryptography, which we don't want to do. And another way is through this one parameter, which is body length. And that's actually questionable functionality that DKIM has. Sometimes you can specify that the hash, for signing purposes, we shouldn't consider it a whole body, but only first something bytes. So that's actually useful in some cases regarding with mailing list, but for the most part, that's not useful. And in practice, most email software does not do this. If it does, then it is susceptible to potentially to this overwriting body as well. You could add another MIME type and then modify headers to show that different MIME type. And it will pass the DKIM. So in this case, it actually will show, for example, the green button or whatever, because the DKIM will be valid. So now there's the third technology, which is called DMARC. And again, there's the full name, which is long, but in this case, actually, it means something. There are two key words, reporting and conformance. Reporting is the one which most admins are familiar with because that's how DMARC, I think, often is being sold to them. Reporting means that when you have some problems, in this case, you actually get to tell other side what to do in that case. So basically, you tell them to send you reports, either once per day or every time and so on. So for penetration testers, it's not that useful. Potentially, we could use that to understand what sort of configuration is running on the other side. But currently, this functionality actually is not that widely implemented. However, the other part, conformance, it's actually really, really, really powerful. What it does is it corrects these major flows that I mentioned in SPF and DKIM. So first of all, DKIM had this massive problem that if you just strip down the header, then the recipient has no way of knowing whether there should have been DKIM in first place. If you are using DKIM alongside with DMARC, that fixes the problem because DMARC specifies just that you have DMARC itself, it means that you automatically, at least one of the SPF or DKIM should pass. So automatically, DKIM's major problem is solved. The other thing that changes is the semantics for SPF. Now, SPF, if you have both SPF and DMARC, it means that SPF should be checked against from header. And as I mentioned, that was the major flow with SPF because if you are using SPF itself, even with the hard fail mode and so on, it means that attackers can modify from header still and the recipient won't know any better. So, a minimal example of DMARC is really, really small. And I think it's easy to understand. You have just, it's a DMARC, it's reject. You need to like find out the right place to specify but it's easy. And all you have to do is create this one DNS record. And the benefit for that is even if you don't have DKIM and DMARC, if you have created, sorry, if you don't have SPF and DKIM, but you have created DMARC, effectively what it means is that this domain should not send any mail because for recipient to consider a mail valid, at least SPF or DKIM should be valid as well. If they are not, then they can be valid. So in fact, what it means is that most domains how they should consider enabling DMARC. That's just the right thing to do. Okay, so there are more tags. So in the wild, these DMARC records might be much longer but it's not of much use to penetration testers. So important part that here's again, is this policy which can be three values, none, quarantine and reject. And if it is a quarantine, that means if there's a failure, the message should go to the spam folder. If it's reject, it should be rejected or tried. And if it's none, it means it's in testing mode. So, and this is the picture that I showed in before which shows that actually, even though DMARC is really like the best technology out of these three, it's not really widely used. Unfortunately for defenders, quite a nice fact for all penetration testers out there. That means that you can in fact spoof most of the mail out there. Okay, so how do we work around it? Sorry. So what happens if actually someone has implemented DMARC? Does that mean that now penetration testers can do anything? You don't even need to do any research? No, it doesn't. So in practice, if someone has implemented both DMARC and DMARC, but not SPF, so they have only two of them. That's a really cool combination. Digim is pretty powerful and the major flow that it had, DMARC solves. So this combination is really cool in theory. In practice, the problem is that in order to protect your own mails, the recipient side should validate both Digim and DMARC. And unfortunately, quite a lot of software still does not do that. One such software is Microsoft Exchange. And even if you are not running Microsoft Exchange, chances are good that some of the partners that you are communicating with are running Microsoft Exchange. And by default, it doesn't have any functionality to parse Digim. So in fact, most systems still need to enable SPF just for practical purposes, which is good for penetration testers because if SPF and DMARC are enabled by default together, then again, that fixes one of the major problems with SPF, but it does not automatically fix other problems because there's not enough granularity and potential for misconfiguration. So, and the interesting fact is that DMARC only requires that one of the other technologies, SPF or Digim, is passed in order to consider email valid. There's no way in DMARC, even though there are many other selectors, there's no way to specify that both of them should be valid or that Digim should be preferred to SPF. In practice, what it means is that for most systems that enable all three of them, which is a good practical solution. From penetration testers side, we can just ignore Digim outright and just focus on SPF because SPF is the weakest link in this situation. Okay, so just a minute for recap. I'm not sure if I have any more time. Not many time I have. Okay, so, sorry. Yeah, and so one really important note is when you are testing the systems, consider both scenarios. So don't focus just on send, if you are, for example, testing Alice, Alice is the organization that is your customer, don't just focus on testing email sent impersonating Alice, but also test the other side. Because in this, here you can see that it's easy to implement, for example, SPF and DMARC because for both of them, you only need the Alice configuration, just one record per each. However, actually testing them, like validating them properly, is harder. For the first, you need software support and you need to configure it correctly as well. So in practice, it might be that many of organizations that have enabled DMARC or SPF on the DNS side for outgoing males, they are not actually properly validating it. Yeah, okay. Sorry, I don't have time for that. So, probably that's it. Sorry, maybe some questions. Thanks, Andrew, for this nice talk. Sure, we have time for a couple of questions. So there I already see one person, microphone number two. Hi, thanks a lot. Do you know some good tools to monitor DMARC reports that I get sent by my recipients? Yeah, so this is a really good question. We, as I said, we are really suggesting everyone to enable this tool. But unfortunately, as far as I know, all the tools that are popular on the internet, they are collecting some data on you. So they are using it for marketing purposes. So they are not very good for privacy if you're concerned about that. So you need to implement something yourself or you need to start some open source project, maybe. Okay, microphone number one, please. Thank you for the good talk. Me myself, I would consider myself a male administrator. I sometimes get advice to shorten your SPF record because if it's too long, it gets dropped anyway. For that, I sometimes get advice to drop the PTR record. But in your talk, you say the PTR record is useful for reverse DNS checking, which I find very useful as well. How are you about shortening your SPF and how are you about the PTR record in general? Well, it really depends on your particular use case. So it might be the case that some organizations really need this long SPF and there's no way around it. You could do, what you could do is include this, include, use includes because they are not macros so they won't get expanded. They do not, like your record doesn't become longer if you include, use many includes. But the problem which I would suggest to you is actually reconsider whether it's really, whether you'd really need that many records if it's too long because the very common problem is that unless you are Google or something like that, you don't really need that long SPF. It's probably some problem with, yeah, so it's probably an error for most organizations. Okay, well, very, just briefly, number one, though. On the PTR record, I heard that it's dropped, not dropped on the standards, but it's not in the standards. It is in the standard, yeah. No, PTR record by itself, if it's really your use case, I don't, I'm not aware that it would be automatically dropped somewhere. But that shouldn't be a problem. Okay, we have a couple of more questions here. So number six in the very, very back. Yeah, thank you for your talk. That's not directly related, but even on the other side should relate it. If a mail server accepts because de-kim, de-mark and SPF, everything is fine, but especially Google for a lot of organizations, the mail is delivered, but classified as spam, it means on the inbox of the recipient, it's not displayed. Have you a solution to solve this problem against Google? Yeah, okay, so I have like different opinions about that because one thing which actually enables, which we actually should be like telling, thank you Google, is that they are so strict because that's the only reason that we even have, this is high percentage of even improperly configured SPF. The only reason there are 70% websites are using SPF is because they need to communicate with Google and Google won't accept your mail if it doesn't have even SPF on the baseline. So I actually, I enjoy as a job that I do, I would prefer that Google does what it does, but I understand the real admins which have this problem. Google has the tool, you probably know about it, where you can check what it considers about your domain. So you need to consider this problem on case by case basis. Quite often what happens is that even though you have this decim, demarc and so on, it's not configured correctly. So that's what the talk was about. So you have it, you probably think that you have configured it correctly, but there are some errors. Okay, let's give priority to the internet. We have one question from the internet. When attempting to verify an address, how to handle no reply email addresses? No reply, sorry? Can you read it again please? When you're attempting to verify an address, how to handle no reply email addresses? Maybe it was about no reply header or not existing? I appeared addresses. How to handle email, no reply email addresses? I will try to get the answer how I understand it. So what often happens is that, what often happens is that email will be sent from non-existing addresses. So maybe that's what the question was. For example, there's no reply and it's not the problem itself, no reply. The problem is that it's not a real address. There's no such address, right? And so I don't have an answer for that. Because according to IRC, you should still accept it. Practically, as I said, lots of mail systems already are dropping these addresses. If you're sending from non-existing, unless you are Google something large, so you have been put into a white list, you just won't be able to do that. You won't be able to send email from non-existing address. So if that's your situation, create the address. Make it like, remove all the email that comes there, but create the real address so that you are acceptable. If you are on the other side, so you are receiving this email, it depends on this particular use case. So just check what's going on. If you can contact them, contact them. If you can't contact them, then you should decide what is the risk if you are dropping these addresses. Are they important for you? So according to IRC, you should receive. And process these addresses. Okay, microphone number four, please. Hey, thank you for this talk. Do you know about effort to solve problems with big email centers like online books, sellers, which are very great? Because they don't seem to have their own SPF records, for example, in control. So in many cases, you can't just contact them. So it's just the question that they haven't thought about it or maybe no one told them what to do or maybe they don't know how to do better. So that's one of the part that we, as a SERT, we are doing. If you have some, this problem with some large company, in particular country, I would suggest to contact SERT even if it's not a governmental organization. For example, in Latvia, if that would be a Latvian company, we would do the triage. We would try to talk to them, explain to them why they need to change and so on. So that's maybe one option for you. But the practice is that if something looks to you as a third party, as a wrong configuration, that is one I couldn't mention in this talk. If something isn't perfectly secure, it doesn't mean that it's wrong. There might be actually business case why it should be this way, right? Because for example, if it's a large, I don't know, Amazon or something like that, and if they have tested and they know that when they enable very strict configuration, some percentage of their emails just doesn't come. Not because of their problem, because of someone else's problem, right? But then there's actually real business case that they are not, it would be stupid for them to enable this too strict configuration, knowing that it will damage their business. That makes sense, right? Okay, we are unfortunately running out of time. For those who are on the microphones, please just line up with the speaker next to the desk. He's gonna talk to you perfectly sure. And...


A compact heterojunction consisting of half-metallic C, Cn, 3, HmCn, hydrothermally embedded in Biobr, Biob, as the backbone enhances charge separation in semiconductor photocatalysts for efficient artificial photosynthesis, resulting in a larger electron transfer rate and increased photocatolitic C02 conversion efficiency. This article was authored by Xinhuang Xu, Hengmen Su, Jin Yuan Lu, and others.


I'm here at the CHP Academy in West Sacramento, where a new class of cadets is on their way to becoming officers. But before they can accept their new roles, they must first endure intense coursework, rigorous physical training, and let's not forget driver's education. But this isn't your high school driver's ed course. This is the CHP's Emergency Vehicle Operations course. The importance of the training is simple. No matter how far you go up in rank, the first thing you do is drive. This high-intensity maneuver teaches these cadets how to keep control of their vehicle on wet road conditions. Mastering this is a must to becoming a CHP officer. When we first get in there, it's very stressful, and you learn how to manage that stress through breathing, through just focusing, doing the techniques correctly. Not only do these cadets learn how to maintain command of their vehicle, they practice identifying the sounds of gunfire while driving, and other highly spill performance techniques. EVOC is certainly challenging. There's more to the training than just emergency vehicle operations. Cadets also must complete weapons and firearms training, arrest techniques, and undergo grueling physical fitness challenges. It's 28 weeks of very physical, mentally taxing, and demanding training. And so we look for people that have the ability to sort of, you know, move through that at all phases of training. We also have an air operations program, motorcycle enforcement, we have bicycle enforcement, equestrian enforcement, so canines, all these different things you have an opportunity to be able to go into. As you can see, becoming a CHP officer is not an easy task. Not only do these fine men and women keep our highways safe, but they are at times the first responders when disaster strikes. The California Highway Patrol has a very specific function, but at the same time we rely on the resources that are provided to us by our allied agency partners. The fire agencies that we work with and the Office of Emergency Services, all of those agencies play a part in our first responder role in providing this safety and security to the public. So as you can see, these cadets have some challenges ahead of them. And we want to wish these first responders all the best on their new endeavors as they serve and protect the citizens of California. For more information visit www.chpcareers.com.


So, I met Ms. Cleco probably in the beginning of 2017. She had just recently completed breastfeeding her most recent child. She noticed a new left breast mass that she had noticed before. After I went and saw my doctor, she recommended that I go get a mammogram for the first time. The doctor immediately sent me in to get an ultrasound as well. I was getting an ultrasound for almost an hour before the doctor came in and she said to me, you know, she's like, obviously there's something wrong. We scheduled a biopsy for the following Monday and I could just tell by the urgency of the nature of them scheduling it and the speed at which they got the test results back that, you know, the doctor felt that it was something pretty serious. It was a little bit of a timeframe, probably about a week or so, that it was sitting on. It's like weighing on her chest. It revealed that I had stage 2 breast cancer called invasive ductal carcinoma. I had triple positive cancer as well. My relationship with the doctors in New York, of course, are through the New York Jets. Ken Montgomery's wife, Leslie, is probably one of the most renowned experts on breast cancer. I know Ken. He is one of the orthopedic doctors at the New York Jets. I expressed to him, you know, that this had to happen quickly if we could and he said, got it Joe. He basically hung up the phone, called Leslie's office and Leslie's office I think within that day called Billy. She already had had a biopsy of the breast cancerous mass and we also were able to identify that the cancer had already spread to her lymph nodes in her armpit. In my case, they wanted to start with chemotherapy. We did chemotherapy for 20 weeks. She showed up that first day, like, all right, let's go. Let's get this done. And her doctor was like, I've never seen someone excited to get chemo. Her attitude was, well, the sooner I start it, the sooner I finish it. So we have to get it done. Let's get it done. And that was her attitude of the whole thing. If you didn't know, she didn't tell you if the physical signs weren't there, you'd never even know she was going through this. She underwent the 12 weeks of the initial treatment, then two months of a little heavier treatment and then she went to surgery. We then, at the time of surgery, tested the lymph nodes in her armpit and found that indeed she was one of the exceptional cases where all that cancer had been cleaned up and we did not have to do a formal lymph node dissection. We actually had to do a mastectomy for her. If the amount of tissue that has to be removed would be deforming and then it doesn't make sense to do a lumpectomy and we need to go with a mastectomy and we do immediate reconstruction, which is what we did in her case. At the time of mastectomy, I would come in and I put a balloon in called a tissue expander underneath the skin that's left behind from her mastectomies. Those balloons serve as space holders, essentially, and it allows us to also stretch out the skin that remains behind and then decide on a more definitive type of reconstruction based on the fact if she really did need radiation or not, even though we thought that may be the course of treatment she was going to have to take. She had 33 radiation treatments daily Monday through Friday for a total of about six and a half weeks. Even after a mastectomy, there's a risk of the cancer coming back and the radiation therapy gets that risk down to one or two percent. We were able to do what's called a deep inferior epigastric perfrator freeflap. Because she's had radiation therapy, implants and radiation can have a lot of problems. They can get hard called capsular contracture. They don't change similarly to a natural breast, especially in unilateral reconstruction. We decided to use her own tissue because she had been radiated. It's nice to have your own fat and skin as a definitive type of reconstruction so that you don't have to worry about any long-term complications in the future. The most important part of this is what we call the multidisciplinary approach. We meet on a weekly basis to discuss each and every new cancer patient that is seen through medical oncology or surgical oncology. All representatives from each subspecialty are sitting in a room as we review each and every case. We make sure that we communicate so that we're all in tune with one service understanding what the other service is doing. We're on each other's cell phones, so the minute I see a patient, if I have a question, I'm calling or texting the surgeon or the radiation oncologist or the medical oncologist with any questions. So the communication is there and the determination to really give each person the best treatment is here. All indications point to that she's cured. Everything she did, she did like a trooper. In the evolving of this bad situation, I truly believe it has become something special. This kind of situation puts you in a different element and the way she went through it with guns ablazing, so to speak, it was amazing. So it opened my eyes to her. I fully resumed my duties as mommy and I also work full-time. To anybody who's maybe going through this or experiencing this, your job is really just to fight and my best advice to you would be to rely on those people closest to you for help.


Some people think that we cannot have affordable drugs in this country. They think Americans should be paying twice as much as everyone else. And they want us to be guinea pigs for their untried drugs. Those people, they're called pharmaceutical companies. And I would like them to contribute to my campaign. So, fellas, if you're out there, return my calls, would you? Please? I'm Gil Fulbright. For the right price, I'll approve any message.


20 yeah yeah one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen eighteen ninety


In this video, we're going to take a look at the new features that have been added to the Stream Deck in version 5.3 of the software that was just released. So whether you are using the Stream Deck for live streaming or productivity in general, you're really going to love these new features. So let's jump in and take a look. First off though, we do actually need to get the update, don't we? So how do we do that? Well, if you come over to your app, your Stream Deck app, and then click on the little cog wheel just up at the top here. And then from the preferences screen, what you need to do is just click on that check for updates button. If you are not on 5.3.anythings or any previous versions, just click on the check for updates and you'll see that there is an update available. Go through the update process and update the Stream Deck. But we're still not quite ready to go because what you need to do then after you have done the update is go back into that same panel again. And what you'll notice is there is now also a firmware update, I should say, available. So just go in and click that one and that will update the firmware on your device. So let's have a look then at these new features, shall we, now that we're all up to date. So I'm going to start with some that are actually pretty irrelevant to me and that is OBS Studio Integration 2.0 as they're calling it. So they've basically redone the OBS plugin for Stream Deck and they've added in 10 new actions. And those are, cunningly, I've got them here to pop up on the screen for you. So first is the ability to pause and resume an active recording, turn on or off a replay buffer. The next one is save the active replay buffer. By the way, these are relevant to me because I use Ecamm Live. One feature request for Ecamm Live has been those replays. So maybe I should note these down as a feature request for Ecamm. The next is switch scene collections. Next is play, pause, restart and so on for the media controls for a media source that you've got in OBS Studio Mode. Toggle this on and off, review to program. So send the sort of preview scene to the program window, I guess a bit like we've got preview mode in Ecamm Live.  Take a screenshot of the current preview and finally switch transition and set a duration. So that is what those updates are for specifically for the OBS plugin. Now I should just say, if you are using OBS and you're on a Mac, then I wonder, have you heard about Ecamm Live? I've just mentioned it enough times. Ecamm Live is basically live production software built purely for the Mac and it is very Mac-like in its implementation. I did go down the OBS route by the way when I first started out looking to create this type of video.  Hair still hasn't grown back, but I'm a lot happier now that I've found Ecamm. You can get a free trial of it as I say, if you are familiar with OBS it does most of the things that OBS can do and a lot of things that OBS can't do as well, you can get a free trial at takeonetech.io.ecamm. And if you really like it then I've even got a whole masterclass all about it that you can find in the description as well. But with that said, let's get back to some of these features shall we? So back to the updates and the next new feature is device rotation. So this is something that you'll find in the settings if I come back over here, clicking on the cogwheel then we've got this new little option just here. This is in the general device settings where you can set brightness, screensaver, all that kind of stuff. So we've now got this extra field here which is device rotation. And what that's going to do, or sorry device orientation, what that's going to do is just rotate the button. So if you think about the way that you use Stream Deck, I've got mine here and I've got it in this orientation logo at the top with the text the right way round.  There's any number of reasons why you might want to have this in different orientations, cable routing and things like that. Well now you can do that. And if I just come back over to here momentarily, I can come to this device orientation and basically you can choose standard 90 degrees, 180 or 270. So if I come back over to my device, if I change the device orientation 90 degrees, what you'll see is all of these icons will rotate by 90 degrees. They stay in exactly the same places on the device, or exactly the same place on the device but they've just literally rotated the icons. If I want to turn them upside down, maybe this is a good one to look at the house for my home icon. There it's upside down now. Turn it to 270 degrees and then finally back to normal. So it's just rotating the way that the icons appear on the keys. Now if I come back over to the Stream Deck app itself, you'll see that there's nothing that actually happens in the app. So if I come over here and I change this to 90 degrees, it hasn't actually changed anything on the device, in the app I should say itself, it's only changing it on the device. So that is quite a nice little feature there. The next one is the ability to resize the property inspector area on the app. And what is the property inspector area? You may also ask, well it's this whole area down here, down at the bottom of the device where you add in an action and you've got this area here that you can edit the settings. So if I was to come down and find something, there's one down here that I happen to know is, that's quite a lot of information in it, the custom shortcut for the zoom plugin. And what you'll see is in a moment, there you go. It's now got this information and settings related to that particular action. But what you can see is we've got this little scroll bar here. So that just sort of be able to move down to see the rest of the details and the information in there. Previously, the size of this window down here was always fixed and as we resize the window of the app, it was always this area up in the top that would be the one that got bigger or smaller. Well now what we can do is if I just make this window a bit bigger, what I can do is I can just grab this centre bar. I mean it's something that I went to try immediately when I first started using the stream deck because you just feel like it should be able to do it. Well now it can. So now you can see how I've resized that window. It's all fitting on our screen here nicely. And you can see that now we can see all of the information for that plugin. So just a little thing in terms of functionality, but it does actually make it a lot more usable because you don't have to worry about these scroll bars and things like that. So a nice little extra little bit of functionality that's been added in there. So moving down the list, the next up is integration and support for the Corsair Voyager laptop. Why have they got integration for a laptop by a company called Corsair? Well in case you weren't aware, Corsair actually own Elgato. Corsair make a whole range of PC streaming and gaming gear. They make PCs. They also make components and various different things like that. And they actually own a number of different companies of which Elgato is one. And the Corsair Voyager, in fact I can even show you, the Corsair Voyager A1600 features a built-in macro bar right at the top. You can just sort of see it over there. In fact if I scroll down here, this is it. So where you can see between the sort of base and the screen, you've got this line of keys here. Well these are basically all programmable keys just like you would have on a stream deck. He says knocking his stream deck over. And with those basically you can program those now in the stream decks app. So what you would do is if you are owning one of these laptops, you would just come into your stream deck app and you would see that the Voyager would appear as the device name. So just as you can select the device in the stream deck app. So if I come over here, you can see here we've got the different devices. So stream deck mobile, stream deck pedal, stream deck XL. So Voyager would just appear in there as one of those devices. And then you could just use the same familiar interface drag and drop to add your actions to your course at Voyager laptop. So again, I'm sure that's going to be really welcome for people who use those devices. Not one that I'm going to use, but nevertheless. Nice little addition. The next new feature though is custom multi-action delay. Not to be confused with multi-action delay actions. Let me explain. Perhaps if I come over here and I delete this action I've just created, if we want to create a multi-action, this enables you to basically string together a series of different actions in anything that you've got from the plugins. You can just chain them all together. There's two ways you can do this. You can either come into the stream deck and you can select multi-action and you can drag it across just like that. But actually there is a shortcut for multi-actions which is just right click and create multi-action there. Once you've created the multi-action, then you just click on this little arrow here to go into edit it. And now we basically just drag on any actions that we want to go there. So why might you want to do that? Lots of reasons you might have it opening an app and then opening a series of documents or various other different things. Lots of use cases for this. One that you might do is something like a stinger transition in Ecamm Live for example. So just to use that as an example, I do have a little stinger transition which is something like this. You can always have that pop up.  So that is what it's used for. The way that you'd program that into a button so that it does those two things at once, the stinger triggering and then the transition to the next scene is, and this is by the way not the new feature. This is the way to use the built-in delay. So what we would do is I'd come into Ecamm Live.  So from here, I'm going to select it. It's just thinking for a moment. There we go. It's actually taking that as a default, the first one up there. And then if I go to run scene and then I select the scene that I want as this main scene from all of my scenes. And now if I was to trigger this transition what might happen is because there's absolutely no delay in them, it's sort of the timing of it might all be slightly off, although actually I have to say it did work kind of well.  What I'm going to do is I'm going to show you what the sort of traditional delay that you might have added in would be. So in the stream deck plug-in, you've got this delay action. This only appears by the way when you are in multi-action. So you won't even see this as an option if you are just creating a regular action. But if I just drag this across here we might want to add in a bit of a delay. And the way that you specify delay in here is in terms of milliseconds. If I wanted half a second delay I would just type 500 in there and then, as I say it was working pretty well before, wasn't it? But that now after 500 milliseconds is switching the scene after starting that animation. So that's kind of how the delay works in there. But the thing is there is actually a sort of baked in delay in stream deck. And from all of the previous versions from 5.2 backwards there was always a 200 millisecond delay between any actions. So if you didn't actually want any delay in here and you just got a series of things that you wanted to trigger pretty much all at once it was impossible to do that because you'd got this 200 millisecond delay sort of baked into it. So even without the delay there was probably 200 milliseconds between this one and this one which is actually why this kind of just happened to work that way. But let's say you were doing something where you didn't want any delay that could sometimes cause a few issues. So what they've done now is they've actually added in the ability to adjust the built in delay if that makes sense. And the way that you do that is just down here. You've now got this extra little icon this one here, the customized delays and it allows you to select two different delays here. The first one is what they call the virtual key press. That is if you imagine, you know, pressing a button you've got a whole series of of actions in here for each one imagine that you're just kind of virtually pressing a button to activate them. Well the virtual key press is the time from when the trigger is sent to the imaginary button popping back up. A bit of a weird metaphor I know but that you can now change the time from basically 100 milliseconds down to one millisecond. So that is kind of like the time of like pressing the button and it triggering the action. One thing to bear in mind with this is in some of these cases you could run into issues where basically you're trying to do it too quick. Certainly when you're sort of chaining things together you might have things where apps need a certain amount of time to react to them. So actually, you know, it's not a case of well let's just set all of these to the lowest possible number and then everything will just happen quicker. There may be a bit of fine tuning that needs to go on here. Some things it may actually kind of stop the chain of events from happening. So there's not going to be sort of one size fits all for this. The next one here that we've got is the time between actions. So this again can be between one millisecond and 100 milliseconds. The default for these is basically exactly as it was in version 5.2 and previously. So this is set to the virtual button press or virtual key press is 100 milliseconds and the time between actions is 100 milliseconds given us that 200 milliseconds that there was always before. 200 milliseconds being 0.2 of a second if that puts it into a bit more context for you. But what we can do is we can now actually take this both of these down to get a theoretical minimum time between actions of two milliseconds. One for the virtual key press and one for the time between actions. So again not necessarily relevant to this particular use case here that I've got but with anything else where you're kind of stringing actions together something to play with. This is not going to replace that delay because obviously the maximum that we can get up to is 200 milliseconds. Whereas with the delay you can see that the default for that if I just drag it in the default here that it puts in is 1000 milliseconds being a second but we could equally do here if I'm doing my outro on YouTube then I would set that to 20,000 milliseconds which gives me that 20 second countdown to the end with my end scene and various different excitement. So that is these delays. If that is a little bit tricky to get your head around then if you haven't run into any issues with this before and timings of things and you haven't noticed that there's any this is taking too long or something like that it's almost something you don't need to worry about but if there are some things where you wished things could actually trigger closer together and they just can't because of this 200 milliseconds this is where this is going to help you. So I hope that kind of explains it maybe a little bit confusing having three different delays but I hope not. Now if you are relatively new to the stream deck and maybe you're not using multi-action features or indeed many of the other great features of stream deck then it may be that you might want to check out my beginners guide to stream deck and that is coming up right now as is my playlist for stream deck in general. So maybe check out those videos and I'll see you in there.


Phenomenal run and a lot of you guys did great with this things has been an absolute great trader But now it's putting in the opposite right if the Q's were putting in three four days in a row of higher lows This thing is putting in four days in a row of lower highs You see that high lower high lower high lower high if the if this thing could just get below this whole channel here And lose the five-day moving average. I think the video could get pulled So if you know this would definitely be one of the one of the first ones I'd be watching if we start losing that 307 level on on on the Q's I'll look at Microsoft, right again Another one had a great run today, but you have to start looking for signs like lat I think it was last night they got upgraded the stock couldn't rally today again If a leader cannot rally after an upgrade it means is getting tired You see I was just sitting here right you see how Microsoft is sitting here three days in a row Defending on the five-day same thing when the video if Microsoft starts losing the five-day there will be a pull Right there will be a pull as well


So the metaverse, unlike the fancy and commercial headlines about buying digital real estate next to Snoop Dogg, the rapper, and all this hype around it, it's really distracting from the real message and purpose of what we've explored with the metaverse is to use it to transform education and learning, and most importantly, to take young individuals from low-income, marginalized communities and upskill and reskill them into developing this next generation of the internet, particularly because it's a non-coding, coding environment. So an individual like Samantha, who is an art major, 20 years old from a community like South Central Los Angeles, is actually exceptional and has a professional career now in that space, and that's the exciting thing about the metaverse that is the reality versus some of the hype that we're hearing with NFTs and blockchain and crypto and metaverse. So that's where we're focused. Well, so there are a few areas. One is we're working with schools in low-income communities right now in Chicago, Florida, and Los Angeles, but we're also working internationally, and it's giving teachers and students and principals new abundant skill sets to create imaginary spaces that let them teach in a way that brings students and engage them in these immersive and experiential learning models. So we've all been working on developing four types of pedagogies in education learning on how you can actually use the metaverse for this purpose, and what I would say is that it is a superior model for some topics than what you could do in a classroom setting or on digital online learning, and that is not only because it's engaging, but you can bring environments to life. They get the brain to receive these signals in a way that is more effective for learning, and there's efficacy studies that have been done that demonstrate that. Yeah, just like any technology, artificial intelligence, or even fire, there's pros and there's cons, any invention. With the metaverse, it's the same way. I mean, it's really surprising how realistic these environments have become just in the last year. The price is coming down significantly, but with that, you have to consider, yes, it can be used for education and learning, but also escapism, isolationism, even some forms of addiction are going to be prevalent with this new capability because it's so realistic. So we really have to be cautious in terms of, you know, how we use it for positive things, but also how it can be somewhat negative and even addictive in some cases. I'd love to introduce my friends and colleagues here. They helped me co-found the non-profit exponential destiny, and specifically Pablo, a 20-year-old, we just turned 20, and he was a graduate of the Public High School in South Central Los Angeles, and he's actually one of our technical experts because he uses technology to bring images from the real world into the virtual reality metaverse world. Do you want to share that, Pablo? Yeah, Marcos, thank you. So in my work, there's two different paths that I could take in doing this, right? One path is I'm actually an FAA licensed drone pilot. In my work at Nexpo, I've taken my drone, gone and scanned the topography of an area to then bring that into virtual reality to be interactable. And then the second route is I can take my phone right here, right, and use LiDAR, which is a dot projection piece of software that I can use to scan any object of any size and bring that into virtual reality in just a few minutes with all free software. And Samantha is one of our leaders. She's our chief storyteller. She's an art major also from South Central Los Angeles. And Samantha, why don't you describe the work you've done with some of the schools? So some of the work we've done with the schools is pilot programs. And a way to get the schools engaged and to adopt this new method of education is to gamify the process. We get a school break up into teams compete against each other and see who comes up with one of the best rooms around our topics specifically in virtual reality. And that's actually the way they stay entertained is the gamification process. It's the the challenge of trying to beat the other teams. So they try to create the best possible experience. Well, yeah, definitely. So I mean, that's why we came to the ITU Summit to talk about this. It's a little it's a little bit of a Wild West complicated space.  I mean, Pablo, who's our chief technology officer, can probably describe it best. Earlier, I mentioned two paths I use and two pieces of tech that I use I use drones and LiDAR and just making these two pieces of the hardware connected to each other and work seamlessly is a job in in itself. And this is true. This is just two pieces of the tech, right? In the industry, there's there's a mass, I guess, growth in hardware, right? There's there's haptic devices that are coming on the market now. There's gloves, haptic devices, devices, there's suits that you know where to give you vibration, all that hardware. There's no tech and smell. There's like a smell as well as just in the after effects in the software, right? There's and making these these work, all these products will work more seamlessly with each other in AR, in augmented reality, virtual reality, in the haptic devices, and so on is very important, important to the interoperability of it all. Yeah, I mean, quite frankly, the way we look at it is we have all these productivity tools. We it's a non coding coding environment. So individuals like, you know, from any background, an art major can actually code in this environment. We akin that to, you know, Samantha essentially is a coding the next generation of the internet. But rather than having to learn HTML or JavaScript, like I had to do in 1992 with the internet, she uses her art skill set and creativity skill set to basically get in these environments and manipulate things with their superpowers, which is about as hard as editing a TikTok video, right? It's not a coding. She never writes no code, but you create these environments. So we can excel very quickly to do this. Our biggest bottleneck is, which is something hopefully the ITU is going to take on is what happens then when we have all these different headsets, all these different haptic devices, all these different eyewares that don't operate interchangeably. And it slows us down technically. So the standards are pretty important here if we're going to get this thing working effectively and delivering on its promise. This has changed my life dramatically. A year ago, I would never have imagined that I'd be sitting here one or even working at a nonprofit like Expansion Destiny. I had no clue that technology and virtual reality specifically was being used in these ways. I just thought it was for gaming and just having fun. So when I actually tried it and saw that I could just build things out and that makes the whole business that it was amazing. It was so easy to learn and very entertaining to do. That's right. As a nonprofit, so there's no commercial incentive here. It's purely a nonprofit. We're trying to think of a way that how can we get young people or adult learners from around the world exposed to this technology and start experimenting and realizing how non-technical it actually is to create. So therefore incentivize them to build in these spaces. So we coordinated this with the support of the leadership from the ITU. And we announced yesterday during the keynote that we launching a global prize and virtual reality competition around metaverse for the STGs. And anyone in the world can compete. 14 to 18 year olds is one category of teams and 19 year olds are above is the other category of teams. And if a team wants to form they can partner with anyone they want in the world because you're in virtual reality. So a team from Mexico can work with the team from Spain. And those teams of two to six people each will take the next six months to select an SDG out of the 17 and then go build some imaginary experience that they feel expresses that SDG in a way that builds empathy, education and awareness of the challenges and opportunities associated with that SDG. And we are going to evaluate all of the submissions and the winning finalists from all 17 SDGs. We're going to fly them to probably Bucharest, Romania for the next ITU summit. And we're going to have them demo all the 17 finalist teams. And then the delegates that attend our plan is that those are the ones that are going to vote and figure out the best experience of show the overall winner. And we've already raised from the honest company which is one of our sponsors who gave us a donation as a nonprofit and a company called Blend Hub. Those are the two sponsors that have initially funded us, which is all prize money, thirty thousand dollars for responsible consumption and production, that SDG, and zero hunger is thirty thousand dollars. And we plan to get all 17 SDGs funded, which means teams that compete can win money for themselves in their school, while also picking up a new skill set that's going to be valuable to them in terms of upskilling them into the new job economy.