Reply to post: Re: Java*.*

ASLR-security-busting JavaScript hack demo'd by university boffins

bazza Silver badge

Re: Java*.*

"Then the black hats will simply proceed to crack your instance of the server side application."

Er, the point is that a client user wouldn't have an instance of the app at all on their own hardware. The app would remain on the server.

It's far easier to secure a fully defined remote display protocol than to guard against arbitrary code that may or may not be malicous. If all that's flowing between server and client is information to be displayed and mouse click events then the attack surface is significantly smaller. There would be no arbitrary code running on either server or client.

The problem for a web browser running arbitrary javascript is that the browser developer has no control over what code actually gets run in the browser. This is a much bigger attack surface, as we are witnessing right now.

"Also you need bigger servers. Client-side computing distributes some of the load."

That kinda depends on what's being served up. If a website has some enourmous database and most of its workload is running and querying that (e.g. Google's search), then hosting the application too is small beer in comparison. If someone visits something like Google Docs, a vast pile of Javascript code is piped from the server to the browser over an encrypted connection. But if that someone then clicks out of Google Doc without doing much then the amount of javascript served by the server out outweighs the amount of data that it would have taken to convey the display instead. Similarly for Google Maps, etc. As for content websites, like YouTube, they're serving up streams of video data which would be the same amount of server-side work regardless, or adverts (in which case it's someone else's problem).

Client side computing does distribute the load, but for the client, who generally has a battery powered mobile these days, that's a bad thing. Hence functionality-deficient mobile websites. Hence native apps. Hence separate iOS and Android native apps, and the two teams needed to develop and maintain both.

It would be far easier if you only had to develop the app once and have it displayed to a remote client through a standard protocol.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon