My wife asked me, do you feel like it's your birthday when you have to work? No, but this is a great evening, isn't it? Oh, hi! I'm in the post office as well, and we have been instructed to deliver you this postcard and wish you a happy birthday. I guess they hacked my phone, now I told them because I brought some cake to my fellow Haralds because it's my birthday, so thank you Haralds, thank you post office. Wow, it's so wonderful that these services all around, big applause for the post office. And then for the thing you're really here for, of course, which is the great talk. So I've warmed up the audience together with the main post office, warmed up the audience for you a bit already. Ladies and gentlemen, we're gonna start with our next speaker. I won't tell him about him that much because he will introduce himself, but that's giving at least as warm welcome as you gave me. So ladies and gentlemen, Matthijs Mehlissen. Good evening all. I'm going to talk tonight about single sign-on protocols as seen from the perspective of a hacker. First, a little bit about myself. I'm Matthijs Mehlissen and I started my career a long long time ago as a developer, a PhD developer in a small software company. After that I moved into academia. I started working as a researcher at the University of Birmingham and the University of Luxembourg. I did research on single sign-on protocols there. And currently I'm working as a hacker. I've been working for more than seven years at CompuTest now, a security testing company in the Netherlands. You might have seen our tent already. It's the tent at the very end of the field with all the arcade games inside there. If you haven't, feel free to drop by. So CompuTest is a full service security company. I myself work as a security tester, but we also do incident response. We do monitoring and we do government services. That's briefly about me. So single sign-on. That's what I'm going to talk about tonight. What is actually single sign-on? I guess many of you have logged into the Stack Exchange website sometime and I'm going to demonstrate how single sign-on looks like from an end user perspective on the Stack Exchange site. So if you want to look log into Stack Exchange, you're clicking at this beautiful login button there. You're presented with the next screen in which you can choose between a couple of single sign-on providers. You can choose, in this case, Google, Facebook, or Yahoo. You can also choose the own Stack Exchange single sign-on provider. For example, when you click on Google, you're forwarded to Google. You can also see in the URL bar that we are at the Google.com domain now. You're entering your Google credentials and Google provides back the user's identity to Stack Exchange. And we are logged in at Stack Exchange now. So that's briefly what single sign-on looks like. I already mentioned a single sign-on provider can also be a website that's run by the application itself, by the company itself, and that's a trend that we really have seen a lot in the last couple of years, that instead of building one gigantic application containing an authentication module, what companies are doing is they're moving authentication out of their application towards a single identity provider or a single sign-on provider, which is good because it means that you don't need to worry about authentication within your application anymore. So why would people move towards single sign-on? There's a couple of advantages and, of course, also a couple of disadvantages. First of all, single sign-on makes it quite easy to use for the user. You can look into a lot of different applications using the same credentials. So you don't need to create different credentials for each application or store different credentials for each application in your password manager. It is also quite easy from the perspective of the person managing the web application. Because what you can do is there's only one single place only in the identity provider where you're storing users' identities. So if you're running multiple websites, there's a single place where you can manage them all. And a final advantage is security, with a big question mark behind that, of course. It's somehow nice from a security point of view to have identity provider handling for your authentication. But the reason that is nice is that it means that all the difficulties of authentication and logging in, you only need to handle at one place. But, of course, every advantage comes also with its own downside. And that means that you need to build some kind of protocol that connects the application to the identity provider. And in particular, you need to have something on the side of the application that handles the response of the identity provider. And what we are seeing as security testers in my daily life, I see this going wrong a lot of times. And the problem is, if it goes wrong, you have immediately serious consequences because it immediately means that you can log in to the application. So an attacker can immediately log in to the application if there's a mistake there without having the right credentials. So what would be the simplest possible solution to solve this problem? And I think that's this very simple protocol. What we're doing is we're entering as a user, a username and password to watch the service provider. That's the application we would like to look into. We have a username and passwords that is forwarded by the service provider to the identity provider. The identity provider checks if these credentials are right. And if so, tells the service provider. Very simple protocol, also perfectly good protocol. As long as you are okay with the fact that it's a perfectly fine protocol, as long as you assume that service providers are trustworthy. If you build a setup like this, if one of the service providers gets compromised or gets malicious, they own the credentials of the user, so they can also log in to all the applications that are connected to the same identity provider. In reality, often in security, you would like to have segregation. So you would like to have the guarantee that even if your service provider gets compromised, all other service providers remain secure. And this is the reason that you would like to have a single sign-on. And that you would like to have a proper single sign-on protocol rather than a simple naive solution that I gave here. So what are we going to talk about tonight? I'm going to talk about two protocols. The two protocols that we see the most in the wild, SAML, which is an XML-based protocol, and OAUF and OpenID Connects. I'll tell about the relation between these two later. And for each of those protocols, first, I'm going to show how it works, and then I'm going to show what are the most common attacks. I'm not going to demonstrate any new attacks today. Today's attacks that I'm going to present are all attacks that are very well-known by the people that look into these protocols every day, but apparently not so well-known by developers. So we can find these attacks quite commonly in the wild. Like I said, I would start with SAML. And in SAML, we have three different roles. We have a service provider. That's the application that the user would like to look into. And we have an identity provider. That's the server or the service that checks the user's identity. And, of course, we have a user that tries to log in through his browser. And the steps of the protocol are actually quite simple. The service provider, if the user wants to log in, then the service provider sends an authentication request through the user's browser to the identity provider. Note that all messages are passed through the user's browser. The identity provider then checks the user's identity and sends an authentication response back to the service provider. And if the service provider receives that authentication response, then the service provider can check that it indeed is the right user that's logged in. So I'm going to show now how these messages look like. An authentication request, like I said, it's XML-based. So an XMAS authentication request looks like this. We have in there an ID. We have the name of the provider, the destination, and we have also here we have the issuer, which is the service provider that generates the request. If the identity provider receives this message, then it responds with a SAML response. In the SAML response is an ID. Again, there is a destination, and there is an in-response-to-value here that should be equal to the ID of the request that we just saw. Also, there's the name of the issuer, the name of the identity provider. There's a status code, success in this case, which means that logging in succeeded, and there is an assertion. And the assertion looks like this. It again has an ID that has the name of the issuer. It does have a digital signature. And this, by the way, is funny because digital signatures contain a URI that refers to the part that's actually being signed. So in this case, it says this URI is being signed. So the entire thing that signs contains its own signature, which when I first thought, this is funny, you cannot put a signature over something that contains that same signature, but actually the protocol takes this into account. So it first drops the signature before actually verifying the signature. Moreover, what we have is a subject. That's the name of the or the ID of the user that's trying to log in. We have conditions, for example, for its audience, is it valid? And when is it valid? We have an authentication statement. When was authentication happening? And this is important. We have the attribute value, which contains, in this case, the email address of the user that's trying to log in. There can also be other attributes. These messages, of course, need to be sent to the other side somehow, and there's two different ways to do that. There are URL bindings, and there are post bindings. What we do, we take the message, we take the XML, we deflate it. That's a compression algorithm. We base 64 at URL encoded and pass it in the URL. Or we can do exactly the same thing, but in a hidden form field. So what kind of things can possibly go wrong here? First of all, what we can try to do as hackers, execute a man in the middle and try to get in between the service provider and the identity provider, intercept the messages and see if we can do something with that. And actually, in this case, where we use HTTP, there's nothing that prevents us from doing that. Summall doesn't care about transport level security. Summall doesn't encrypt any messages that are sent from one side to the other. It does have signatures, but those signatures don't guarantee confidentiality, only integrity. So if there's no TLS, we can intercept all messages, including the Summall response and use that Summall response to log in to the user that's trying to log in. So always, always, always run Summall protocols over TLS. Fortunately, most of the implementations that we see actually do this nowadays. What else can we do? I already showed you before that there is a signature in these XML messages. Of course, if there is a signature, we want to break that. And this is something that actually works surprisingly often we see at our customers. We surprisingly often see that there is a nice signature in a message, but there is no process on the other side that actually verifies this signature. And my theory of why this happens so often is that developers mainly care about making things work, and there is nothing that doesn't work if they write an implementation that doesn't check the signature. Other theory I have is that perhaps they might comment out the line that checks the signature at some point, then don't notice that or then they forget that they ever commented this out and then forgets to uncomment this. Anyway, I don't... These are two hypotheses about what are the reasons, but we do see that signatures checks are very often just ignored. In addition to checking signatures, what we can also do is check if unsigned messages are accepted. And that's not exactly the same, right? So if you check if the signature is verified, we just change the message, see if it's still accepted. What we can also do is just drop the entire signature, drop the entire thing from the XML, and see if the application likes it. What we also can do is self-signed certificates. These signatures are actually signed by a certificate we can check, and we can check if the message is encrypted rather than signed, because for some reason developers also confuse these two quite often. My third attack that I'm going to discuss is also a quite fun one. It's XML signature wrapping, and it's based on the way... It's based on a parser differential between getting the ID that's trying to log in and verifying the signature. And what I mean with that is I'm going to show this in this quite complicated XML overview. So on the left is the regular message. On the right is the message that we are using if you're going to attack this. What we are doing is we are wrapping the entire thing into our own summer response with an evil response ID. It doesn't really matter what it is. We are changing that, so we are entering here the ID of the user that we would like to log into. And we are changing the signature. So what we are doing is this, or I'm actually not changing the signature. So what we are doing is this signature refers to the green block. The signature is still valid. And what we see in some implementations, and this is also something we actually do see in practice, what we see in some implementations is that if you send a message like this that the part that is verified, that's the green part. And the green part has a perfectly fine signature. And then there is a next step in which we are going to check which user is actually trying to log in. To do that, we still take the outermost seminal assertion, we check which ID that is. But that is not the idea of which to just check the signature. So this is XML signature wrapping. Attack number four, attacking the XML parser. And many hackers that have ever worked with XML will find this familiar. There's a lot of nasty things you can do in XML. For example, you can define your own external XML entities that might refer to internal files, that might refer to internal network locations. And you can use this to read the content of the network location or read the content of the local file. Nothing special about that, just the normal XML vulnerabilities that always work, also sometimes work here. Then we have login cross-site request forgery. And I hear many of you thinking, okay, login cross-site request forgery is not actually so serious, but I'll show you that in the case of SAML, this can be really nasty. Because we have, let me first quickly repeat what login cross-site request forgery means normally, is you can do cross-site request forgery against login functionality, which means that as an attacker, we can login ourselves on the device of a user. So that means that the user opens his laptop, cross-site request forgery happens, and the user finds that the attacker is logged in on the application on his device. Or perhaps he might not find it, he might not spot it, and he might accidentally enter data in the application, not knowing that he is entering the data to the attacker accounts. So again, what we can do, we can login ourselves as the attacker on the user's device, not the other way around, that would be much more serious, of course. But the nice thing, and I mean from a hacker perspective, what we can do is we can also connect our Facebook accounts. Many applications have functionality that let you add an existing account, an existing single sign-on account like Facebook to your account. And by pressing at Facebook account, it's running through the normal login flow, the normal semiflow, but instead of logging in, it connects your Facebook account to your existing account. And if you can see as a ref this, what that means is we can connect the attacker's Facebook account to a user's account, which means that in the future we can always use our attacker's Facebook to log in to the account of the user. So login CSF can be very serious and it's something, especially if you have connecting functionality, that needs to be taken very seriously. How does it actually work? Basically the same as login CSF always works. So what do we do? As an attacker, we connect to the service provider, we say we want to log in onto our own account, the authentication request gets forwarded to the identity provider, we log in with our own accounts, with our own attacker credentials, and now we have an authentication response that belongs to our account. And then we forward this authentication response to the user agent that might be, for example, a user, that might be, for example, a link in which the user agent or the user can click. If the user agent is tricked into clicking on that link, then this link will be followed in the user's browser. It's going to go to the service provider where the user is going to receive a valid session for the attacker. How do you actually fix this? It's very simple because there is a default way of fixing this in SAML, and this is something I just explained. I quickly mentioned it because we have this in-response-to-value here. And in-response-to-value, I already mentioned, needs to match the ID. And this might be something that looks a bit as a familiar pattern. Maybe some of you guessed this already, but yes, this in-response-to-value pattern is actually just a simple normal CSRF token. That functions exactly the same. So the trick is, on the side, of the service provider, we need to save this ID in the user session. And we need to check if in-response-to-value comes back that this indeed matches the ID that we sent out earlier.  And this is something that I started this talk from. The reason we use such complicated protocols is because we want to protect ourselves against service providers that get compromised. So then, of course, the question is, does someone actually protect against this? Do we have to guarantee that if one service provider gets compromised, that all the other ones are still secure? Fortunately, we should have this guarantee if the implementation is correct. So what is going on? We can try to attack this. We can start a session as a malicious service provider with the service provider. So we just let ourselves log in and get authentication requests. As a malicious service provider, then we are going to start a session with the user. So we have just a normal flow authentication request to the identity provider and authentication response back to the malicious service provider. And now we have an authentication response that's meant for us, for our service provider. What we can do is try to forward that authentication response meant for us to another service provider and see what happens. And I can tell you most of the time this is not going to work because, remember, this authentication response contains the name of the service provider. The service provider is probably going to check what name is in there. This check might be forgotten. I think Google did this, forgot to check sometime in a second. There was a serious vulnerability at Google. Anyway, probably the service provider is going to check the authentication response and the name of the service provider in there and we'll see that this message is not intended for him. We can always try if it works because who knows, maybe we forgot about this check. So that's the summary of the first half of this part, first half of this talk. We can try executing men in the middle attacks. You can try to bypass the signature check. You can try to do XML signature wrapping. Attack the XML parser. Log in CSRF and you can try to be a malicious service provider. These are six of the most common or most interesting attacks. Of course there are a few others but these are the most interesting to present, I think. Let's continue with Oof. Do you guys know what Oof stands for and people always respond? Yes, of course I know this. It stands for open authentication. Everyone says it wrong. It stands for authorization. And why I mentioned this is this is actually important. Because the purpose of Oof is not to be an authentication algorithm or an authentication protocol. The purpose of Oof is to allow an application to access resources of another user on behalf of a user. So for example we can Oof, we can use Oof to allow an other application to access our profile page. Let's have a look how it looks like. It's not XML based this time, so all messages are a lot shorter. They even fit all on one slide instead of the five slides I needed for some. So what's going on? We start. We have four calls in total. A user authorization request and an authorization code grant. These are passed through the user agents. And we have then a backend call that's not passed through the user agent but straight server-to-server an access token request and an access token grant. So these are the backend server-to-server calls. First probably I should mention what roles we have in Oof. Because they basically roughly function the same as Oof. But of course they use different vocabulary. So what we have in Oof is we have a client that's the application that would like to get access to a resource like the user's profile. And we have an authorization server that's the server that checks the user's identity. We start with a user authorization request. And in the user authorization request we send a message straight right to the author with the request for a code an authorization code. And in that request we also include a redirect URI that's written here client.com. which is the URI that the message is being sent back to. So what the authorization server is going to do now like it should is going to check the user's identity and it's going to check if the user actually authorizes the client to get access to the for example the profile request. So in most Oof flows you always see such a check. Then if the check is passed then it's going to send indeed a message back to the redirect URI that we passed including this code. And this code is an authorization code which gives the client permission to continue the rest of the flow which is the server to server to server call client to authorization server containing the access token request. And how that looks like is we are passing the name of the client ID, the name of the client secret and we are passing the code that we just received and the server is going to respond to that with a piece of JSON that contains an access token and the access token is something that can be used for example to call an API that contains the profile information. So as you see here we have a two-step process first we are passing an authorization first we are passing an authorization code and this authorization code can be exchanged for an access token. Let's continue to the attacks. First attack, be a malicious client. And I already mentioned earlier in the summer case, summer protects against this by default. So of course Oof is going to protect against this as well right? Or wrong? There is no protection whatsoever present in Oof of against malicious clients. Oof doesn't offer any protection against clients that forward the token to other clients. And that's actually by design because like I started, Oof is not an authentication protocol or if it's an authorization protocol you can for example authorize the user to share his profile and if you authorize that to it wouldn't be weird for that client to also pass that authorization on to other applications. After all they could also directly share the content of the the content of the profile. So important to remember in Oof no protection whatsoever against clients that forward tokens. So there is a solution for that fortunately and that solution is OpenID Connect. So OpenID Connect is a small extension built on top of Oof and JWT JSON web tokens and it looks like this and it's actually very simple extension to Oof because what we have here is we have here an ID token this one is added to the access token grant and this is actually JWT so this is a science message generated by the authorization server that contains importantly the audience and what I mean with the audience is the client that the message is being used for it also contains some other information including the user's identity and because we're adding the audience now the audience is sent to the or the message is sent to the client and the client cannot longer forward or of course he can try to forward it but a good client would check that he is not the audience and rejects the message of course as a security specialist something we should always still check for if this check actually happens but OpenID Connect is intended to be used for authentication so something already briefly showed you is that if you have an Oof loader should normally be a screen in which actually authorize the application to get access to certain data or to login some applications or some flow skip that step which is nice for a security test or as hackers because it means that we can make any client have the user login to us and obtain the identity of any client so as a client we can make any user login to us under some conditions of course so therefore we have this permission view something else if they are so smart enough to actually have this check yet there is something we can do we can try to do CSRF on this button and see if that works because that's also fun and accomplishes the same then login cross-hatch request rotary this is something that we saw in Summell as well we saw that Summell has protection against this and OpenID Connect Oof it's the same in this case also offers protection against this it's also something that's implemented wrong incredibly often we very often see that people just do not bother to actually implement this check which is very nice especially again if you have the functionality to connect new accounts to our accounts so how does it work the attacker goes to the authorization server logs in with his own credentials the authorization server responds with the authorization code grant now we have a code grant for our accounts we pass that as a CSRF attack we pass that authorization code grant link to the client so we send the link to the client and hope that the client will click on that link and then we are being used we are logged in into the client or we are logged in into the client so the attacker is at that point sorry at that point the user is logged in because it's just going to continue the same flow access token request followed by an access token grant like I said someone has protection mechanisms against that's in response to value OOF also has protection against that and that's done by means of a random state that's added to the user authorization request so what's important is that the client when it receives an authorization code grant that it always verifies the state variable in that request with the state that it stored in the session then next attack redirect tokens back to us in this case we have a link we have an authorization server where we can log into and remember this one contains redirect URI normally this points back to the client but we can also try to change this link and try to change this link so that it redirects to the attacker so we can pass this to an we can pass this to the authorization server and hope that we actually receive a redirect that redirects the code that we need to log in back to us as an attacker you can even make it a bit more complicated and that's what this guy actually did this guy succeeded in attacking github couple of years back and the way he did it was by path traversal so he tried first to enter his own attacker domain into redirect URI that didn't work because there was a requirement that the redirect URI started with github.github.com what he did was he did path traversal he went up a couple of directives and then moved to his own home directory because we remember we had github.github.com and at github.github.com you can place your own content what happened was that the tokens were indeed redirected to his own home directory at github so redirect URI is very tricky best way to implement that is probably make sure that you have the exact that you have the exact same string like you should probably define your own string, define one particular string that's the only string that's being accepted that would probably be the most secure way to accomplish this then an extension quite late a relatively new extension to OpenIDConnect.io is called Pixi and what Pixi does is this is an extension that prevents leaked authorization codes from being useful. Why do we need that? Especially on mobile applications we often see some problems there's basically two problems with mobile applications first of all they don't have a backend so they don't have a secure place to store their own client secret and second of all redirecting back to a mobile application is very tricky in many instances it's possible to install your own mobile application as an attacker so then there's a malicious application that's registers the URL to which the user is being redirected and then at that way the attacker can intercept malicious codes so that's the reason for Pixi make a way or design a way that prevents authorization codes from being useful and what does it actually offer more precisely if there is a man in the middle on the authorization requests then we are still secure you can prove that even if an attacker is able to read the authorization request then there's still no attack possible and the claim or the guarantee for the authorization code grant so the response to that is even stronger an attacker that intercepts the code or even an attacker that can modify the codes will still not be able to log in to the user's accounts so what does Pixi look like we start with generating a code verifier that's just a random string and we calculate the SHA-256 hash of that and that will be the code challenge and this code challenge we pass along with the user authorization request and at the moment that we actually submit the access token request we include the code verifier and this code verifier that's the original string is also sent to the authorization server the authorization server can now compare the two and can compare that basically can check that this is indeed the SHA-256 hash so once again the reason this is often done or sometimes done is because this offers extra guarantee against authorization codes that get leaked what can we do as a pen tester if you see this definitely check that this code verifier actually is checked because of course I'm quite sure there will be many instances I don't think I've ever spotted an impractice but I'm quite sure there are as many instances where people have forgotten about this check so to summarize again a lot of different vulnerabilities in OpenID Connect what can you do as an attacker you can try to be a malicious client you can try to bypass the permission of the user you can try to execute login CSRF you can try to redirect tokens back to SSD attacker using the redirect URI you can check pixie verification so basically the conclusion is single sign on is very nice because it really does provide a lot of advantages but it is also very tricky to get right doesn't really matter if you use SAML or OpenID Connect there's many small tricky things that if you forget to implement it correctly you have big problems such as the attacker being able to login on the account of arbitrary users so I think a general recommendation this applies to a lot of security stuff in general but I think to single sign on protocols in particular do not build your own implementation what we see at our customers if you see your vulnerability we often have a little chat with the developer hey what guy have you guys done how come you actually implemented this like this and very often in that case they just build their own implementation with two or three lines that just check the necessary stuff but don't actually check any security don't actually implement any of the security requirements so please do not build this yourself if you're going to use single sign-on use an existing implementation both on the side of the identity provider there's many good open source product side of there I believe key cloak is quite good and also on the side of the application that actually receiving the message that's coming from the single sign-on provider also on that side don't think it's just two lines of coins if you want to build this yourself please use something that your library provides or uses some existing well-known framework and finally I think this is the most important or this is one of the important things many developers don't know that the reason that you have single sign-on is that you want to protect against malicious clients so in the entire process keep in mind that the entire goal, the entire reason you're using protocols like that is that you want to stay secure even if one of the clients gets compromised alright that's what I wanted to tell about single sign-on I'm curious if there's any questions thank you any questions please walk to the front I need people know already how it goes throw the first question, go ahead hey, a question about Pixie and why it's actually helpful if a client can't assure the confidentiality it's a little bit difficult to understand also because of the music from the outside hmm I'll do my best if a client can't assure the confidentiality of an authorization code grant what makes it able to assure the confidentiality of a code verifier secret from your description it sounds like these are both just static secrets alright so you're talking about Pixie right can you repeat the question once more yeah so in the before Pixie we have an authorization code grant that we receive back to protect the confidentiality of that grant for the duration of the lifetime of our application and that's just some static secret that we store and here we're adding another static secret that we store and it seems like we would need to protect that in the same way so how does this actually help can you repeat what the attack scenario you're trying to protect against well I guess I don't see what attack scenario Pixie is trying to protect alright so I understand your question so the attack scenario is the case so basically at this point in the protocol we have an authorization code and we need to get it back to the user agent somehow and in mobile applications we have mobile applications we have difficulties getting this back to the correct user agents so there is quite a risk if you send this code back this ends up at a malicious user agent for example a wrong for example an application installed by the attacker and what Pixie protects against now is even if the attacker intercepts this code at this point it still will not be able to continue with the flow because it does not know the code verifier because the code verifier is a shahesh of the code challenge so the attacker will know the code challenge but it will not know the code verifier so it will not be able to go on with the protocol after the third step I see so it's more about concerns about confidentiality of the link between the user agent and the auth server and in both cases we're assuming the client to be fully trusted that's correct thank you thank you for the question any more questions yeah I see one coming up back from the signal I think people are watching online so there was a question wouldn't matching the client ID or client secret against the ID for which the token was issued prevent both the relay and the lock in CSRF attack which is something only the auth server that means identity provided I would have to do I'm afraid I'm going to have to ask you again to repeat the question because these are quite technical questions which I need to hear twice okay wouldn't matching the client ID or client secret against the ID for which the token was issued prevent both the relay and the lock in CSRF attack which is something only the auth server identity provider would have to do I don't think so this kind of things are always really tricky so if I say yes you can do this for sure I'm sure someone is going to implement this and end up quickly I don't think it's going to work because probably there's still a message that you're going to be able to send to the clients I think of the top of my head that you still will be able to send the same message back to the client because the attacker is still going to know these tokens I think but this is probably something I would need to write out feel free to if you're really interested feel free to drop me an email and then I can think a little bit longer right probably it's not going to work the way you described people here around mean they can visit you afterwards but your email address would then be on the first slides thank you well thank you any final question no there were some tough questions I agree that it's difficult to top those in general for security protocols it's always really difficult to say I changed a tiny thing is it still secure or not this is really the question I cannot give an answer to straight away if you have more questions feel free to ask Matthijs but first let me give him a very big hand thank you very much alright thanks


