> people need to stop reciting this compulsively and take the time to think each situation through.
I believe that thinking has already been done, and the reasoning published. If you can refute the well-publicized arguments against JS crypto, then of course that would be productive and appreciated. Given the discussions that have already taken place, I believe the burden of proof now rests with those who support JS crypto, not those who oppose it.
To make an analogy: We "compulsively" assert that the earth orbits the sun. But that's not a cargo cult. It's a conclusion which we've confidently accepted based on the weight of the evidence.
> Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript.
If that's true, then SecureDrop might not be so secure. I'm not pointing to SecureDrop as a gold standard. There are very few cryptosystems I trust.
> The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.
That might be true, but then again it might not. We don't know much about JS crypto. We don't know what attacks are possible. (We know about compromising the JS source, but that's only one threat model. There could be others that are unstudied.) Thus, it's quite possible that there are attacks which depend on the application using a specific browser feature, such as drag-and-drop. Is this likely? Not terribly so. But is it possible? Absolutely.
But I'm sort of nitpicking. Like you said, JS can be MITMed, so there's not much point in debating whether a given JS crypto app is secure or not. The best strategy is to just not use JS crypto.
I believe that thinking has already been done, and the reasoning published. If you can refute the well-publicized arguments against JS crypto, then of course that would be productive and appreciated. Given the discussions that have already taken place, I believe the burden of proof now rests with those who support JS crypto, not those who oppose it.
To make an analogy: We "compulsively" assert that the earth orbits the sun. But that's not a cargo cult. It's a conclusion which we've confidently accepted based on the weight of the evidence.
> Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript.
If that's true, then SecureDrop might not be so secure. I'm not pointing to SecureDrop as a gold standard. There are very few cryptosystems I trust.
> The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.
That might be true, but then again it might not. We don't know much about JS crypto. We don't know what attacks are possible. (We know about compromising the JS source, but that's only one threat model. There could be others that are unstudied.) Thus, it's quite possible that there are attacks which depend on the application using a specific browser feature, such as drag-and-drop. Is this likely? Not terribly so. But is it possible? Absolutely.
But I'm sort of nitpicking. Like you said, JS can be MITMed, so there's not much point in debating whether a given JS crypto app is secure or not. The best strategy is to just not use JS crypto.