Talking about website security with Matt Shearing

Website Security with Matt Shearing from A Digital transcript powered by Sonix—the best audio to text transcription service

Website Security with Matt Shearing from A Digital was automatically transcribed by Sonix with the latest audio-to-text algorithms. This transcript may contain errors. Sonix is the best way to convert your audio to text in 2019.

Matt:
You've got a responsibility to your customers if you're taking their data and the way I look at it is your website helps you to run your business in the same way that you might have an iPhone. You're not still on an iPhone 4 or 5. They get slow after a couple of years and you have a need to update them so you can still use all the latest features. And it's similar to that with websites.

Andrew:
Hello, everyone. Welcome. You're listening to the Clientside podcast, which is the show that bridges the gap between clients and their digital or creative agency. I'm your host Andrew Armitage, and if your job is to look after the day to day digital activities or manage your company's website, then you're in the right place. Whether you're part of an in-house team for a well-known brand or you're working for a small business. You'll find helpful tips and techniques to make sure that you're getting the most from your digital activities. If you're here for the first time, welcome. It's great that you can join us. We're delighted to have you here. Today, we're going to be getting a little bit techie, but please don't let that put you off. In fact, the conversation is more about why we need to have techie conversations, because we'll be talking about the implications of owning a website that has fallen out of date. Now, we're not talking about your website having lots of old content in it or the fact that you might not have written a blog post for six months, but something that is far less obvious, and that's how to date it is with new software releases, security fixes and compatibility with third party services. It's a subject which is often misunderstood, I think, really, because for most clients, it's something that is out of sight, out of mind. But things can undo break with technology and sometimes for no obvious reason at all. So I'm joined today by Matt; welcome to the show, Matt.

Matt:
Hello.

Andrew:
This is your first appearance on the Clientside podcast, so do you want to just introduce yourself and tell people a bit about your role with A Digital?

Matt:
Of course. I've been here for quite a few years now and I'm a web developer. I tend to do a lot of the server-side stuff and focused a bit on page speed more recently. Often you'll find me just writing PHP, database queries, JQuery. So all the techie sides that make it functional.

Andrew:
Yeah, great. So website maintenance can be a bit of a tricky subject to get your head around because it's something that can't be seen. In particular, people that are using a website on a day to day basis don't necessarily see it. So why is it so important that web sites are kept up to date from a technical point of view?

Matt:
So the main issue is security on top of. If a service updates itself and we've not changed any code on the site, suddenly it might just stop working. So for a client, it's a case of, well, we've not got any work on the site, but suddenly it's broken. They've not changed anything and it's hard to explain why that's happened so far. As a bit of understanding of, okay, well, things have moved on a bit. We need to keep it up to date to keep it compatible. Otherwise, we'll start losing functionality. On top of that, you've got all the security issues as well. If someone can get at the data, we need to close those doors.

Andrew:
Yeah, sure. Now, before we get into some of the specific reasons for maintaining website, we ought to say that this conversation, it mainly applies to certain types of websites. So if you have a website that is an all in one hosted package such as Wix, SquareSpace or Shopify, then those platforms will often take care of core updates anyway. That's all part of the package that you subscribe to. So that makes life easier to do a degree, but that doesn't necessarily mean that you can just let that site to run and run forever because there might be certain bits of code in the templates which wouldn't be taken care of by that particular platform. So you will still have to apply some sort of maintenance to any type of site. So I think for the purposes of this discussion today, the type of sites we're really talking about might be a WordPress site, possibly Joomla site or in our case, most of our sites run on a platform called CraftCMS. So these will be sites that are hosted on a server somewhere and most likely have been built by an independent designer, a developer or an agency. You have some of these platforms actually might have a setting that allows them to dated automatically. But as we've seen some times, Matt, that's not a good thing, is it?

No, absolutely not. Also, this could apply to custom build applications such as Code Igniter, Laravel. So just to cover those as well, it's not just CMS's.

Let's just break down a couple of things that you've said there. You talked about CodeIgniter and Larawel and CMS's. We said it was going to get a little bit techie, but we don't want to frighten people away, so CodeIgniter and Laravel, they are both what we call development frameworks, aren't they? So just explain what we mean by a development framework and what that might mean for a client because they won't necessarily know what it's been built on.