So I guess going along with it. This is my first time at scale by the way is a fantastic conference So before I get started when the next slide appears There's gonna be a picture on it the first person to yell out what they see in the picture wins six free internet or something So all right, so if you don't know who Bloomberg is we are a global company that produces a bunch of different things Financial services products media news all kinds of things But the most important thing is we have five thousand people writing software, so we are heavily involved in open source We do a lots of things, but as you've probably all heard Michael Bloomberg Who's the founder of our company is heavily into philanthropy? What is it come on? No, no, no, no, no. What kind of event is this you're looking at? It's a hackathon, right? So what we have here is two hackathons one in our New York office one in our London office They happen on the same weekend. They had about 75 Bloomberg employees They had 20 or 30 people from these open-source communities and about 20 or 30 students from nearby universities Who all came in on the weekend to hack on scientific Python open-source tools? This was a lot of fun. This was actually I think our seventh event doing this The reason we do this is that Bloomberg we have a culture of volunteerism So we have as you can see numbers there and won't quote them all But we have thousands of employees who contribute all kinds of time But up until four years ago, they never had the opportunity to contribute that time to open-source projects We've now given them that chance. So we've done this for well the ones you saw there The next slide is going to list a bunch more logos for more projects that we've done this for and we're planning to do more this year Interestingly we get people Come in on a weekend even when the weather is nice to write software even though they write software all day long every day We're crazy people aren't we we do this kind of stuff So these are all communities that we've contributed to we are continuing to contribute to them more We obviously use all of tools from these projects Which is why they were important for us to contribute to and so when the slide changes you're going to see what we actually Produce out of this and then I'm going to talk about what it takes to put on events like this Part of the motivation for this is we want to get more people involved in open-source projects for those of you who Still remember the first time you try to contribute to an open-source project.  We have had events where people's patches got merged into the master branch of the project Just in an hour after they submitted the patch. It wasn't wonderful. So these things for running these events These are easy right? We have offices. We can provide food. We can provide water We can provide Red Bull we can provide all kinds of things and of course internally to our employees We can advertise these things really well I'm hoping the slide would change there. Dang. It wasn't listening to me So I have to wait wait. Oh, there we go the harder things finding out when you can do this people have lives Amazingly people have lives outside of writing software. It's crazy people have conflicts and all kinds of other constraints We have to bring people in when we did this project We brought in I think a total of eight project leaders from those projects literally paid for their travel to come to our Offices and put them up in hotels so they could be there for the weekend to do this So obviously they have schedules and families and those things and interestingly We found that a lot of big many open-source projects including big ones have no good place to advertise events like this So you end up having a really hard time getting the word out now. They're really hard parts We do surveys in our engineering teams Which projects would you like us to do these events for I get the results back? I sort them by popularity. What's at the top of the list a patchy spark patchy spark is a fun project How many developers out of 5,000 do we have that no Scala? 6 8 maybe I mean it's ridiculous. We would never be able to contribute effectively to this project So those are the things we have to work through to make this happen Obviously our goal is patches getting more patches up as we've done eight or nine events I think we've probably produced a hundred and fifty patches so far for a bunch of different open-source projects and I'm trying to encourage more people to try to do these things if you work for a large company that has a Volunteer program of any kind that so that contributes to charities that you can even convince your human resources department to give you Whatever you want to call it comp time time off whatever for in return for contributing to an open-source project in an organized way like this Please encourage them to do so if you're interested in Contacting me to learn more about this you've got contact info there And if you want to see the full version of this talk, there is a video on the FOSDEM 2018 website because I gave the full talk there. Thank you very much


