Hmm, most of these don’t really apply here? Like, it’s not like we are proposing to do anything complicated. We are just saying “throw in some kind of sample function with a 5:1 ratio, ensure you can’t get redraws”. I feel like I can just audit the whole trail of implications myself here (and like, substantially more than I am e.g. capable of auditing all of our libraries for security vulnerabilities, which are sadly reasonably frequent in the JS land we are occupying).
My point is less about the individual example than the overall decision algorithm. Even if you’re correct that in this specific instance, you can verify the whole trail of implications and be certain that nothing bad happens, a general policy of “figure it out on a case-by-case basis and only do it when it feels safe” means that you’re probably going to make a mistake eventually, given how easy it is to make a mistake in this domain.
I am not sure what the alternative is. What decision-making algorithm do you suggest for adopting new server-side libraries that might have security vulnerabilities? Or to switch existing ones? My only algorithm is “figure it out on a case-by-case basis and only do it when it feels safe”. What’s the alternative?
For site libraries, there is indeed no alternative since you have to use some libraries to get anything done, so there you do have to do it on a case-by-case basis. In the case of exposing user data, there is an alternative—limiting yourself to only public data. (See also my reply to jacobjacob.)
Hmm, most of these don’t really apply here? Like, it’s not like we are proposing to do anything complicated. We are just saying “throw in some kind of sample function with a 5:1 ratio, ensure you can’t get redraws”. I feel like I can just audit the whole trail of implications myself here (and like, substantially more than I am e.g. capable of auditing all of our libraries for security vulnerabilities, which are sadly reasonably frequent in the JS land we are occupying).
My point is less about the individual example than the overall decision algorithm. Even if you’re correct that in this specific instance, you can verify the whole trail of implications and be certain that nothing bad happens, a general policy of “figure it out on a case-by-case basis and only do it when it feels safe” means that you’re probably going to make a mistake eventually, given how easy it is to make a mistake in this domain.
I am not sure what the alternative is. What decision-making algorithm do you suggest for adopting new server-side libraries that might have security vulnerabilities? Or to switch existing ones? My only algorithm is “figure it out on a case-by-case basis and only do it when it feels safe”. What’s the alternative?
For site libraries, there is indeed no alternative since you have to use some libraries to get anything done, so there you do have to do it on a case-by-case basis. In the case of exposing user data, there is an alternative—limiting yourself to only public data. (See also my reply to jacobjacob.)