Matt:
So we use language called PHP to make websites; websites can be made in other languages as well. Instead of writing absolutely everything from a start point of nothing, we use a framework where things like a log in functions and base checking can already be done for us. It packaged up. We then extend that functionality to make it do what we need it to. On top of those frameworks can then be used by other companies to build CMS's (content management systems), which we can then use such as CraftCMS instead of having to build the entire thing ourselves. We are then customising it for each client's use cases and extending it where needed where we go back to write and core PHP to put extra functionality in.

Andrew:
So we're really talking about these frameworks have been a little bit like scaffolding. You can put the scaffolding up around a plot of land and then you can build your house up in the middle of that completely customise that house to however you want it to look whatever sort of rooms it might have inside. But you've got that scaffolding around it that helps you build it.

Matt:
And if you run out of room, you need a bit more land. So that's where we can then extend it.

Andrew:
Great. Okay. So with these frameworks in place, you know, things change, don't they? And I think the key thing around maintenance is that you can build a website in the same way I suppose you can build a house. It's what happens sometimes around that house, around that website that changes. It's the environment in which sets and that can cause problems, can't it? So, yeah, I think one of the specific examples that we've seen more recently and I wouldn't mind betting that a fair number of people who are listening to this have probably come across this themselves, but Google Maps, for example, they changed something on their API fairly recently, didn't they? So an API is the way that websites talk to each other essentially, and you know Google made a change that meant the way maps displayed on a website no longer just worked in the way that they were once did.

Matt:
They changed their billing setup, essentially. So a lot of maps suddenly got this watermark on them saying for development purposes only. If you own this site, please contact us.In fact we saw that in a museum didn't we.

Andrew:
Yeah, we were at a web conference in Berlin last year and some of the interactive displays were using Google Maps and it was quite obvious that they had fallen foul of that, they had not updated the Google Maps API.

Matt:
So in that instance, they might not have seen it themselves. But certainly all of the visitors to that museum were experiencing that. And it would be the same case for a website. Any visitors that are seeing that, it's going to be affecting them and their usage.

Andrew:
And what's actually quite frustrating from our point of view as an agency is, we don't get an email from Google do we that says, oh by the way, this is going to happen on such and such a date? Sometimes, you know, for larger sort of things that might have a greater impact than we do get notification and something around payment gateway changes, which is coming up later in September, is one example of that. But that has a more fundamental impact on how website works. With the Google Maps example things. It just broke. It didn't stop working. It just continued to work, but in a slightly broken fashion.

Matt:
It was quite grayed out and difficult for people to read. But essentially you could use it, but it wasn't ideal.

Andrew:
But let's just think about something like this SCA. So SCA stands for –.

Matt:
Strong Customer Authentication.

Andrew:
That's right. So payment providers like SagePay, World Pay Stripe, even PayPal, I think are all been impacted by a new European ruling around how online transactions are protected for fraud, essentially, aren't they? And that has meant that a lot of the payment gateways have had to change the way they work. Personally, I don't feel that's been well communicated either, but has at least been some communication and we have had some details around the types of changes that are going to be seen in the process of collecting an online transaction. But we've really for some of those things, we've been forced into a bit of a corner haven't we to apply updates. What type of thing have we typically found around those types of updates that unfortunately it's not been as straightforward, oh well, we can just flip that switch or we can just download some new software. It's been a little bit more involved in that based on the experience that we've had with a few different gateways hasn't it.

Matt:
So, in particular with SCA, it's kind of adding two factor authentication, which you're probably familiar with when you log into sites, they send you a text or an email with a code. That's going to be the case for making payments for all customers. So if you've not implemented that, your payments, won't work on the website anymore because the bank will straight up refused. Now to get that working, it's not just a case of flicking a switch as you say, we've got to build in these additional fields. We've got to send it off to another location to receive that code as well, where it's accepted as a response. So there's a bit of work to do around with different responses, fields, all this kind of gateway side.

Andrew:
In a nutshell, there's extra too-ing and fro-ing isn't there as that transaction.

Matt:
Yeah, it's not just a simple tick box or field with a value.

Andrew:
No, no. So that I think we'll catch quite a lot of people out. You know, even though there's been some communication from payment providers, I haven't seen communication from all the payment providers and even are looking more widely in the media, you know, there's certain suggestions that you have some businesses will, in effect, go off line because that's the challenge that they face. The website will still be up, but if the payments suddenly stopped working, then that's obviously going to cause a problem. And if that happens, once those changes have been implemented, all of a sudden they're forced into making the action.

Matt:
Yeah. And if they're not in a position to make that action, if the communication is broken down or they've not got I.T. department, that's sufficient to do that, it could be that the website's no longer viable if it can't take payments any longer.

Andrew:
Yeah, and I think what's particularly challenging is for small retailers, because unfortunately this inevitably adds extra cost, doesn't it? Yeah, but it is part of managing a website; if you want to take payments online, you got to follow the rules of the payment providers.

Matt:
And it's quite hard as well when payments have been working for, say, five, six years for a site and then all of a sudden we say, oh, we've got to do some work on it. And they think, well, why? You know, it's quite hard to get across that it's not us forcing that change on them, it's the industry, if you like, as the standard as a whole.

Andrew:
Yeah, I think that is difficult because it was the outcome of that. The outcome is the same really as what is happening on the website today. Somebody can check out today, the 14th of September is the deadline for this secure customer authentication, isn't it? And after that day, so long as you've made the upgrade, the same outcome applies. Customers can still take still place an online order and place that transaction.

Matt:
Yeah. So for the owner of that website, it doesn't look any different. There's been no design changes or anything to the checkout process. It's all pretty much the same as they see it, but they spent this money, but they can't see the return from that.

Andrew:
So what about some of the other issues with keeping a website up to date? I think the other big one that stands out for me is security. I mean, we've talked about security around payment, but that's really been around the data that must be submitted to payment gateways for this new SCA rules. But payments aren't the only type of data that websites collect, of course.