My life's kind of boring, but I'll film it anyway. No one else for this. Oh my God, please never let me do that again. Well, it happened. I got sick. Good morning, everyone. Welcome to Vlogmas number five. We made it almost halfway before I got fricking sick. It actually started happening right when we got home from the Christmas lights, which was I think the last thing you saw in Vlogmas. I started feeling like a little tickle in my throat and I was like, oh no. And I actually didn't even get to spend my dad's last day with him in LA. I was really sad about it and I just didn't wanna get him sick and he didn't have that much time here before he went to the airport anyways, but it was just a huge bummer. I was like really, really sad. I actually like was on my period at the same time and I was literally just like laying in bed crying. I was really dramatic, but it's fine. And it's been like four days and I'm like continually getting worse and don't worry, I have tested negative for COVID. It's just one of those things I guess and it's going around right now and I don't know if it was the flu or if it is the flu or not because I keep getting these bouts of like body aches and that doesn't really happen like that long for me when I am sick with a cold, but it's been like day three of body aches and it's pretty gnarly. But I gave myself three full days, like three full days in bed and I just have to like, I have to do something today. So I literally just like put on a little bit of mascara. I don't have any face makeup on or anything but I thought, you know, we got the show must go on. I'm going to take it easy. I'm not going to leave the house obviously. I'm not going to leave the house when I'm sick anyways but I'm just going to like take it really easy today and you know, it's vlogmas. So we're along for the journey, all the ups and downs.  So first things first, I'm kind of in the mood to have coffee for the first time in like several days and we got this new coffee machine and I haven't even gotten to try it out yet. So I think that's first thing on the agenda. Maybe going to like try to make a fancy coffee and make myself feel better. I look how I feel. I feel how I look. I immediately just got back in bed and I'm going to watch some YouTube. I actually just finished, it's about 10 a.m. I just finished very, very, very last minute uploading my newest main channel video and I was putting the finishing touches on it at like 9.45. So really cutting it close this morning. I'm about to watch Molly Burke's new condo tour. It's so cute and I love her. Thank God I got this little tray to do my work on and I can lay in bed and I can like take it around because I don't really have a desk to work at in this house. Drew has an extra desk in his office but a lot of times like he has work calls and stuff and I just want to like give him his space. So I've been thinking about potentially putting a desk here in my bedroom or transforming my office a little bit and maybe like taking out that orange couch. It's kind of just there as an accessory at this point and then maybe putting a desk there, maybe even like a walking desk type of thing but I don't know if I'll like really stick with that so who knows. But yeah, I can't believe I got sick again. I don't know what it is. I think it's just like my immune system like readjusting and you know, maybe it's the fact that usually when I lived in Arizona, I was going out like once a month if that. Like I was doing something socially like once a month and since moving back to LA when I have like a lot more friends here, a lot of my hometown, Tennessee friends live here and social media friends and stuff. I feel like it's, I'm doing way more. Like I'm doing stuff multiple times a week and maybe that's why. I think I got sick from hanging out with my friend last week. Her husband and daughter were sick and then she ended up getting sick. So I think that's where I got it from. But it's just what happens. It's this time of year especially.    And I think I've gotten sick four times since we moved here in June and it's December. So I don't know what's going on but I'm just trying to recover. So I'm gonna watch some YouTube videos. I don't really have any more editing work to do. I'm like pretty much all caught up on that. So I might do some like content planning, you know, that kind of stuff. Try to get back into getting some work done but also like rest at the same time hence the bed situation. And I'm very happy about this. I was just sitting there, you know, watching my YouTube videos and I had this thought and I was like, I could be doing this from the bathtub. Like why am I not sitting in the bath? Like soaking in like a nice Epsom salt bubble bath situation. I feel like it's really gonna help my body. I've been taking baths like every single day that I've been sick. And yeah, like why am I not in the bath right now? You know? So I'm gonna fill up my water and make myself like a nice spa bath because that just always helps me reset. And then I can like watch the vlogmas videos I want to watch today and like maybe some TikToks from the bathtub. Genius.  Like that makes sense. But oh boy, does this feel nice. I'm actually gonna read a little bit of the next book that I've been reading and it's called One Day in December. I actually saw my friend Chelsea or choosing Chelsea from Instagram TikTok. I'm talking about this book. And then when I opened it I saw that it was in Reese Witherspoon's book club. I don't, I'm not familiar with her book club but I think a lot of people follow along with that. And it's like kind of Christmassy themed. I'm only like literally 8% into the book. Like I just started it not too long ago. I think I only read a few pages like the first night. So I'm gonna try to get some festive vibes going read like a Christmassy book. I recommend it so far. I mean, I'm not that far into it but it's about like a sort of missed encounter type of thing. And then like trying to find that person again. And it takes place in London which I love obviously as we know. So I'm gonna put a little dent in on this. And then once I get out of the bath we're gonna have some lunch and do a very fun little taste test for lunch. So I'm trying to chug as much water as possible because I am coughing up a storm. I definitely think I'm gonna put on an old Navy onesie after this. That is like my ultimate comfort outfit. That makes me excited for when I'm done with this but for now we're gonna continue on with the book. Out of the bath reluctantly I wish I could have stayed in forever. It looks like this mirror is really dirty but it's just like a mercury glass kind of finish. But I do have my old Navy onesie on and I couldn't be happier about it. I'm so cozy. Hi! Drew reminded me that we haven't done our advent calendars yet today. So aw, you set them out and everything. Go ahead. You're on four. Yeah, I am. It looks thick. It looks like a lipstick. Oh, okay. Mascara! Mine's strawberry grape.  Yeah, that's a lot of grape. What kind is it? And it's gum. Oh, let's try it.  I mean, it's gonna lose its flavor in mine. Yeah, that's true. I'll try the grape, I don't mind. Here you go. Here you go. The spice is actually good. It's not like Tylenol flavor. The mascara that I got is the Too Faced Better Than Sex mascara. Did you know that's what it was called? He goes... Here she is. I have a little bit of mascara on this morning and it's like the Ilya. I mixed the volumizing and the lengthening one. All right, I'll split this gum now. By the way, this is what it looks like. How cute! It's really tasty, but we're about to eat lunch, so I'm gonna spit it out. Oh boy, it's a special delivery. If you're on TikTok at all, then you would have probably seen this already. I am so curious about this. But this is like the most viral thing I've seen in a while. Hello, welcome to my office. Welcome to lunch break. It's me.  So this is called a tuna kado sandwich. This place is called Joe and the Juice and I'm pretty sure it's actually like a Danish-owned restaurant or like it's in Denmark, you wanna say someone said? Oh really? And so it's this sandwich. I do see a big tomato which looks, I don't know. But it's this sandwich that's like gone so viral on TikTok because supposedly it's like super delicious. So it's like a tuna sandwich. It has tuna, avocado, pesto, tomato and some other stuff. And apparently like the bread is super delicious and unique and like crunchy.  So we're about to find out. It's pretty good. I'd rather just have a regular tuna sandwich with like relish. The pesto is a nice touch. I'm trying to get like everything. I like the pesto better. We'll apparently want some. Honestly, what do you give it out of 10? Kind of like an eight? Yeah. I would say so too. Like maybe even a nine. It's really delicious. Maybe 40. Our life only exists in TikToks now. Like we just communicate via TikTok. But it's really good. The tuna flavor is really good. I like that the bread has like a little bit of crunch. I actually like it on this bread a lot. And I just saw so many people on TikTok biting into this thing and like the bread was really crunchy. It's a good crunch. It's a good crunch. And I'm eating it with tomato on it. So that's how you know it's good. They have a spicy one too. So maybe you'll have to try it out sometime. Really delicious. Not mad at that at all. It's many hours later and it is now that time to get nice and cozy. So we're gonna turn on these lights. Super cute. A personal fave. We're gonna turn on, actually I don't even know if we've turned these on yet. Our little houses. So cute. Love that.  We can turn on the lights behind our TV. We'll do green. And we can even change the color of that. It's holiday time, baby.  Oh my God. It's so Christmasy. I don't know how I feel about this. Maybe green. Whoa. I would turn these on. Honestly, most of them are dead. I actually kind of want to take them off. They're sort of bothering me because if they don't all light, like what's the point? But okay, there we go. About a third of them light up. At least it's cozy. We've got a couple of different shades of green happening but it's fine. So it's been several hours and I've just been trying to like rest up, relax. Now it's time to make some dinner but the day's not a total wash because we did something very exciting. Do you want to share? Well, so something happened and we're possibly going on a trip for sure. Going on a trip in our little rocket ship. Back to Arizona. Yay. We're going back to Japan. Oh, if I wasn't sick, I'd have a lot more energy but basically I'm gonna just sit, I've been sitting in this chair a lot today. It's kind of nice.  He's obviously in a very good mood but basically we've been talking about taking a trip back to Japan for a while and when our friends were here for Thanksgiving we kind of got to talking about it and we had always talked about going with them like for years, honestly. I think we were talking about going together in 2020 and then obviously we know what happened. So that just got put on pause and now here we are and so we were kind of just like chatting about it and then on Thanksgiving we were all for like, yeah, let's do it. Our friend texted us like in the group chat and was like, hey, tickets are pretty affordable right now. Yeah, like the cheapest we've seen in a while and it's on the airline that we wanna fly and so we were like, should we just book it now? So we literally just booked it probably 15 minutes ago. So that is very exciting. We're not only going to Japan but we're going with our friends. We've been like talking about doing this trip together for so long and like they're so wonderful and they're well-traveled and really fun to go places with and explore with and they're like very much the same as us with like they wanna try all the foods and they wanna see all the things and experience a different culture and like all that kind of stuff. So we are freaking stoked. Unexpected turn for the day is that we're going back to Japan which like we knew was gonna happen but now it's like official official, like it's booked.  So in celebration, we are going to make a Japanese recipe which we were already gonna make anyways. Don't cry, it's okay. He's so excited. Drew's just very emotional about it. To our Japan trip. To our Japan trip. I'm gonna be alone because I'm on a sick. Yay. He's using it for the sauce. So he was like, why not? Yum. Cover it? Yeah. With our scenic sauce. Here she is. We usually do like green onion on top but honestly just too lazy. There it is. It's delicious. I'll link the recipe we used down below. Let's go eat and watch our Christmas movie. Time has come for the classic. We're done eating and we figured it's time. And we've, if you like haven't watched us for a while we recently learned last year that like English people take their Christmas chocolates very seriously like every year during Christmas time. I agree too. They're good. Their chocolate is bomb. But every year during the holiday season they have like Christmas chocolates that come out so we did try celebrations which is like, it's like a Mars company so it's Mars Bar which is like our Milky Way. Is it like a Snickers? There's like Maltesers. Yeah, it's like, you know, stuff that we have here. And then we also tried the movie in the background. It's kinda loud. We also tried Quality Street chocolates which are very popular as well. And then there was one more that we haven't tried. And I think I showed this a couple of blogs ago but we ordered a tub of roses. We've never had it. It's Cadbury. It's Cadbury, yeah. And we also got a Cadbury Hero's advent calendar last year. I love the Niki Deckers. We loved the Niki Deckers. I love them. So. Wow, pretty. They're so pretty. So we're gonna test them out and rank them. We won't make this as long as the other one. So we have one, two, three, four, five, six, seven, eight, nine flavors. Yes. To try. I want the strawberry one. Oh, and it actually says on the front. So we have Caramel, Hazel Whirl, Hazel and Caramel, Strawberry Dream, Caramel, Signature Truffle, Country Fudge. Ooh, that's you. Dairy milk, Tangy Orange Cream. Yeah, there you go. You're gonna love that. Golden Barrel. So that's one, two, three, four, five, six, seven, eight, nine. Got them. So let's test. Are we picking random? Yeah. Drew's been waiting all day for this, by the way. Pick one. Don't look. I think we should start with the dairy milk first, because that's like the plain milk, right? Oh, come on. And then we've had dairy milk before here. I'm gonna adjust it so you can see, because we're gonna rank them after a while. Dairy milk is first. We've had this before. And it's just really, it's like pretty much a solid piece of milk chocolate. We've all. Mm. It's just really good chocolate. Nice. They don't make them like this here. What are you gonna try next? Golden Barrel? What's Golden Barrel? This is one of my favorite. Yeah, we don't know what Golden Barrel is, so it's the gold in it. Is it honey? Oh, it's a barrel. Oh, it's so cute. Wait, can you see that? It is, like a little barrel. That is so precious. Oh. Is there goop? Oh. Mm. That one's tasty. Mm. It's like a salted caramel, maybe. That one's really good. Okay, you've chosen country fudge next.  It's not chocolate fudge, it's just fudge. Because their fudge is by default like vanilla, but if you say like fudge in the US, it's typically chocolate fudge. It's like, I don't think butterscotch, but it's like sweet. It does have like a buttery taste. Really good. They're all bangers so far. You pick one. Let's do a fruit one. Okay. Let's do strawberry dream. Sorry, strawberry. Strawberry. Here's what she looks like in the wrapper. Is it a strawberry? Is it? Oh. It is. It has little strawberry seeds. Cute. It's, you're not gonna see that because honestly like this lighting is atrocious. But like there's little indentations for strawberry seeds on top. How cute is that? All right. Is it a cream or is it a jelly? You're gonna love it. Oh, it's like the. It's exactly what you like. That's delicious. That's better than the quality street one. I just noticed how green we are because of the green on the TV. We're set. We're gonna do the orange. I'm getting like that like cloying. Yeah. It has a little orange on it. Ah, you're not gonna be able to see it. We keep trying to show it. We're doing what's it called orange tangy orange cream. Tangy orange cream? Yeah. Tangy orange cream. It's the same. Do you like it? I'm not a massive chocolate orange fan, but. It's good. It's good. The texture of the cream. And it just like cuts the sweetness a little bit. I will say with each year, I warm up to chocolate orange more. First time I had it I was like, ew, ew. We have one of the terries in the pantry for my mom. I might break into that. That's not bad. Next, I'm gonna be ill. We have two hazelnut ones and should we try one of those? Hazel Whirl or hazelnut and caramel? Hazel and caramel. There she is. Hazel and caramel. I wonder if there's a nut in it, like a hazelnut in it? Maybe. Mm-hmm. Wow. Mm-hmm. Oh my goodness. So good. I like that the caramel has like a salty-ness to it because these are so sweet. Like the dairy milk by itself is like so sweet. You're gonna have a nice chocolate. Oh my god, delish. Let's try signature truffle. Signature truffle. This must be like the OG. That's a rose. Oh cute. I don't know. We keep trying to show it every single time and then it's just big. Look, look, there's a rose on top. Truffle. Is it so good? Mm-hmm. It's like our fudge, so that would be like if we had like a chocolate fudge. Oh, it's so good. It's almost like hot cocoa, like cocoa. Absolutely delicious. I'm struggling. Yeah, I'm struggling. I'm not gonna have more when this is over. All right. So there's caramel. Just a little bit. Caramel, should we do it together? Oh, I got more. Mm. The caramel's like buttery. Mm-hmm. Yeah, it's almost like the Werther's caramels that you get. You know what I'm talking about? Almost like butterscotch. Like a butterscotch-y caramel. Mm-hmm. Wow. Just better. It is better. All right, last one. Last one is Hazel Whale. Hazel Whale. Oh, I wonder if there's like a cute little, like, squirrel on the top or something. Yeah. Ah, cute! There's like so much attention to detail. It's got a little swirly-whirly on the top. There's probably a nut in it. Mm-hmm. What's in it? Just the chocolate and the- There's a chocolate and a nut. Mm-hmm. Deflicious. All right. Should we take full ones? So we don't have to use a wrapper. I'm gonna bring you down a little bit so you can see it. Okay. So my number one. Wait, is this controversial? Well, Lea just come to join us. I just can't get this angle right. It's fine. It's fine. No one cares. I honestly wanna say like strawberry cream was up there. And I don't know if that's like controversial. Watch, I pick like the worst ones. If there's one thing English people have the most passionate opinions about, it is food. And like if you make their food wrong or if you eat it wrong or if you choose the wrong thing. No, you're not supposed to use that milk or you're not supposed to use that in that order. You're not supposed to put those beans on the toast or put the other beans on the toast or whatever. I mean, it was good, so. It was good. So I'm like scared I'm gonna be doing this wrong. I mean, dairy milk has to be up there because it's so delicious. I can't believe that I would say strawberry dream is number one. There's no way. Like they were all good. There actually weren't any that I didn't like. So it's a matter of just like putting them in order. I really liked the signature truffle. It's like somewhere in the middle here. I can't believe, like what? I would probably put orange cream as the last, just it was still really good, but I would say it's probably the last. The golden barrel was delicious. That had the caramel in it. I would say like fudge next to cream. The hazelnut ones, I mean they were both great. I would prefer the caramel one over the plain. We'll go, this is my order. Here's my official order for roses. Number one, strawberry dream. Number two, signature truffle. Three dairy milk, four golden barrel. This is off the top of my head. Five hazelnut caramel. That feels like it should be higher up. I'm gonna switch that with golden barrel. Six caramel, seven hazel world, eight country fudge, and nine tangy orange cream. There is my ranking. Your turn. My turn. Is that number one? Number one, strawberry dream, signature fudge. Tangy orange. Signature truffle, babe. Oh, what did I say? Signature fudge. Oh, truffle, golden barrel. Golden barrel was good. Country fudge, caramel, dairy milk, this is just chocolate. And the ones with nuts are at the bottom. Hazel caramel and then hazel world. Wow, and there you have it, that is Drew's ranking. So that's us and the roses. I'm eating more. This is not official, so please don't be mad at us if we did it wrong. But let us know if you agree with our choices. If they're extremely controversial, that would actually be really interesting to know. But yeah, I can't believe that strawberry cream was both of our favorites. That's just like, I would never pick a fruit as my number one, but it was just really good. Dare I say my official ranking would be... I like these better than quality street. I was gonna say celebrations, roses, than quality street for me. Same for you. I like celebrations because it's like, I don't wanna say it's more, it's more typical American candy bar. Or it's just like more what we're used to. You know, quality streets or like the chocolates your grandparents have. It's the, yeah, sorry if that's like an incorrect assumption, but it did kind of feel like these were the chocolates that you would have at your grandma's house. We did bring them to your moms and people enjoyed them. They're all good. So we'll have to bring these back for Christmas this year too. It's always like kind of fun coming back and be like, here's this chocolates from England if anyone wants to try them. People are like, yeah, I wanna try them. So anywho, my cough. Now I need some of the salty.  And that's gonna do it for me for Vlogmas today.  We were actually supposed to be going to Disneyland tomorrow and Friday with his family that's coming to town. They come like, I don't know, every couple of months and go to Disneyland.  So unfortunately, we're gonna stay home and it's sad. But I mean, you guys have seen enough Disneyland for the year. I wasn't gonna vlog anyways, but now we'll probably just try to focus on like, obviously me getting better and then like finding... Christmas. Yeah, like Christmas presents. Like shopping for the family and whatnot. And then maybe looking for some stuff for ourselves. We might go to the Rose Bowl this weekend. So if we do, I'll definitely vlog that. But yeah, hopefully I'll be feeling much better. Thanks for watching and for hanging out with us. And we will see you next time. Well, boy. Bye. In Japan. Bye. That's a don't mark. He's gonna be insufferable until then, goodbye. Merry Christmas. Merry Christmas.


