I expect that the way to attack SPW will be to write, not malicious code, but insecure code, code with some flaw in it that allows it to be used in a buffer overflow attack or similar. In essence, only part of the attack is subject to PeerReview?; the other part is the input which is entered on the fly to the insecure SPW over the web. This is the only way that I can think of to get past the PeerReview?. -- BayleShanks
Also, without a MeatBall:CommunityExpectation? to write good Wiki:UnitTests, the script could be undermined in unobvious ways. -- SunirShah
Good point. I'll put UnitTests on the RoadMap. -- BayleShanks
One could also imagine a user taking advantage not of SPW's primary server, but rather of other users who download SPW and run it locally in the process of modifying it. The advantage here is that presumably most modifiers won't bother with the OSLayerSecurity; so there is one less layer of security available. However, it seems to me that this would be harder to do than to attack the server; the reason is that the attack at the top of this page becomes impossible; the attacker is not able to enter a given input into the local developer copy of SPW over the web. Instead, the entire attack must be placed in the PeerReview?ed code.