Matt:
No absolutely. So a checkout example is quite a good one because we've put in quite a lot of data into a website where we checkout. We're putting in an email address, telephone number (sometimes it's optional, sometimes required), and a lot of time all of you address details. So to make sure that these are stored correctly, it's quite important because especially if GDPR are being enforced now, if somebody managed to get at that data and they had your email address, telephone number and your address and your name, they could commit fraud and all sorts of things, especially if there's any card details stored as well. So there's definitely a case of having to keep your data secure because also the fines for not doing so is very high. I'd argue you've got to keep it secure because a lot of businesses, if you said to them, can you afford a 2 percent annual global turnover fine or 10 million, whichever is more if you can afford that, then you can be flippant about your data security, but most people can't.

Andrew:
No, it's not just about affordability either. It's brand reputation.

Matt:
Absolutely.

Andrew:
that can go with that. You know, British Airways was a recent case, wasn't it? There's been a couple of high profile cases where the Information Commissioner in the UK has started to take some action around enforcement for various breaches and data security.

Matt:
So essentially if your brand can't afford that kind of reputational damage and your business certainly can't afford the fine, we need to make sure that is kept secure. Now to do that, I've been looking at a few stats around the web industry as a whole and a lot of sites are running on PHP and you can find these stats yourself over at https://w3techs.com/. They've got technologies on that and there's versions of PHP that are now considered end of life and some of these versions were considered end of life as of 2016 or earlier. And 26 percent of the internet currently is running on PHP that was end of life 2016 or earlier. So that's just over a quarter of the Internet that has been passed security updates for about three years now because it's 2019 at the point of recording this. So that's a big one for me. Upgrading your PHP version. And that won't just be helping with security of a site that will also help speed. I've also been looking at some speed benefits and cloudways.com have benchmarked this. So they did PHP 5.6 versus 7.0 over five minutes. The average hits were 34 a second compared to 53 a second. So you can essentially double your traffic without having to increase the size of your server. It can handle more and it will load the pages a lot faster and that will help you in many ways with your website. And we've done a few blogs about Page Speed which you can read into and see the impacts on bounce rates. But it's not just security upgrading your PHP version will help with a little, it will also be performance. So I'd strongly recommend that as a starting point.

Andrew:
Okay. So just backtrack again ever so slightly. PHP we said earlier was one of the languages that sits on a server.

Matt:
Yeah.

Andrew:
Basically it does all the heavy lifting, all the calculations, all the understanding which bit of content to show where all that kind of stuff doesn't it. But because it's doing that transactional stuff from a security point of view, if there's any gaps in there that potentially makes that information available to other things or it could be sort of intercepted.

Matt:
Yeah. So quite common. One is you could have cross site scripting with JavaScript that can set cookies and server values and essentially falsify a submission to get some data back. And you can also put some malicious code into input fields and return full databases where you can actually put a full queries into their return, and return anything you want, and sort of skip through the code that way. Hackers have been finding ways of doing this and every so often they publish a list of all of the security flaws that a version will have and upgrading to the next version should fix most of those flaws. But you can check these flaws online. There's a CVE checker and it shows how many security flaws that are unfixed for each version that's out there.

Andrew:
Ok, so that's definitely something that an IT team or a technical contact might want to look at, but I think from a client point of view what we're really saying is that if your site is running PHP and because it is running loads of sites, has a fair chance that it might be, if you're running WordPress, Joomla or CraftCMS or ExpressionEngine or a variety of other content management systems, they will all be running PHP really underneath the system that they're running. So you've got PHP on the server, you've got, say, WordPress or Craft as the content management system, and that's where your content goes.

Matt:
Yeah.

Andrew:
So what you're basically saying is if I'm running a website, it's not just about updating the website itself. I also need to be mindful about what's happening on the server.

Matt:
Yes, absolutely. The way I see it is that you wouldn't leave your house unlocked if you knew that somebody else had a key out there for your house and you'd locked it, you'd change for locks. That's kind of at the level the PHP is. It's not the inside of a house have painted the walls and things like that. It's the actual structure itself that everything sits on top of, and within.

Andrew:
Okay. So you're saying that these PHP versions that they have they have a fixed life span? Is that what you're saying essentially?

Matt:
Every single year there's a new version released. And I think on average, they last for two years until they go to just security updates and then they get a further year and then they're end of life so they don't even get security fixes. As of recording this we are currently on 7.3, 7.4 is going to be released in October or November this year, but as of now, doing that, check on w3techs.com I could see the 49.75% of websites on the internet are still on PHP version 5.

Andrew:
Wow.

Matt:
So they've got quite a few versions to go. That's nearly half.

Andrew:
As a website user, let alone a website owner, that's quite frightening statistic, isn't it really? If you think about the types of all the websites that we might use, OK, it's not going to be the Asda's, the Tesco's or the British Airways type websites, but perhaps smaller independent retailers that might be less familiar with this type of thing, they won't have dedicated in-house resource to provide that technical support. That's really frightening if they're collecting that information. I'm inputting my data into those types of sites, but also if they're dependent on that site for their business to run, they are, we do want to be alarmist about this, but they could potentially, potentially be on a little bit of a knife edge, couldn't they? If there's a vulnerability that is identified within any of that code. Then they could quite easily fall victim to some sort of attack.

Matt:
100%. So essentially what I'm saying is if you've got a site that was built more than two years ago, you've got a 50/50 chance of being on PHP version 5. You've got a 50/50 chance anyway. But if you've had it built in the last two years, you developers should have put you on version 7 at the least.

Andrew:
You're likely to be on something more up to date. OK. And I think actually something that really needs to be enforced here, that if you lets say you that you are running a WordPress site, you might have had it, lets say, lets say you've had it three years. The problem with just updating WordPress and other content management systems is you're updating the core code, but you're not actually changing your PHP version on the server.

Matt:
Correct.

Andrew:
So you might be merrily going along and updating, applying all these updates to your Web site. But if that's running on an outdated version of code on the server, then you're still leaving part of that door open, aren't you?

Matt:
Yeah. You think that you're covered and that you're safe, but you're only doing half of the jigsaw. So it's there's another piece of the puzzle we need to look at. A lot of the time now as we're going on when you update, they will set a minimum required version of PHP, which forces you down an upgrade route, but not all of them do this. So it is still worth checking as well.

Andrew:
So we've talked a bit about general security. We've talked about how third parties can force these types of updates on you. What about someone who might have had a site for, let's say it was built maybe five years ago? They might not have really kept it all that up to date. But let's say that they are wanting to do a little bit of extra work on the site now to prepare it for some new functionality that they might want to add, or a new product that they might want to be adding to the site. What sort of problems might that cause?

Andrew:
Yes. So we've seen recently with this SCA regulation being introduced, having to get ready for that by 14 September. In some sites that we've been running, there's a case of it being on old software because it's not been updated in so long, that some of the changes we want to make won't be supported. So first we have to update the version of that software and the PHP version before we can then move on and make the change that we wanted to. So that's down to a compatibility issue at that point. So if it's quite an old site and it's not been updated for a while, you might run into that as a bit of a roadblock where you need to either do a full site update which could take some time to make sure everything still works and plenty of testing or just to rebuild.

Andrew:
We've got a phrase for that where we know that it's technical debt.

Matt:
Absolutely. So that's a case where you might have been extending it to do extra things, but it couldn't do out of the box. And eventually over time, say, five, six years down the line, you've got so much extensions in there, but it starts to run slowly. You start to look through the code and you can find lots of optimisations to be had, you're falling into errors and you've built up so much debt to get that functionality in there when it wasn't meant to be. You're now at the point where there's so much of it you need to write that debt off and just start again.

Andrew:
Yeah. And I think even if you haven't been adding lots of functionality and sort of building layer upon layer on layer, you know, even if the site is by and large, as it was after the box when it was first built, it's still not necessarily a straightforward thing just to say, oh, well, we can update it to the latest version.

Matt:
Absolutely not. The latest version might be, say, three or four full releases ahead. Not just like point one to point two. I mean, like version 2, up to version 3, up to version 4, up to version 5. That could be the case, in which case the codebase has probably changed a few times. So to actually make it compatible, it could be easier and cheaper and less time intensive to just move it to a different CMS and rebuild it.

Andrew:
So CMS. We're talking content management systems, which is...

Matt:
Yeah, WordPress, Craft? All of these kinds of–

Andrew:
They all fall into content management systems, don't they.

Andrew:
So essentially what you're saying is that larger upgrades can become more problematic if you leave something for several years and you've got to jump from version 2 to version 5.

Matt:
Yes.

Andrew:
Rather than going from, say, version 2.5 to 2.6 to 2.7 and then perhaps to 3. It's not plain sailing, I think is what you're saying.

Matt:
Yeah. Because from 2 to 3 to 4 to 5, they could have changed the actual framework underneath it, which we spoke about earlier. So you've got PHP then you've got your framework and then you've got your CMS. So as an example, Craft runs on Yii and Symphony; I know this is getting a bit technical, but say...

Andrew:
They're other frameworks aren't they.

Matt:
Yeah. Say they moved away from Symphony to something else. And for argument's sake we'll say CodeIgniter, I doubt they ever would, but for arguments sake, if they did that the way that we've written the functions within our extensions that would all have to change.

Andrew:
And extensions., we're really talking about customisations aren't we.

Matt:
So any case where we've put a little plugin because it doesn't do something out the box where we've had to add it, we've done that ourselves using core PHP on top of that framework. So if that framework then changes, we need to change all the way we've written that bit as well. The template code of how it calls data out of a database might have changed as well.

Andrew:
So all in all like you say, I suppose the point of been blocked off that future direction, that future roadmap that you might have thought you could follow is essentially cut in half because you've got to a stage where there is so much technical debt. Actually, you've just really got to write it off and think about starting again.

Matt:
You get stuck in a point where you've got to decide if the upgrade is still the right way to go, or if you just start from fresh and import the data into it. And a lot of the time that can be a lot better because then you're shaking off a lot of the old debt that you might have had and just start afresh and building it exactly as it needs to be for your needs.

Andrew:
Okay. So it's a bit of a tricky one, isn't it, because all of this costs, there is a cost to to keeping things up to date. It's very much like owning a car I think you buy a car and the last thing you want to think about is then having to pay for servicing and garages will always do this. You buy a car on then straight away they want to talk to you about servicing plans and you think well hang on I've just bought a brand new car I shouldn't be talking about service plans already, but we kind of we've been tuned into how cars work and how they need to be maintained to ensure that their reliability continues essentially. And actually what we're saying is it's it's pretty much the same thing with a website. You know, from time to time, it's going to need a little bit of maintenance. It's going to need an MOT to check things over, at some point it might need new tyres. All of those things apply to a website that all unfortunately are going to have a bit of cost, but ultimately is about is thinking in the long term picture is about prolonging that website's life and also protecting the data that might be in it, the way people use that site so they can feel confident and positive about it being secure for holding their personal information. Very few websites these days actually store cardholder information, most of know, goes across to the payment gateway. But even so, I wouldn't particularly want my phone number address, email address and all that sort of thing to be...

Matt:
On an insecure platform.

Andrew:
Precisely.

Matt:
No you've got a responsibility to your customers if you're taking their data and the way I look at it is your website helps you to run your business, in the same way that you might have an iPhone. You're not still on an iPhone 4 or 5. They get slow after a couple of years and you have a need to update them so you can still use all the latest features. And it's similar to that with websites, PHP frameworks, because it's helping you run your business you need to keep it up to date and keep on top of it to get the best out of it that you can.

Andrew:
Ok. So what might people be able to take away from this conversation? Obviously, they should have realised now that it's something they need to be doing. What sort of steps? I suppose the first thing might be to have a look inside the content management system. Look on the dashboard or whatever page you're directed to when you sign in and I suppose that's really going to be the first clue, isn't it? Because there should be some sort of flag that says there's updates available.

Matt:
And if there isn't, most content management systems should at least say the version number and it'll take 2 seconds in Google. Just put the name of the content management system in and see if that is the latest version. If it's quite a way behind, then you should probably have a discussion about that. The next step would also be to contact the people that are responsible for your site and find out what version of PHP you are on. You can easily find on PHP.net what the current version is so you'd see how many steps behind you are from that as well. They've actually got a nice end of life chart as well that shows coloured bandings of each year for each version that they actually went out of end of life. So you can very quickly and easily see if you're still supported for security updates or not.

Andrew:
Okay. So yeah, it sounds like supposed to simply stop to speak to your developer, whoever it was that built the site, whether it was an agency or an independent freelancer. But if you have lost contact with that person, as we know, as we see from our own experience, that does happen then as you've just said, you know, perhaps have a look at PHP.net. Or at least think back to when the site was built. You know, has the site moved from one server to another since that point in time? Because if it hasn't, then more than likely it will be sat on technology that was current back when that site was built and it's probably dated by now.

Matt:
It might be you've got an in-house team or something, you've kept the same hosting environment, but you've had a new say relatively recently past year or two. But it's still in the same environment on the same box. And that might be running an older version of PHP. We've seen we've shared hosting platforms that they do start withdrawing these PHP versions after a certain amount of time. So at that point, you need to make sure that you are up to date because if they just withdraw it, you site won't work.

Andrew:
That's gone, isn't it! Potentially overnight

Matt:
So it's better to be proactive about this than waiting for it to break. So really, people ought to be thinking of having some sort of monthly or annual maintenance plan to just provide a little bit of time each month. I mean, what sort of frequency we're talking about for these sort of releases and I guess it depends on each platform doesn't?

Matt:
PHP releases are one per year. Each content management system will have a completely different release cycle. But certainly for one that we predominantly use of Craft, they're releasing I'd say, 2 to 3 times a week, they put out a new release so we can go in once a month and keep it up to date and do some tests on a dev site, make sure everything's still work and then ship it.

Andrew:
Yes. So it's not necessarily a case of having to be kept up by the day, is it?

Matt:
No, absolutely not.

Andrew:
If there's three releases a month. Is that something that could feasibly done, let's say, on a quarterly basis?

Matt:
Absolutely. There could be larger releases held within that. A lot of them will be, say, 1.0.0 to 1.0.1. It's when they go from 1.0 to 1.1. That's a bigger marked release. It's still not as big as say 1.0 to 2.0. but we've seen with I think it was 3.1 to 3.2 there's lots of author experience changes within the CMS.

Andrew:
And that was specific to Craft, isn't it?

Matt:
And there's a lot around drafts and things like that. And we have a site with custom draft work on it and we have to do a fair bit testing to actually get that up speed. But that's purely due to the nature of that kind of update they've released. They've sort of stored up all of his changes to go in a big release.

Andrew:
So, I mean, that highlights a point around possible breaking changes as well. Things can break as a result of these updates. Yes. Actually, on the one hand, you're doing it to improve the longevity of the site and to ensure it's continues to be robust and secure. But actually you can introduce breaking changes.

Matt:
Yes. So a lot of these updates will be a case of just a click of a button updates, everything works fine, let's go. Because it's a security fix or something minimal. Sometimes there is a breaking change where you get tags that you need to change, ways that it needs to work a bit differently where you've restructure your data a little. It doesn't take too long to get it working again, but it's just something to be mindful of.

Andrew:
Yeah. And you just use the words then a security fix. If they see, if people go into their content management system and they see some sort of red alert that says there's a security fix available, should they be frightened about that? Is that something to panic about?

Matt:
It's not something to panic about such because it's a case of they've found an issue where if somebody chose to exploit it, they'd be able to get in through that route. They're closing off that loophole. That doesn't mean that instantly someone's going to be on your site trying to do it, but I'd still advise that you shut that loophole because it's like, you wouldn't want somebody outside in the world having a key to your house whether they know where you live or not, eventually they could get in. They probably won't. But it's better just to change the lock at the security fix to make sure it's all okay.

Andrew:
So really, we just wanting to have a belt and braces approach isn't it, and I think all about being proactive rather than reactive. Being reactive puts you on the back foot. It might cost you not just in terms of money, but in terms of time. If you suddenly have to make a sweeping change on your site within 24 hours or worst case scenario, because something's already broken. That doesn't necessarily mean that you can just suddenly pick up the phone and development work can be done immediately. You know, there could be certain prerequisites, certain testing and things like that. That could mean you could actually be sort of a couple of weeks before you're in a position to actually make the upgrade and go live with changes.

Matt:
If you're in a position where you don't have an agreement in place and you're waiting until something breaks to get it fixed because you think it's going to be cheaper in the long run, that will cause stress, frustration for your customers and also for yourself while your site isn't working and that's going to be lost revenue until it's fixed. And it might not always be a quick fix. So we like to have a development site where we can test these changes before we push them out live so we can get it all in place before your site even breaks. Instead of waiting for it to happen.

Andrew:
Yeah. Okay. Good advice. Okay. Well, we're coming up to time. So hopefully that's been a useful episode. Website maintenance can get technical, as you have heard. So hopefully we didn't go into too much detail. If you do have any questions though, we're more than happy to offer any guidance. Please feel free to get in touch. You can just drop us an e-mail too. hello@adigital.co.uk. As we said, our experiences with a particular platform called CraftCMS, but that doesn't necessarily mean that we can't give advice on other platforms and that type of thing. And you know, it's strange because I can feel quite at home looking at website issues, but I'm quite keen biker. But if something breaks on my bike, I'm absolutely hopeless. I'm not just someone who should be allowed to fix my own bike. Perhaps it's just a lack of confidence, but personally, I'd far rather someone else looked at it so I could be confident I'm not going to get stuck in the middle of nowhere and face a long walk home. So yeah, I think it's definitely be worthwhile speaking to your developer or agency whoever built the site for you in the first place and just perhaps just ask them for a bit of an MOT; a quick overview. Is the version of the site up to date? Is the server up to date? Are there any proactive steps that you could take to make sure that the site is as secure and stable as it can be?

Andrew:
So thanks for joining us again today. Please tell other people who you know about Clientside podcast. We'd love for you to leave us a review on iTunes as well. In fact, we've we've had a couple of reviews over last few days, so we'd love to know what you think and get some feedback. Finally, if you want to benchmark your own digital marketing performance in your business, I'm pleased to count our online scorecard. It'll take you about 10-15 minutes to complete, but you'll get a personalised breakdown of how you're doing in four key areas sent back to you by email, as well as giving you some actionable tips that you'll be able to use straight away. So just head across to https://scorecard.adigital.agency to find out more. That's it from us today. Thanks for sharing your thoughts.

Matt:
You're welcome. Thank you.

Andrew:
Thank you, everybody. We'll look forward to seeing you on the next show in a few weeks time.

Quickly and accurately convert audio to text with Sonix.

Sonix uses cutting-edge artificial intelligence to convert your mp3 files to text.

Thousands of researchers and podcasters use Sonix to automatically transcribe their audio files (*.mp3). Easily convert your mp3 file to text or docx to make your media content more accessible to listeners.

Sonix is the best online audio transcription software in 2019—it's fast, easy, and affordable.

If you are looking for a great way to convert your mp3 to text, try Sonix today.