Alrighty, I have a new construction update for you guys today and things are really heating up. I'm sure you have all seen Grace's and Canada's Wonderlands video that I was teasing for a while now that discussed and went into detail about a few things and the park is even teasing an early discussion about the construction taking place in Elpin, keyword Elpin. I'm so glad the park confirmed that that area is Elpin because a lot of people have been fighting me on that and I told you guys just trust me you're going to see a return to Elpin in this area and lo and behold the park is even teasing that. Alright, in our station area, so here on the screen you can see what will most likely be the brake run leading into the station for the 2025 coaster. This I can pretty much guarantee unless I was reading something wrong over in Elpin, they are still working on removing the foundation. This will most likely be utilized for some footings for the brand new coaster and yeah, so TinyToms is moving to a new location confirmed by Canada's Wonderland, but we already told you guys that. Here is the third tunnel, so yay, we've been waiting for this and beautifully enough it aligns perfectly with tunnel 2, so this in my opinion is most likely going to be the launch. Now again, things could vice versa, but usually typically the reason I am assuming this is going to be the launch and the other one is the station and brake run is projects always start with the station, so yeah. Here is my new flight location, so next to the hospital I have a beautiful pond I can utilize for this third tunnel, so I was really excited about that. So I'm able to show you guys a whole new angle and yeah, hopefully you're really liking the drone shots by the way. A lot of work is going into these. I literally fly for like five minutes in one spot, land the drone, drive to my other spot, take off and fly for five minutes, land and then then it's getting kind of annoying and repetitive. I'm not going to lie, that is my least favorite part about doing these construction updates having to land, drive and take off again and land, drive and take off, but yeah, here we go. So if you look closely, I really don't see a wing coaster fitting out of this hole, so I'm really ready to rule out a wing coaster, but again, you can't always rule things out unless you have definitive proof, but I think you guys are really going to like what it most likely is going to be. I will say that El Toro Ryan usually gets his things right and there's a reason that Cedar Fair was probably checking out Velasa Coaster. With that being said, over at Extreme Skyflyer, here they are completely wrecking Extreme Skyflyer, so no this is not getting sent back to Sky Coaster, this is getting scrapped and demolished and the question still remains, what will replace this ride in this plot of land and why was it removed a whole year early? Wonderland confirmed it's for a future project, so what is it going to be? I don't know, I really don't think the coaster is heading out here anymore. I think this is going to be an Elpin Coaster. If it were to head out here, that's a crazy large project and oh my god, but yeah, I have no idea what this land is going to be used for. The park has a crazy expansion plan that they're going to be utilizing over the next five years, so things are all up in the air. I can tell you as much that plans have literally changed last minute for even 2025, so yeah, I have no idea what it's going to be. I think it's pretty obvious what happened, very similar to a Yukon Stryker in 2016. I think Kings Dominion is getting our wing coaster, Wonderland was supposed to get a wing coaster. I don't think that designed by the way, but they wanted to change the plans, but they had a contract with B&M and they didn't want a fault on that, so then Kings Dominion is getting a launched wing coaster and Canada's Wonderlands moving forward with a coaster, possibly Zamperla question mark. But yeah, over here at the second tunnel, the station forms are going up along with the retaining walls for the brake run and yeah, not much else going on outside of that. There is, I'm trying to think if there's anything else important. That's pretty much it. All right, so let's enjoy the construction of our launch tunnel coming out of the mountain. We'll call it that, a third tunnel is going in and yeah, so it'll be interesting to see what happens with Thunder Run and are they going to be able to get this done in time for about 37 days until park opening per season pass holders, 37, 38, whatever it is now? But yeah, thanks so much for supporting the channel and watching these construction updates. Hopefully you enjoyed all the information Wonderland dropped today and yeah, thanks guys. Have a good one. See you in tomorrow's construction update. Bye.


