 I'm just going to jump straight into my presentation, which is the second part, which is actually on content security policy. So recently this content security policy thing has been getting traction now, starting to see it come up like everywhere. Oh, wait. And you'll see the, okay, let me move this away. Okay, so that's why I decided, and actually I had to use it a bit for work, so then I dive into this and I thought it was a good opportunity to share it for both of you. So actually to start off everything, then comes the question like what actually is content security policy. So actually content security policy is a security feature that allows us to control exactly, make sure that our app only does the things that we intend it to do. So it actually takes a white listing approach to white list assets like script styles, like images fonts, etc, etc, white list these assets, and then we can totally control whether they are executed or not. Okay, so this is one of the solutions that actually came up from Prevent to protecting your websites from getting a 10% back, like cross-site scripting or data 10% back, because usually people can run sometimes, pre-vent something into your website and then they just read your user, your user data, read your cookies, everything off your website. So this is some, I don't think that it can prevent all, but it can prevent most of it. So, so how does it work, right? So it's actually very simple. It's only just one HTTP response header, and the response header is just content security policy. And then when, when users request for, for your website, and then it just send back to the user through, and then through the HTTP response. So, so when browser detects this like response header, then it's actually the browser that is enforcing the policy. So that's why that makes it even more lightweight. So what does it look like? So this is like an example I do from content security policy.com. I thought they, in their content security policy account, they must have like enforced content security policy, right? So this is an example. When you type content security policy.com in your browser and then you open your dev, dev tools and you look at the response header, you will see this. So, so this is an example of a content security policy. So how do you read, like in this example, it looks like it's very gibberish, like a lot of things, like some hash going on, some URLs going on and some like non-self thing going on. So actually how to read it is that the way that content security policy is constructed is it really starts from directives. So directives specify, there's one directive for almost all types of assets. And then it's split by semicolon. So you have the directive like script source and then all the values. And then after that, you have a semicolon, they have style source and all the values in a semicolon. So I think it's quite straightforward that script source just means that Java script sources and then style source just CSS style sheet sources, font sources for fonts, image is for image and frame is for high frames. So the way to read is pretty straightforward. So like I said, there's a lot of directives and then the police can be found here if you, the MDN also has, if you are very familiar with MDN like Mozilla developer network, they also maintain a documentation there, the specification there for content security policy, you will be able to find the full list of directives there also. So, yeah, so some of the things that is not shown in the previous slide like connect source, prefetch source, if you, you use all this in your work and then there's like a lot more like base URIs, blah, blah, blah. Yeah. So then just now we talk about the directive then why is the actual sources, right? So the actual sources comes right after the directive. So just a few types here you can see is like none, none is like you don't allow anything at all. Self allows like assets from your own origin, like for example, your website is called Ruby.sg and then you only allow assets from Ruby.sg, like JavaScript from Ruby.sg or CSS from Ruby.sg. So this like self, same origin. Then of course then you have the usual URLs that you whitelist that you and you can literally control the entire like saying that, for example, like I want to allow everything from hookeranalytics.com and then you then the browser would just let all this, all the sources from hookeranalytics.com to just run, execute for your website. So then again, like there's a lot, quite a lot of types of sources on top of the normal URLs, like for some examples, like the style is like a wild card and then you have HTTPS to only allow assets to load over HTTPS, then Shah is, Shah is a bit, I think most of y'all will be familiar with it, like JavaScript text already has this integrity HTML attribute that you put a Shah there where the browser will automatically check the Shah and then the script, whether the Shah of that script and then see whether it matches, if it matches then it will execute it. So in this case, if you put the Shah in your content security policy, then you don't need to put an integrity HTML attribute, you just put in your content security policy and your browser will do this Shah matching on the fly. Yeah, so, so now we talk about, just now we talk about like content security policy in general, but how do we use it in Rails? Actually in Rails, it's very simple. Since Rails 5.2, Rails have provided domain specific language for us to configure content security policy. And then if you are, Rails 5.2 onwards, when you do Rails new, you will automatically see an initializer, content security policy initializer in config dash initializers. So how does it look like? This is an example that I came up or I just edited or uncommented some stuff here. So like all Rails config is very straightforward, it's Rails called application config, content security policy, and then here you can see the directives and the sources, default source, image source, script source, and like the list goes on and on and then the directive goes on and on and on. And then after you policy dot default source, then you can specify all the sources that you want to allow. So like just now I said self was to allow same origin. So here image source, I also allow images from, that comes from Ruby.sg, and then you can add all the Shah, all the other URLs here, just common and then append and then just get it going. So this is a very, very simple DSL that Rails provide for us to use. So then after you implemented your content security policy, how do you know, like where do you see whether your website, anything is breaking or not? So because it's like enforced on the browser side, so you can easily just open your console and then your browser will just, you will see the error logs there for content security policy. And this example you can see that like the loading of the ruby dot sg asset dot png is blocked because of the image source, so as simple as this. The first one in Jack Global Hook is actually a Firefox extension. So it blocks that, so it literally blocks everything. So it's like a hard core lockdown of your website. So this is actually, this is something that I face at work and thought is very, very important about now it's like so easy to enforce content security policy, but then there's actually a danger of pre-virtual enforcement of it. You might find yourself getting a long call from your client, why this break, why that break, everything starts to break without you knowing. So actually one problem of pre-virtual enforcement is things will start breaking, even if it works on your computer, doesn't mean that it will work on the other people's computer or your client's computer or your user's computer because it's a browser side enforcement. So, and especially when you have like a lot of pages, your app is very big, you have a lot of types of assets coming from all over the place and all you let users load their own assets, put their own URLs, load assets and et cetera, et cetera. Then you, then the app might break for them but not break for you. So then this is one very dangerous thing to do, to pre-virtually enforce. So it's as if that the people who design content security policy knew about this problem. So then that's why they came up with this thing, report only mode, or maybe they went through this entire percent, that's why they came up with report only mode. So actually this report only mode, right, it doesn't lock down but then it still locks all the errors for you to see. So, so you can, you should always start from report only mode and then let your application run for some time and then to go and collect the errors in a while and then you, and then, then you can analyze all these errors and take some time to tune your content security policy until it's stabilized, then you can enforce it. Then you, this is the one way to make sure that it doesn't, it doesn't suddenly break for your users. So for report only mode, for in real DSL is also very simple. It's just like a flag to turn it on to true. So application config content security policy report only equals to true. And then you will see that the header switches from content security policy to content security policy report only. So it's, and then behind that is exactly the same. It's just the header changes. And then now it goes into a report only mode. But in a, so now you have report only mode, then how do you collect the errors? Just now I said you collect the errors in a while and then you take it all back and analyze and then you, and then you'll fine tune your content security policy. So here Rails also provide a report URI of a directive. So what happens is that your browser when it enforces the content security or you, or you just runs the content security policy on your website on the user's browser and then you turn on report. Whether you turn on report or not, it will still send a post request to whatever your report URI that you specified here. And then it will send a post request and then for example, in Rails, you can easily collect create a controller and a block to catch it. And then there you go, you will, you can start doing something by saving it in a database or collect it somewhere to analyze all these all these reports. So one example, just now I say it's a post request, right? So it's actually a simple post request format and then like in this example, I just do a JSON pass and then the request body string and you can see that it's just a hash CSP report, block URI and all the details of what broke, what, what is the thing that broke content security policy or violated the content security policy. So after looking at all these errors, you will be able to find you. So I actually wanted to go to, want to go to a demo and I need to show my screen because I need to show my desktop. Okay, so let me move this away. So actually I have a demo here and then I should have started this earlier. And then I have a website, it's back. And then we can see that like something is blocked. So actually I have an image here, it doesn't show. So here I actually wanted to show the report URI, content security policy. So I actually created a controller to catch this thing. And then let me just turn on the report only mode and because it's an initializer, I have to restart it. And here I want to report control. So here I have a route that actually just catches just the content security policy stuff. And then when I refresh okay, I'm skipping a lot of steps, but I just going to show you that now I have to allow the Ruby SG, oh, okay, I'm sorry, because I made it like report only, that's why I did that at first. So, so now I, so just now I commented this out, but then I actually commented the report only mode. So that's why the image appeared. But actually, like if I do it like that, I don't allow the Ruby SG to run the image to be white listed. There I shouldn't, so I shouldn't be able to see the image here. So this is, then when I allow it, so this is a very simple example, it's just one image. And then now the image should come up and then you will see that the console thing is gone. So there's some, still some like block stuff. I'm not going to go through it now, but it's actually, it's just like this simple content security policy. Yeah, so, so then only the other thing that I really wanted the demo is to catch it here. But I think you guys get the idea that once you catch the violation here, you can pump it into a DB or something and then analyze it and then come back here to fine tune it to allow some more stuff, blah, blah, blah. And then after when you're really, really done, you can turn off this, turn off the report only mode and then done. Content security policy enforcement is done. Yeah, so there's actually a very, a lot of talks, very good talks on it and then a lot of content on how to do content security policy, because I think that a lot of people got burned like doing it without prior people doing it before and telling them like where are the gaps that you should not fall in. So there's actually a lot of conference talks over over the past few years on this thing. So it's great to go and watch them. And then once you have content security policy down and falls in your website, you can really help protect your website from basic cross-site scripting attacks and like those people go and deface your website. It's kind of very basic attacks. So yeah, that's it for my talk for today. It's a very simple sharing and I hope that you guys find find content security is not useful for your work. It's not just Rails, any web servers as long as it's just enforced this hater and then all these things will take. Yeah, so that's all for my talk for today, content security policy. Okay, so for the next part, I dream we are almost at the end. And if anybody got any questions, I know I didn't want to put any time. You can ask in the telegram group and I will answer it there. So now the next part is like for jobs, if anybody have any looking for jobs or anybody like have any openings that you want to share, does anybody have? Nope. Okay, then I think we can move on. So the next RubyMeta is scheduled on the 15th. So if you didn't know that our RubyMeta is actually on the 3rd Thursday of every month. So it's very pretty simple to track just 3rd Thursday. It's always the 3rd Thursday. So please RSVP if you are coming and then I have opened a GitHub issue for it already. If you wish to share something, please go and comment there and then I will follow up with you. Or you can go check back to the issue if you are looking like you want to find out real time what the what's what talks are happening, et cetera. Yep. And then if you don't know all our Ruby SG channels, mainly the GitHub, Ruby SG organization, the Facebook group, Singapore Ruby Brigade, and then our Meta.com group, Singapore Ruby Group. So and then of course the Ruby SG telegram group. Oh, yep. That's it for today. Thank you all for coming and hope to see you all like in the next, next, next, next, next, next, next, all the other GitHub. Okay.