Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browser Games Aren't an Easy Target

jakob.space

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Browser Games Aren't an Easy Target

#41

Post by bostonvaulter2 »

marcus_holmes wrote: post #33
redka wrote: post #24

It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…

that does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that. Hard to resist that nagging thought, though.

On the other hand people don't like playing a multiplayer game when other people are badly hacking.

Re: Browser Games Aren't an Easy Target

#42

Post by throwGuardian »

xg15 wrote: post #16

> So I went back to the debugger and placed some breakpoints around where the WebAssembly module is loaded, realizing that its only purpose is to deobfuscate the JavaScript that eventually makes it into that "SOURCE" pseudo-file I saw earlier. [...] > 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. [...]…

Why should someone be forced to make their IP "open" just because someone else on the internet feels entitled to read and potentially copy/modify/... their code?

Re: Browser Games Aren't an Easy Target

#43

Post by redka »

p1necone wrote: post #39
redka wrote: post #24

It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…

The only way to stop players from cheating in a multiplayer game is to make the server the authoritative source for any information you want to stop players from messing with. If it's a single player game, then who cares?

The games are multiplayer and the server is authoritative. That doesn't mean the games can't be played with cheats, eg. wall-hack, auto-aim, etc.

Re: Browser Games Aren't an Easy Target

#44

Post by ghusbands »

marcus_holmes wrote: post #33
redka wrote: post #24

It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of chea…

that does kinda feel like premature optimisation. First make a game. Second make a game that people want to play. Third make a game that people want to hack. Then maybe look at stopping them from doing that. Hard to resist that nagging thought, though.

And, as with premature optimisation, mantras don't communicate any of the subtleties around the fact that many concerns can influence your code at the same time.

Re: Browser Games Aren't an Easy Target

#45

Post by xg15 »

throwGuardian wrote: post #42
xg15 wrote: post #16

> So I went back to the debugger and placed some breakpoints around where the WebAssembly module is loaded, realizing that its only purpose is to deobfuscate the JavaScript that eventually makes it into that "SOURCE" pseudo-file I saw earlier. [...] > 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. [...]…

Why should someone be forced to make their IP "open" just because someone else on the internet feels entitled to read and potentially copy/modify/... their code?

Because the code is being executed on my machine, with my data, using my online identity.

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.

Re: Browser Games Aren't an Easy Target

#46

Post by throwGuardian »

xg15 wrote: post #45
throwGuardian wrote: post #42

Earlier quoted context omitted.

Why should someone be forced to make their IP "open" just because someone else on the internet feels entitled to read and potentially copy/modify/... their code?

Because the code is being executed on my machine, with my data, using my online identity. 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 th…

> Because the code is being executed on my machine, with my data, using my online identity.

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.

Re: Browser Games Aren't an Easy Target

#47

Post by xg15 »

throwGuardian wrote: post #46
xg15 wrote: post #45

Earlier quoted context omitted.

Because the code is being executed on my machine, with my data, using my online identity. 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 th…

> Because the code is being executed on my machine, with my data, using my online identity. 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.…

> You chose to execute someone else's code by visiting their website.

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/

Re: Browser Games Aren't an Easy Target

#48

Post by throwGuardian »

xg15 wrote: post #47
throwGuardian wrote: post #46

Earlier quoted context omitted.

> Because the code is being executed on my machine, with my data, using my online identity. 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.…

> You chose to execute someone else's code by visiting their website. 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 ha…

The presence of "View Source", or extensions, or the ability to modify js is not evidence backing "All web apps need/were-meant to be open 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.

Re: Browser Games Aren't an Easy Target

#50

Post by p1necone »

redka wrote: post #43
p1necone wrote: post #39

Earlier quoted context omitted.

The only way to stop players from cheating in a multiplayer game is to make the server the authoritative source for any information you want to stop players from messing with. If it's a single player game, then who cares?

The games are multiplayer and the server is authoritative. That doesn't mean the games can't be played with cheats, eg. wall-hack, auto-aim, etc.

Yeah, you need to have another (more invasive/fragile) solution for things that involve scripting input like auto-aim. Wallhacks can be prevented by not sending location data for units that players shouldn't be able to see though.
Post reply on HN