After Java

[oNyx]

@elias4444

Well, I’ve been looking into the whole javascript (and webGL) thing. I’m impressed by how much faster it runs these days and some of the game demos I found out on the web (especially the HTML5 stuff). I’m curious though as to how one could “secure” it for use with “online” functions (like posting high scores, or multiplayer). Seems like anyone could just take a look at the code, save it, edit it, run it again and do whatever they want with any server feedback code.

Is there a way to prevent such easy hacking?

Using JavaScript doesn’t change anything there. Everyone can just use a sniffer and check what’s going on. If you use a minifier (you should for the bandwidth savings alone) the code is about as readable as decompiled obfuscated Java.

After minification it will look like this:

http://code.jquery.com/jquery-1.4.2.min.js

Of course you can then run it through some auto formatter, but that won’t help much. No one will bother anyway, looking at Firebug’s net panel is a lot more convenient.

It’s the same thing with Java or Flash. Whatever you send to the server, the client can always log it.

[JL235]

[quote=“oNyx,post:61,topic:35232”]
You could always encrypt.

[Riven]

@JL235

You could always encrypt.

The browser needs to execute the code.
The browser needs to decrypt the code.
The browser needs the key.
The client knows the key.
The client can decrypt the code.

Oh, and clientside security will never work.

[Orangy_Tang]

On Javascript:

I’ve always quite liked it as a language, although like oNyx mentions it’s something I’ve messed around with without taking the time to properly ‘learn’ it. My issues have always been with the implementation - the speed was always terrible and browser quirks rendered it fragile and even more “write once test everywhere” than Java.

However this seems to be rapidly changing - particularly Chrome’s V8 seems to have given most of the other browsers a good kick up the rear end and now javascript is reaching acceptable speeds. Browsers still seem to be very quirky but there’s a good handful of libraries that seem to do a good job of hiding these, and the canvas tag should improve things still further. So in a couple of years javascript-the-programming-experience (as opposed to javascript-the-language) could well be a much more pleasant experience (or even now, depending on how much you need to worry about compatibility and older browsers).

[JL235]

@Riven

The browser needs to execute the code.
The browser needs to decrypt the code.
The browser needs the key.
The client knows the key.
The client can decrypt the code.

Oh, and clientside security will never work.

Agreed.

But if you add username/password into the mix you can use the password as the key for encryption. When submitting highscores username can be sent both as plaintext and encrypted together. Server can verify it’s the user they claim to be by looking up their password using the plaintext username and then unencrypting the message to get their username a second time (only the person with the password could have encrypted their username). Server can then challenge the user using an encrypted nonce to prevent replay attacks. Note that the password is never sent.

There are also alternates, the user could send their username and receives back a key to use for future encryption which is encrypted by the server. Nonces are also included to prevent replay attacks. This is used in Kerberos.

@elias4444

Well, I’ve been looking into the whole javascript (and webGL) thing. I’m impressed by how much faster it runs these days and some of the game demos I found out on the web (especially the HTML5 stuff). I’m curious though as to how one could “secure” it for use with “online” functions (like posting high scores, or multiplayer). Seems like anyone could just take a look at the code, save it, edit it, run it again and do whatever they want with any server feedback code.

Is there a way to prevent such easy hacking?

Multiplayer games are usually run on the server with the client being a dumb front-end. In theory it doesn’t matter if the client is decrypted and hacked apart because it’s just dumb client. The server just ensures all inputs it receives are valid.

[jezek2]

@Orangy Tang

… and even more “write once test everywhere” than Java.

Which applies to any crossplatform development. Write once, run anywhere is more or less a lie. Some kind of apps (eg. LWJGL based games) need little to none tweaks and generally just work as intended, but GUI applications are very different matter. You really need to test on all platforms and make changes for each platform as each OS has slightly different concepts (Mac OS X being the most different). If you don’t do this you’ll deliver a poor application, for every OS (maybe except the one on which you’re developing).

Having good crossplatform libraries can help, for example I want to experiment with some higher level abstraction for PureSwing that would help in developing crossplatform GUI apps with having (quite) different GUI structure based on standards for each OS. But while it would help, the testing everywhere still applies.

[delt0r]

Write once run anywhere is not a lie as such. Just oversold. It was oversold in the perception that a compliant L&F CDE app would not need any changes to be a windows L&F app vers a Mac L&F app.

