Dear Ryan, In outlining the two paths that I presented at the end of my previous email, I made sure to illustrate the choice between them as one that comes repeatedly -- a conscious choice that every time produces a small, incremental improvement, often through a tiresome and onerous process. Indeed I was trying to support slow, grinding iterations towards the better -- and that's not at all something that sounds to me like sticking out for only the perfect solution. And indeed I supported the subjective and deliberative path as often necessary and wise when time is of the essence. I find it very surprising that you seem to believe that I was arguing for perfection -- quite the opposite, in fact.
I do still believe that when we fall back to relying on mainstream news articles, with no obvious fallback in procedure, then it's reasonable for people like me to chime in and wonder about a potential lack of rigor. Every potential participant in this thread comes with their own misconceptions and lack of information, and I'm no exception, but I still find that my original source of concern holds. My impression at least is that it's produced a worthwhile and valuable discussion for everyone (in no small part thanks to your own time and effort). And of course, I don't mean to admonish anyone here with the points of discussion that I've raised, and I would certainly like to think that nobody feels admonished by anyone else so far in this thread. I am very glad that others are working slowly on the long term effort for better policy. I think these issues are fundamental to the Internet's safety and hope that I'll be able to help out more one day in whatever way I can volunteer. Thank you, Nadim Kobeissi Symbolic Software • https://symbolic.software Sent from office On Wed, Jul 10, 2019 at 9:59 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi <nadim@symbolic.software> > wrote: > >> Many times in this discussion, we have all been offered a choice between >> two paths. The first path would be to examine difficult problems and >> shortcomings together and attempting to present incremental--often >> onerous--improvements. The second path would be to just say that someone >> should trust us based on years of subjective experience. In many, many >> cases, the latter really is a wise thing to say and a correct thing to say >> (and I truly mean this); it offers a path through which judicious decisions >> are often made. Furthermore, it is often a necessary path to take when time >> is of the essence. But it is seldom the rigorous path to take, seldom the >> path that serves future engineers and practitioners in the field, and >> seldom the path that gives institutions the foundation and the standing >> that they will need in the decades to come. >> > > Hi Nadim, > > There's a phrase to capture the essence of what you propose doing. It is > that the perfect is the enemy of the good. Wikipedia even helpfully > contains a useful quote in the context of Robert Watson-Watt. > > It is important that, while these flaws are recognized and being worked > on, there is still a duty of care and community responsibility. There's > clearly a school of thinking, which you appear to be advocating, that the > best solution when something is less than perfect is to not do it at all, > since doing nothing is the only 'fair' choice. Perhaps that's not your > intent, but I want to highlight, you've repeatedly admonished the folks who > have spent years into understanding and improving the ecosystem that > they're not doing enough, or that it isn't rigorous enough. > > By way of analogy, which is admittedly a poor way to argue, it would be > akin to someone arguing that out-of-band writes should not be fixed, > because fixing OOB writes is not rigorous, and instead it should be > rewritten in Rust. While it's certainly true that rewritting in Rust is > likely to improve things, that's a bit of what we in the industry term a > "long term" effort. In the mean time, as pragmatic professionals who care > about security, long-term participants on this list are approaching both > pragmatic and long-term solutions. > > There's not much I can say about the claimed lack of rigor. It appears > that you were not familiar with long-standing policies or discussions, the > means of approaching both the short-term risks and the long-term, the > efforts to ensure consistency and reliability, and the acknowledged > near-term gaps that necessitate a pragmatic approach. It's a bit like > arguing that, since you have an OOB Write, the best path to take is to > either do nothing to fix it, and in fact continue writing more code in > unsafe languages, or do nothing until you replace it all. Neither, of > course, are paths of rigor, and neither are paths that serve future > engineers and practitioners in the field, nor do they give foundation and > standing to the trust and safety of users. > > A different parallel to take would be that ignoring these well-known, > well-documented limits to understanding would be a bit like ignoring the > well-known, well-documented limits of JavaScript cryptography, and > attempting to write a chat application in Javascript and promoting it for > human rights or dissident safety. While it's certainly a path one could > take, it's hardly a responsible one, just like it would be irresponsible to > ignore both the limits of audits and the fundamental role in subjective, > but thoughtful, evaluation of the risks comparative to the benefits. > > [1] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
