Wouldn’t this be circumvented by performing Step 5 followed immediately by Step 4 before running the script? (Of course, the level of inspection necessary to determine what’s going on in the script may be high enough that you may as well write your own script by that point.)
It wouldn’t be every time you run the script; you would just need to vet it the first time. I expect that anyone using this for serious security purposes would just save the script locally. The point of this is that it’s browser-based, not cloud-based. Saving an HTML + Javascript file with a (admittedly rudimentary) GUI is infinitely easier than downloading a command-line based program.
Yes, presumably this danger could be mitigated through a combination of code inspection and sandboxing. But, one of Nanashi’s stated motivations for developing this was that “I had yet to find an easy way to do this that didn’t involve downloading command-line based software”. I doubt that anyone who is adverse to running a command-line program would be very excited about inspecting a javascript application for security vulnerabilities and/or sandboxing it each time he/she wants to sign a message.
As much as I dislike blindly following rules in most cases, I think that ChristianKI is correct that any security-related web application ought to be secured via SSL.
I think what I could have been more clear about was the use case here: this tool in its current form is sort of “pre-Alpha”. Previously the script was just sitting locally on my computer and I thought it could be useful to others. If I ever try to deploy this on any sort of larger scale, absolutely it will be done on an SSL server. But for right now, it’s just being shared amongst a few friends and the LW community.
If it turns out that people are using the tool frequently, I’ll probably go ahead and pay to upgrade my hosting plan to SSL. But for something that’s a free tool not meant for wide distribution, which takes about 7 seconds to right click and hit “Save As”, I just didn’t see it as necessary just yet.
Understood. Obtaining an SSL cert is a hassle (and an expense if you obtain it from a cert authority) that may not be warranted for a pre-alpha release. As long as your users use discretion before signing using their “real” private keys, I don’t see any issue.
Thanks for making these available; the Decoy app sounds particularly innovative.
Wouldn’t this be circumvented by performing Step 5 followed immediately by Step 4 before running the script? (Of course, the level of inspection necessary to determine what’s going on in the script may be high enough that you may as well write your own script by that point.)
The scenario that everyone runs Step 5 and Step 4 everytime they run the script is unrealistic.
It wouldn’t be every time you run the script; you would just need to vet it the first time. I expect that anyone using this for serious security purposes would just save the script locally. The point of this is that it’s browser-based, not cloud-based. Saving an HTML + Javascript file with a (admittedly rudimentary) GUI is infinitely easier than downloading a command-line based program.
As a robot, I prefer cloning a GIT repo and installing from source.
Yes, presumably this danger could be mitigated through a combination of code inspection and sandboxing. But, one of Nanashi’s stated motivations for developing this was that “I had yet to find an easy way to do this that didn’t involve downloading command-line based software”. I doubt that anyone who is adverse to running a command-line program would be very excited about inspecting a javascript application for security vulnerabilities and/or sandboxing it each time he/she wants to sign a message.
As much as I dislike blindly following rules in most cases, I think that ChristianKI is correct that any security-related web application ought to be secured via SSL.
I think what I could have been more clear about was the use case here: this tool in its current form is sort of “pre-Alpha”. Previously the script was just sitting locally on my computer and I thought it could be useful to others. If I ever try to deploy this on any sort of larger scale, absolutely it will be done on an SSL server. But for right now, it’s just being shared amongst a few friends and the LW community.
If it turns out that people are using the tool frequently, I’ll probably go ahead and pay to upgrade my hosting plan to SSL. But for something that’s a free tool not meant for wide distribution, which takes about 7 seconds to right click and hit “Save As”, I just didn’t see it as necessary just yet.
Understood. Obtaining an SSL cert is a hassle (and an expense if you obtain it from a cert authority) that may not be warranted for a pre-alpha release. As long as your users use discretion before signing using their “real” private keys, I don’t see any issue.
Thanks for making these available; the Decoy app sounds particularly innovative.