If you are not doing L&F gui’s its pretty good. I don’t need different TCP bindings etc. In terms of a basic GUI its also far easer. But if fine details of platform specific L&F are important then I think swing is just as bad and just as good as any other widget library I have had the displeasure to use.

Personally I hate how pedantic people are with L&F. Its like “pixel perfect” web design. Lame.

[jezek2]

@delt0r

Personally I hate how pedantic people are with L&F. Its like “pixel perfect” web design. Lame.

Please note this is not L&F issue this time, but more high level thing, eg. Mac OS X has quite different concepts for GUI, like having completely different layout and content of dialogs or how are some tasks done by user. In fact Mac OS X was big eye opener for me when it comes to writing crossplatform applications. Windows and Linux applications seems to differ in just few details so it’s mostly just matter of L&F.

[Orangy_Tang]

@jezek2

Which applies to any crossplatform development. Write once, run anywhere is more or less a lie.

Oh I agree, you’ve always got to test on the platforms you release on, but there’s a difference between fixing bugs because you used an API incorrectly (which is what I find most of my java cross-platform issues are) and the flat out browser incompatibility and mess that javascript has.

[delt0r]

[quote]…Mac OS X has quite different concepts for GUI, like having completely different layout and content of dialogs or how are some tasks done by userMac OS X has quite different concepts for GUI, like having completely different layout and content of dialogs or how are some tasks done by user
[/quote]
I would still call this L&F. However i think we probably both agree that other widget toolkits don’t address this problem any better than java(Cross platform ).

The pedantic bit was more of a Linux/windows user thing i noticed with my old work. Quite a lot of people get really upset if the font is not the one they think it should be for example. In a word processor, fine… but in high end banking software… Just change it!

Just for the record. I have not needed to support much mac beyond a working GUI. We have been able to expect users to work with the different “L&F” mostly.

[Markus_Persson]

@JL235

Agreed.

But if you add username/password into the mix you can use the password as the key for encryption. When submitting highscores username can be sent both as plaintext and encrypted together. Server can verify it’s the user they claim to be by looking up their password using the plaintext username and then unencrypting the message to get their username a second time (only the person with the password could have encrypted their username). Server can then challenge the user using an encrypted nonce to prevent replay attacks. Note that the password is never sent.

In no way does this prevent me from sending in a score of ten billion.

[JL235]

Dispite all my criticisms, and all of the issues I’ve had writing cross-platform Java, it is still easily the best platform I’ve ever used for cross-platform development. 99% of the time it really does ‘just work’ across all platforms.

My biggest complaint is that the fake native look & feel is not default. Sun seem to have this bizarre idea that pushing their own Java look & feel is a good thing. They have made excellent UIs, but they are not on par with the Windows or MacOS! People also tend to have a very negative stereotype towards Java apps. IMHO foreign look and feels of the same quality usually always feel worse, simply because they are different. The brushed metal UI for Safari is a good example. Looks great on a Mac (it fits), looks terrible under Windows (really stands out). The various alternate MS look and feels (i.e. Office and Windows Live messenger) get away with this because they are essentially the same with improvements, so they still fit.

@Markus_Persson

In no way does this prevent me from sending in a score of ten billion.

It’s easier for you to be tracked and banned from doing so a second time.

[Riven]

@JL235

It’s easier for you to be tracked and banned from doing so a second time.

With your encryption, you are only making sure nobody is tampering with the connection between the browser/useragent and the server. When the useragent is mallicious, it is not tampering with the connection, it simply sends invalid data. Data integrity/correctness wise, by no means this yields any advantage over sending plaintext.

[Markus_Persson]

@JL235

It’s easier for you to be tracked and banned from doing so a second time.

If that’s your goal, then there are much easier solutions already in place, such as having a sign in form and a session id. There’s no need to encrypt anything in order to know who sent it.

And besides, what if I send in the maximum theoretical score for your game? How will you know I cheated?

Encryption solves none of your problems (in this case).

[JL235]

My suggestion to use encryption was in response to oNyx saying that anyone can just use a packet sniffer to listen to the packets being sent across a network. Encryption aims to solve this issue, that’s why I suggested it.

@Markus_Persson

If that’s your goal, then there are much easier solutions already in place, such as having a sign in form and a session id.

I suggested adding a username in my response, requiring the user needing to signup.

But tbh there are plenty of existing topics where we can discuss ways to encrypt highscore boards. Lets not take this way off-topic : )

[pron]

