On the machine that is asking for the macro to be executed.Jagged wrote:Is it appropriate to ask where the JS will run? On the client or on the server?
Even that is not "secure", depending on your definition of that word. It's possible for the server to be running a hacked version of MT for example (since source code is readily available). Since the JS must be readable to the engine, even if it were encrypted somehow MT would have to decrypt it before giving it to the engine so somebody who wanted to cheat could hack MT to display/modify the code at that point.I mean the only way to make the stuff truly secure is to run it on the server.
This is essentially what GreaseMonkey does for Firefox; it allows a JS programmer to add/change/remove JS code that the web server sends to the browser. I use this for a couple of sites that are broken and need to be fixed to work properly.
MT will only allow the GM to create JS macros, but a player could run a hacked version of MT that allows them to add their own macros. It's not practical for us to obfuscate the process just to discourage such cheaters.
Our primary goal in terms of "secure" is to ensure that the stock MT will not allow access to local files or make network connections to machines other than the server (the same basic kind of "sandboxing" that browsers do) without explicit approval from the user. For the time being we've wanted to avoid having a popup in the middle of the game that says "So-and-so macro wants to create a file in directory such-and-such. Do you want to allow it?" That would get annoying very quickly and users are just going to click OK every single time anyway (which is why UAC is such a failure). So we currently protect them from themselves by not allowing macros to write to local files at all.
At some point we may revisit the "secure" aspects again, but it's always easier to be conservative and loosen the reins later than to be loose and then tighten them.