Re: Don't load third-party scripts
5. If it's marketing driving this adopt some combination of 1 and 2 and charge the work to their budget.
Thousands of websites around the world – from the UK's NHS and ICO to the US government's court system – were today secretly mining crypto-coins on netizens' web browsers for miscreants unknown. The affected sites all use a fairly popular plugin called Browsealoud, made by Brit biz Texthelp, which reads out webpages for blind …
> Concretely, what this means, is that they should host their own instance of the service
That messes with Browsealoud's business/licensing model - and it's far from a cheap product. Browsealoud pre-dates the (W3C) Web Speech API which is supported by all current browsers, trivial to implement and should have made the product redundant anyway.
I really wish I could do this 100% of the time. But then, if the customer needs 'google maps' embedded on the page, for whatever reason, you can just have a *teensy* bit of script to support it.
> Just about every non-trivial website on the planet loads in
> resources provided by other companies and organizations
Really? OK, adverts. But other than that? Surely at least many of them are self-contained. I hope.
If you are going to use 3rd-party code, you've got a difficult decision to make: import it from the 3rd party when the page loads and you're vulnerable to the 3rd party going down, getting hacked etc. But on the other hand, if a security issue is found then they may be able to fix it without you having to take any action. Copy the code to your own server and you'll find you've not kept up with updates and you get hacked....
"Copy the code to your own server and you'll find you've not kept up with updates and you get hacked."
Why are so many updates required (it seems to be a given in a number of comments)? If it's because the code is a bundle of bugs you'd be better off not having it. If it's because of new "features" (did someone say Agile?) then those updates may be adding more vulnerabilities, not removing them.
If you've tested your site and it functions correctly why would you auto deploy updated dependant files? How do you schedule regression testing? Watch all the third parties for when they change? May as well host the files yourself. You can't be serious about your site is you'll let multiple third parties update bits of it independently...
An interesting idea.
If a scumbag-in-the-middle is 'enhancing' code as it flies down the fibre from the CDN to your server, then signatures could be useful. But if the miscreant has managed to corrupt an official upgrade somehow then you're still stuffed.
There are times I have happy dreams of going back to debugging 10,000 lines of COBOL in the daily accounts overnight batch job. Life was simpler then...
Apparently, you don't understand how signatures work. The keys are referred to as the "crown jewels", and held MUCH more tightly than what they sign. Of course, a complete compromise of your network will (probably) get them, but not all hacks get that far. In particular, you can hack the site that hosts my code all day long, you won't get anywhere near my hosts with my keys.
When China got insiders and exflitrated data from Google, the crown jewels were not touched. And that was before Google started to talk seriously about security.
Much though the fans of crypto currency would like to ignore it - and setting aside the security issues that lead to this particular incident - isn't stuff like this an almost inevitable consequence of the way crypto currencies work?
If you create a system that is based on the premise of "swap processor time for currency" then there are going to be a lot of people who will try to find ways to grab time on other people's processors, for their own gain. Whether it's hacks like this one, emailed worms, or something else, the incentive is going to motivate many people to have a try, and get "free" money.
"If you create a system that is based on the premise of "swap processor time for currency" then there are going to be a lot of people who will try to find ways to grab time on other people's processors, for their own gain. "
This was one of the biggest worries of the camram-spam mailing list around 20 years ago - and in that case the currency (hashcash) was "merely" the ability to deliver email.
Biting the hand that feeds IT © 1998–2019