Browser Games Aren't an Easy Target
jakob.space
jakob.space
> So… the WebAssembly is essentially generating JavaScript on-the-fly. Of course, all renditions of the code do the same thing, but the variable names are changing. [...]
> So it seems the WebAssembly module is doing some sort of tampering checking, [...]
I remember various discussions when WASM was specced about the danger of WASM blobs being used for code obfuscation.
The fears were dismissed with the argument that WASM is easy to decompile and that there is a textual representation to preserve "view source" functionality.
And yet, as soon as WASM is practically usable, we get this - an application that uses WASM solely because it is hard to inspect in the browser.
This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.
... but Flash was easy to reverse too, just download the .swf file and use one of many tools to reverse engineer it. It's probably why there are so many "hacked" flash games available if you search for them.
Until now, the general understanding for the web platform was that code that runs on a user's machine is also inspectable by that user. A large number of browser functions are developed with that understanding in mind.
You can argue that this practice should be changed, but that would be a rather fundamental change to the way the web works and the advantages and disadvantages should be discussed.
As a practical point: I don't condone cheating in multiplayer games, but the exact same obfuscation techniques that a game might use for legitimate reasons are also available to malware. If you make a general rule that programs should be hands-off to everyone except the devs (and browsers should change their tools accordingly), the same benefits will be given to malware.
You chose to execute someone else's code by visiting their website. The mere act of voluntarily executing someone else's code doesn't entitle you to it's source. Feel free to not visit the site, and looking at the top Alexa sites, your insistence of code audit-ability would leave you with very few viable, high quality choices.
> general understanding for the web platform was that code....
Untrue. It just so happened that the early web was a collection of static documents, and js was a hack to add some trivial functionality. Only recently has the web turned into a full fledged app development platform.
> fundamental change to the way the web works ....
Again, this is an anachronistic view of the web. We're well past a collection of static documents
> the same benefits will be given to malware ...
Goes without saying that technology can and will be used for good and bad. While one can legislate to discourage the bad, simply demanding code to be open sourced, as an argument for deterrence is unture, inaccurate and hampers innovation.
In summary: No one is entitled to someone else's web app code.
I block JS by default until I get at least a basic understanding what the site wants to do. So I explicitly choose not to execute their code before I have some reason to trust the site.
> Untrue. It just so happened that the early web was a collection of static documents, and js was a hack to add some trivial functionality.
And yet every browser has a "view source" button and extensive developer tools to give users the ability to both inspect as well as change what the website is doing. Not to mention extension ecosystems that are all about tampering with website code.
> ...and hampers innovation.
Given how the web platform is still going strong after 30 years and in fact is one of the dominant and fastest-innovating software ecosystems today, it evidently didn't.
Actually, "view source" can be a driver of innovation by giving novices an easy way so see and experiment with real-world code and a way for the broader community to quickly learn from each other's mistakes: https://blog.codinghorror.com/the-power-of-view-source/
Just to be clear, you can pick any x86 binary and disassemble it to x86 assembly, and if you know your way around gdb, single step and view registers,etc. This is not evidence of "all programs were meant to be open source, else we'd not have disassemblers and debuggers"
And lastly, how you choose to enable/disable js is of zero relevance to arguments for/against open sourcing web apps.
But then the only difference is unobfuscated wasm vs unobfuscated javascript. In both cases an obfuscation can easily hide the scary bits anyway.
I know a lot of time and effort goes into game development, and that I should take the time to appreciate the rhythm of the story and the nuances of the gameplay... but I am an addict.
I don't casually play games. I'm all in, or not at all. I will play day and night until a game is finished and then I will move on with my life. As an adult with a full time career I can't do these marathon sessions anymore, and so cheating is a great means for me to accelerate through a game, tick the mental block of completion, and then be refreshed Monday morning with my mind focused on work.
Hard to resist that nagging thought, though.
If you build a multiplayer game then come back to "deal with cheaters" only a few months before launch (or heaven forbid, after launch) you're probably going to end up taking the easy route by using invasion ~~spyware~~ DRM solutions, which don't stop cheaters once it's broken. To contrast, designing the game around cheaters means you might actually implement sane networking design, such as nearly everything being server-authoritative, aka. "never trust the client". If your client is broken in to, the best your cheaters can do is script the game (scripting cheats are currently the only ones available for Dota2 and probably League of Legends) or see a small amount of information that's otherwise unknown (for dota 2 you can see which enemy illusions are fake, for example).
Of course this approach can be taken too far, eg. in Call of Duty: Modern Warfare (the new one) sometimes your camera positioning can lag due to packet loss; this probably stops some aimbots but things like camera orientation probably shouldn't be handled server-side.
If it's a single player game, then who cares?
I liked the idea you had Flash off by default and you enable it only for the page or section of page you liked, I am running now Vivaldi with Javascript off by default because we have a even more garbage experience now with JS, like on BBC news with JS off the links are broken (wtf the web developers can't even create a working link without JS)
There are many reasons your link may not work. Why do you assume incompetence?
The problem is not JS the language but how it is abused and similar to Flash you get people installing plugins or turning it off in settings and white-listing JS on necessary pages, in my case I will not read the article most of the time or use a private window.
I completely disagree with this, if I'm understanding you correctly. As someone who disables Javascript, I don't want you to purposely break a page that previously worked (in the sense of being able to read the content of the article) simply because a portion of it which I might not even use doesn't work.
The fully competent solution would be to use progressive enhancement[1] (i.e., use functioning anchor elements initially, and use Javascript to add the Javascript-only functionality on top of the HTML solution).
If you don't have time for that, the somewhat-competent solution for alerting non-technical users that Javascript is disabled would be to add a banner at the top of the page (like Stack Exchange does) stating that some features will be broken without Javascript.
Recent addition of our timeline editor means we think it ticks all the boxes as a replacement.
There's also a handful of forums, gamedev.net tigsource and others.
StackOverflow is a common place to search for answers, if you can find questions asked about "what can I use instead of flash" without coming across as an advertisement.
Then Adobe bought it and duct-taped it to the Creative Suite and switched to a subscription-based business model.