Node/JavaScript Security Tech Culture

Solving the Node Buffer Constructor Deprecation Problem


With the EOL (end of life) of Node 4.0 and the introduction of Node 10 coming in April, it’s time to look at that perennial Node problem: what to do about the Buffer constructors.


The CPU Bug: When being clever bites us in the butt


Ars Technica has produced the best write up on what’s happening with Meltdown and Spectre.


Two days ago, the tech world ran into a wall. Probably the best summation of the event is the following tweet:

Yes, this is about the CPU bug. The CPU bug. The bug that demonstrates that sometimes being clever isn’t the same as being smart. The one that gave us Meltdown and Spectre.

I’m not going to repeat what others have reported, including The Register, the VergeBusiness Insider, and Google. But I wanted to specifically point out a New York Magazine piece because it does a good job of explaining why your IT person is currently under the desk, sobbing. Money section:

So basically every computer in the world is broken for the foreseeable future?
To quote Reverend Lovejoy: Short answer, “yes” with an “if.” Long answer, “no” with a “but.”

We’re likely looking at a world where there are pre- and post-Spectre processors. The lead time for new processors is measured in years, so there aren’t going to be quick fixes. There will be continuous software patches as new Spectre vulnerabilities are found in the meantime.

But the root of the problem for both Meltdown and Spectre is one of unforeseen consequences. Guessing what your computer is going to need to do next is a tremendously clever and relatively cheap way to speed up processors, and once it was discovered, Intel pushed aggressively to see how far they could go with it. (This is why Meltdown has hit Intel so hard.)

Designing processors and computers is an extremely difficult and extremely expensive proposition, and the market incentive for manufacturers is always going to be speed, not security. Even after Spectre disappears from the landscape, it’s a near certainty that some other vulnerability will show up on the scene.

In the meantime, stuff is getting patched. Not fixed…patched.

Microsoft just released an emergency patch (which just showed up on my PC, time to update), the current version of Firefox protects against vulnerabilities, upcoming Android and Chrome updates should help in these environments, Intel is putting out patches, and the fixes go on.

But we’re in this one for the long haul.

Security Server Web Technologies

Moving to HTTP/2

I upgraded my server to Ubuntu 16.04, converted my websites over to HTTPs, and locked them in using HSTS. It would be a shame to stop here without making one last change: upgrading to the HTTP/2 protocol.

The web has been spinning along on HTTP 1.1 since 1997. It’s been a good and faithful servant. However, the protocol is also showing its age, leading to gimmicks and workarounds just to more readily process today’s web pages.

Security Server Web Technologies

Moving to HTTPS: First, you upgrade everything

I was one of the lucky folks who received an email from Google warning me that it was going to start marking input fields in my sites as unsafe. “Time to move to HTTPS”, it smugly informed me.

It irks me that we’ve given a company such power over us that it can force us into using technology before we’re ready. However, I knew it was a matter of time before I’d have to go to HTTPS, so decided to just bite the bullet and get it done.

But if I move to HTTPS, I’m making the task a component of an overall site upgrade.  That was my original intent all along…incorporating HTTPS into a total site makeover. Except my plan was to finish by year-end, rather than October. Best laid plans…