Snapchat is one of the highest rated apps for both iOS and Android devices. It has taken the world by storm with its mixture of timed photos and videos, while others love the direct access it grants to celebrities and other people of interest. But at the same time, it contains a lot of sensitive photos and videos, which you have saved in the chat section while having conversations with different people. In our previous video, we learned how to lock Insta DMs and group chats. And in this video, we will take a quick look at some of the best apps to lock your Snapchat app. SC Chat Locker is a must-have app for those who want to secure their entire Snapchat messenger or chats. Using this app, you can protect your personal data from unauthorized access. To use this app, lock for Snapchat. All you need to do is install the app from the official Google Play Store. Launch the app, create a 4-digit passcode and confirm it. Grant necessary permissions to proceed. Tap plus to add chats you wish to lock. Once added, selected chats will appear under Locked Chats with SC Chat Locker. You are done! Now whenever you or anyone will try to access the locked app, you will need to enter a 4-digit passcode to unlock Snapchat. Chat Locker for Snapchat is a decent Android locking application that has a user-friendly interface. You can secure Snapchat by using a pin. The app works similarly to SC Chat Locker. Just download the app, create a 4-digit passcode, reconfirm the same and start adding the chat you wish to protect from prying eyes. App Lock is a popular Android lock app preferred by a lot of users to lock Snapchat, Instagram, WhatsApp and more. You can use it to password protect any specific app on your phone and prevent unauthorized access. It allows you to hide photos and videos from the gallery and store them in a private vault. Simply create a master pattern lock and use it every time you access Snapchat or any other Android app. Secret App Lock for Android is the most popular app locker available on the official Play Store with more than 100 million downloads. The application has certainly earned that. It provides multiple authentication methods to protect Android apps using passwords, gesture or pattern. Not only this, but the app helps in locking Google Play Store and also prevents your kids from buying games without your permission and supervision. Smart App Lock is an ultimate privacy guard and Android app locker to prevent users from unauthorized access. The application also helps in hiding and encrypting your personal photos and videos with its inbuilt gallery vault feature. Not only this, it shows break-in alerts as well and instantly takes a picture when someone else tries to enter your logged apps with invalid passwords. Cool right? Similar to other app lockers, it supports pin, pattern and fingerprint authentication. So that was all for today, I hope this video helped you to find some of the best apps to lock Snapchat and other Android apps on your device. If you have any suggestions or feedback to share, drop them in the comments section below. And do not forget to like, share and subscribe to our channel. Have a nice day.