This is not equivalent at all. You don’t need to create a GDPR notice because the user types their personal info into their own documents for example, despite you being on the path of it going to disk.
Most of these bugs are far worse than that, actually. SQL injection lets people mess up your database but most of these let you get root on the box, which means not only can they mess up your database but they can also make your SQL installation mine crypto and grab your SSH keys while they’re at it. This is why kernel bugs are generally considered to be quite bad.
I’ve always felt that the problem after finding all of these is that you’re going to have to patch and upstream them. I assume you’ve probably asked your models to do that but at this rate you’re probably bottlenecked on people to review these and then the kernel maintainers are likely also heavily time constrained on their side to do the same. What ideas do you have to improve this situation? Do you foresee a process where you’re not just finding an ever increasing number of bugs and instead can bring that number down with different approaches to attacking the problems (e.g. designing new mitigations?) I don’t really see this described in your career listings so it’s hard to tell what you’re doing in preparation of better models :)
I'm a little confused how this is even feasible to do in general. Most inference is batched and often implemented on heterogeneous hardware. In this environment, it's hard to get bitwise identical results, much less prove that the results came from a certain model. Is this actually practical? In the post near the end it doesn't seem like the authors think they have done anything for this and it seems pretty important for it to be used for any production environment.
I guess if you truly don’t care about it sure, this is probably going to be an improvement, but if you are willing to invest even a bit of effort I strongly think you’d want to decide how your website looks like in dark mode.