There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these risks.
There's no reason for drivers to have an expiration date. There's no scenario where it makes sense for the configuration that Oculus stumbled into to be possible.
> There's no reason for drivers to have an expiration date
If you can license software with a definite expiration date, why can't you license hardware with a definite expiration date? And have your license enforced by the operating system? Imagine that I'm a company with a hardware product, and instead of selling that hardware at large expense, I rent it out, and provide drivers with an expiration date to enforce the terms of the hardware lease. If the lease is renewed, I'll provide new drivers with a new lease expiration.
Not that I'm arguing for hardware licensing, or arguing that it was what Oculus was trying to achieve and screwed up somehow. But there's a difference between "Microsoft built a feature some of their customers didn't know how to use" and "Microsoft built an anti-feature".
The driver signing system is not an effective way to implement an expiration date, if that is your goal. Driver signing enforcement can be disabled rather easily by skilled users. Licensing restrictions written into the code of the driver itself are harder to bypass. It also does not seem at all likely that Microsoft intended for the driver signing system to be usable as a time-based DRM mechanism like this.
I'm not being facetious, FWIW. I know a fair amount about PKI, in general (probably in more depth and intricate detail than the average HN'er, actually), but I'm not a developer and I know very little about code signing in particular (and even less when it comes to the Microsoft world of code signing).
I do find it kinda hard to believe that there's no use case whatsoever for this particular configuration (code signing w/o an included timestamp from a TTP), though. I certainly understand why a timestamp can be valuable (as it would in this case) but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.
As I said, though, I don't know enough about code signing specifically to know what these scenarios might be but I can't imagine there isn't even one of them.
> but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.
I can readily imagine a scenario where a driver with a signature but no separately attested timestamp should be acceptable. What I cannot imagine is a scenario where it is useful to treat a driver signed in such manner the way Windows currently treats the driver.
There's no reason for drivers to have an expiration date. There's no scenario where it makes sense for the configuration that Oculus stumbled into to be possible.