Every feature request has a constituency – some group who wants it implemented, because they benefit from it. Simplicity does not have a constituency in the same way, it’s what economists call a non-excludable good – everyone benefits from it. This means that supporters can always point to concrete benefits to their specific use cases, while detractors claim far more abstract drawbacks. The result is that objectors to any given feature adition tend to be smaller in number and more easily ignored. Leading to constant addition of features, and subtraction of simplicity.

I agree with the premise, but challenge the idea that it’s not possible to deny feature requests.

source: HN

I would like to credit C++‘s smart pointer types, because they do significantly help. Unfortunately, my experience working on large C++ projects which use modern idioms is that these are not nearly sufficient to stop the flood of vulnerabilities. My goal for the remainder of this post is to highlight a number of completely modern C++ idioms which produce vulnerabilities.

source: L

There’s a publicly visible patch for the Chrome bug, however there aren’t a lot of details on the Windows kernel bug. The Google team states that they think it may be only possible to exploit this bug against Windows 7, and not newer Windows versions -- even if the bug does exist there. I want to use the remainder of this post to explain reasons that is -- based on the information we have.

It’s very common to think about computer security primarily in terms of fixing vulnerabilities. In reality, security teams spend a lot of their time on a different goal: making bugs hard to exploit. This often takes the form of lowering privileges and introducing exploit mitigations. Windows 10 has a lot of investment in those areas, whereas Windows 7 doesn’t contain any of the improvements made in the last several years. That’s why even though Windows 7 continues to receive security bug fixes from Microsoft, it is considerably less safe to use.

source: L

Given the gaping chasm between what was expected and the massive success of OSS-Fuzz on ImageMagick and GraphicsMagick I thought it would be helpful to review what factors I thought were contributing to OSS-Fuzz finding so many vulnerabilities and other bugs:

source: HN

So I decided to take a stab at writing down the things I want to see happen in 2019, in the hopes that the universe will provide a few of them. I’ve attempted to make each of these be something that could realistically be accomplished in a year, and I’ve include some success criteria for each one.