Google’s decision to implement O3D on top of WebGL is yet another sign that the client side is converging on the browser and “html 5” technologies. This could be bad news for Java, but then again - maybe not.
First of all, it would reinvigorate OpenGL as the most widely used graphics API at the expense of DirectX, which would mean better OpenGL drivers. JOGL and JWGL developers would clearly benefit.
Second, and this is a wild hypothesis (or wishful thinking, perhaps), the rise of “html 5” and fast JavaScript could make Java the only real alternative for web-deployed software. I believe Flash (and Silverlight for that matter) doesn’t have much to offer on top of html5, but Java has some advantages. It would be much more performant than JavaScript in the near future at least, it has a multitude of libraries and power-features, and provides a much nicer development experience, especially with JavaFX script which is a joy to use compared to browser technologies (or Flex).
True, Java applets and WebStart apps won’t get any more common, but they could become the de-facto standard whenever some true heavy lifting is required client-side. All this, however, is dependent on Oracle delivering some much awaited features for Java/JavaFX soon - especially improving the user experience vis-a-vis loading time and installation

[VeaR]

I don’t like the direction the Web goes. JavaScript is basically the assembly language of Web. Why are we using a high-level browser-embedded (possibly interpreted) language for (about) everything? All those applications growing on the Web are Html and JavaScript. I find this approach a waste of resources. We can have MS Word (or OpenOffice) text processors compiled from C++ to optimised machine code. Or we can have runtime-compiled and optimised Java, but no, we are going with Html and JavaScript.

I have researched Web (Html+JavaScript) games a bit. In display complexity i would say they currently equal to desktop games of around 1993 (before OpenGL arrived). With Html5, embedded video, and 3D, Web (JavaScript) games would reach display complexity of the early OpenGL games (Quake II). So basically Web games are 15 years behind.

I cant understand, why is it so hard for all the parties to standardise on a common platform which is more effective. I mean, why is the Web (Html+JavaScript) the only platform commonly accepted?

Besides driving the 3D display from JavaScript, JavaScript programs running 3D graphics are more complex too. In this regard the mobile platforms are not suitable for running JavaScript. One article showed that the iPhone has very bad JavaScript performance. So you may be able to play video (and make Web games with prerecorded videos, like those around 1995), but you wont be able to do 3D in JavaScript on mobiles.

I think the future is in video streaming. There are already two such services. It is possible to rent a game (from the game “cloud”), and to stream display&audio trough the net to you, and controls back to the server. Mobile net will soon reach speeds of 50-100Mbps, and video streaming will become more viable.

Right now Google, Amazon and others are providing services for running applications in the “cloud”. I think we will have “game clouds” too. That means, make a game which plays on a desktop computer, with full DirectX 11/OpenGL 3 capabilities. Publish it to a “game cloud”, and serve it to anyone with a web browser, TV device, or mobile device. Running games on clients computer will become irrelevant, the client computer will become just a cheap “terminal”. I can imagine that new game API’s will be published, specifically for making games run from “game clouds”. Possibly game engines (like the Unreal engine) will have such “game cloud server” functionality built into them.

[Riven]

Running games ‘in the cloud’ has many advantages for the clients, and massive disadvantages for the developer/hoster: scalability is horrible and expensive. Maybe, maybe you have 10 players concurrently playing on 1 dedicated server, and that’s that.

And then there is lag. Network lag (twice), frame rendering, video compression, video decoder, for every controller-input event. No FPS in the cloud!

[pron]

Well, cloud FPS’s are (almost) here: http://www.onlive.com/. Apparently on fast enough connections latency is acceptable.
I agree hosting them should be very expensive. Not so much hosting the CPU work - servers have better cost-effective CPUs, but I don’t see how you can get around dedicating a GPU per (active) player. Maybe those new NVIDIA Tesla farms can help: http://www.nvidia.com/object/preconfigured_clusters.html

[Riven]

@pron

Well, cloud FPS’s are (almost) here: http://www.onlive.com/. Apparently on fast enough connections latency is acceptable.
I agree hosting them should be very expensive. Not so much hosting the CPU work - servers have better cost-effective CPUs, but I don’t see how you can get around dedicating a GPU per (active) player. Maybe those new NVIDIA Tesla farms can help: http://www.nvidia.com/object/preconfigured_clusters.html

There is marketing and there is reality

No matter how cost-effective those server CPUs are, it’s far less costly not to run the games on the servers in the first place. I think this topic has been beaten to death for several times now, and the FPS genre is simply not well suited for ‘remote execution’… even on LAN-like speeds/latency.