Related
I need to gather information when user sees an article. User will browse through 1-30 articles in a minute (maybe even more if user just scrolls through everything looking something specific). I was wondering which way i can keep my server costs at minimum:
At client side javascript i push article id's into an array and send it to server when there is 30-60 id's. At server i loop through all the id's and insert them into database.
Every single time when user sees an article i will send one article id to server. In some cases this can cause over 60 requests in a minute. At server i insert the id into database.
In most of the cases, there is always a trade-off. And a lot of times, the optimal solution lies somewhere in the middle. I feel you should support both and use them interchangeably depending on the situation. Please go through following scenarios:
Will your end-user have bandwidth issues? If yes, it may make sense to go with option 2 or reduce the number of articles to a number such that it can be easily fetched at lower bandwidth as well.
Assuming the user does not has bandwidth issues such that loading of 30-60 articles won't take a lot of time for user, you can go with option 1 and keep using this option for subsequent fetch as well.
A lot of times it will make sense to go with option 1 for initial fetch and then fetch a lower number of articles after that.
Regarding server cost, it will make sense to send 30-60 articles together provided user reads them all. If you feel he won't read them all, find an optimal number using your app's analytics and send those number of articles in one go, provided bandwidth won't be an issue for user.
tl;dr; In data you should trust. Use your intuition, existing app usage patterns, and bandwidth availability of the user to make an informed decision. Also, server cost is not the only thing. Experience matters more, I think.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
[I know there have been similar questions about preventing cheating on high score lists, but no answer didn't really help me for JavaScript based games, so please try to think about my question, before telling me about similar posts. I ask about best practices because the JavaScript is always visible for the user and therefore it is not possible to prevent cheating completly, I just want to make it harder.]
I'm developing a JavaScript based game that works in the browser. I want to make a high score list that contains the user name and the score of all users. To achieve that the browser sends the username and the score to my server (via AJAX).
Submitting fake scores to this list would be fairly easy: One could take a look at the AJAX requests and then make an own AJAX request with a faked score. Using something like a token that has to be send with the other data is pointless, as it will be easy to discover.
My only approach, that would prevent cheating, would be to send a description of every user action to the server and calculate the score there. But this is not really practicable as it would be too much for the server.
I accepted an answer, but in case anyone has other ideas about how to make cheating harder, please create another answer!
I like to play cheat the cheater - something like using a token to authenticate the score that changes every time the update is called... but I accept the cheat score that gets posted using a duplicate token. Then I display that cheat score to only the cheater, so it appears that it worked, but now the cheater is seeing his results in a sandbox.
You pretty much answered your own question. If you want to really make it harder for users to cheat, send game log to the server, where you'll calculate the score.
You don't have to send all the events, just ones that affect result score.
There are some techniques, though, that may help you:
include signature in your request. Something like MD5(secret_key + params). Although, "secret key" will have to be in JS source, it will effectively protect you from simple request interception (see Tamper Data and Charles)
if it's a multiplayer game, accept scores calculated by clients and compare them. Cheaters will be pretty visible (assuming that the majority of users are honest).
you can set a score cap, an "unreachable" result. Everyone who posts score higher than this is a cheater. For example, speed typing game: no one can type correct text at 1500 chars/minute, even 700 is pretty damn hard (though achievable).
On score submit:
Request some token from the server, this should be time based and only valid for about 2 seconds
Only accept submits that include a valid hash of this token, some salt and the score.
This prevents manual tampering with the request as it would timeout the score. If you want to account for high-latency give it a little more time until the timeout.
The hashing function:
Scramble the hashing function inside packed code (http://dean.edwards.name/packer/ really produces nasty to read code) if you use jQuery or some other library just drop the hashing functionality inside the library file and it gets pretty bad to find, escpecially if you use a function name like "h" :)
Handling the score-variable itself:
Well everybody with a debugging console can change the variable on runtime when doing this but if you encapsulate your whole Javascript inside a function and call it nothing is in the global namespace and it's much harder to get to the variables:
(function() {
//your js code here
})();
I have had lots of thoughts about it and, eventually, decided to only have local individual highscores, so cheating is not really beneficial for player and not harmful to others. Yet my game is just a simple minesweeper, and there were people who complained about the lack of competitive table.
Option 2, is approach taken by WebSudoku - to show your place "among the people of internet". So you will not see any other results, and people wont see your results - but you can compare yourself to crowd.
p.s: And seriously - any kid with Firebug/WebInspector can easily hack your JS game and, eventually, to be able to reach very high score.
If you are relying on the client to send the final score to the server, then there is no way (afaik) to prevent a genius from cheating. But I think you might be able to prevent stupid people (and honest people) from cheating, so that only geniuses and their friends will dominate your leaderboards.
There are two ways I can think of
1.) "security through obscurity."
Come up with an algorithm that transforms simple scores into something else (and to transform them back). Then obfuscate it. Complicate it. Write a function that multiplies it by q and divides it by ralph. Apply a bunch of functions to it, and among the 5-15 functions that do random stuff to it, include one that multiplies the number by 19 ( a prime number ). On your server, check to make sure every incoming number (or letter) is divisible by 19, and decode
You have to write a bunch of complex code that transforms simple scores into something crazy-looking. You have to write a series of functions in the least-efficient, most spaghetti-code fashion possible. Use
One thing you cold do is to have a set of disallowed values. I.e., perhaps all points awarded are even. If anyone tries to submit an odd number, they are obviously cheating (and very stupid).
2.) time
You should be able to know when the user started the game. You should have a session started and record when they requested the page. Then you should also be able to tell when they submitted their score. And you should also know what the time series is for max points. I.e. can you get 5 points per minute, 100 per minute, minute^3, etc... If user submits more points than are possible during that time, they are cheating.
You could also strike a balance between server and client processing and make the client should send progress update every x minutes by ajax. And if it fails to report, you assume it's been compromised (much like in Bond movies, when he's infiltrating the enemy's lair and he snaps some guard's neck. When the guard doesn't respond to his next 10-minutely check-in, the alarms will go off).
If you've ever played Zynga Poker, you've probably seen what happens when someone at the table has a slow internet connection.
Depending on the nature of the game, you could use other players to verify the results. In simple games this works great, on others you have to be clever and develop many aspects around this feature. E.g. sometimes is possible to replay and verify results based on logged actions. This trick works specially well for Human versus AI, as long as the model is deterministic.
Another option is redefining the score concept to be more user-centric, this is pretty easy to implement, but tends to be hard to devise, and only applies to a few categories of games.
Purely speculative approaches are also possible, it's sometimes pretty easy to know when some parameters don't fit. It would not avoid cheating, but would moderate it a lot.
The most complicated part is getting a small enough replay log, but since most data isn't random (except for player actions, which, actually aren't that random because depend on the game) it's essentially a matter of getting the design right.
Also, if gameplay is extended enough, for action games and the like you can get a lot of compression from doing some approximation, merging (e.g. motion vectors), and clipping uninteresting stuff.
Ideally you would send your entire event log to the server for checking. Perhaps you can implement a heuristic so you can easily determine if the score is within a set of bounds. For instance, if the total game time is 5 seconds you might expect a much lower score than with a much longer game time.
Alternatively, you could choose to manually check the event log for really high scores (the overall top-X, which should be fairly stable).
You will need a seeded random number generator if you're doing anything with randomness (like random events). Which might be tricky if you hadn't already thought of it.
You can find many more resources but it really just boils down to server-side checking. JavaScript is not unique in this, but likely easiest to exploit because you not only see the client-server communication but also the client-side source code!
HTML5 Multiplayer Game Security Solutions
http://lanyrd.com/2011/jsconf/sfggb/
Games like Starcraft only record the mouse clicks and key presses. The actual commands are then simulated. I expect 'Worms Armageddon' to do something similar but their random events (like the bounciness of bananas) aren't seeded properly so in the instant replay you might get a different result.
You could imagine something similar for MMORPGs. The server calculates your position based on the keypresses, the client merely tries to give a good early interpretation but you may warp around when you're lagging because the server will place you elsewhere on the map because it didn't get the keypress events timely.
If you attack something, the server will check if you're close enough and how much damage you can expect to deal with current stats and equipment.
Record key points in game, then score is submitted with these key points. When people look high scores, they can also see overview of played game, if it looks like it is impossible to play like that without cheating, then people can report these suspicious scores to admins.
I used a system using a time based request having 3 parameters
req number, curr time, score
The req number is returned from server in the response to the update score request , each time this is a new random value.
The curr time is calculated not from computer clock but from start of game and is synced with server using an ajax request.
Update score request is sent after short intervals (around 30 sec max).
Following checks are applied on the server
Time is within 10 seconds range from the server clock.
there has been not more than 40 seconds since the req number was sent.
the score change sent after 30 seconds is possible (within 2 x humanly possible range)
Score is updated only if the above checks are passed or the user gets a disconnection message :(
This is simpler than most methods and works out to eliminate all casual hackers (well, unless they read this and want to go to the trouble of updating score quickly or making a script of their own).
If not cheating is more important than the game itself, try to construct and present your game in a way that it looks like finding the solution to a math problem. So the server will give an instance of the problem to the client (example A: a chess board about to be won in 3 moves, example B: a geometry dash randomly generated level) and the user will have to solve it and post back a solution (example A: the winning moves, example b: the exact timestamps and intensity of jumps to avoid obstacles)
With this approach, it is key that the server doesn't send the same level twice, or else the cheater can plan and "design" his solution in advance. Also, the game information must be randomly generated in the server and not sent via seed, or else the cheater can fake the seed and design his solution with time.
The given time for valid submissions must be also tracked in the server so that they will only have "playing" time and no "designing" time. If the cheater is good enough to design a solution as fast as honest players can win the game, then they are talented enough to win the game honestly and deserve their points.
Back in the server, you will need to check that the submitted solution is valid for that instance.
Of course this approach requires lots of extra work: More instances of games (ideally infinite and non repeating), server side generation, server side validation of submissions, time caps, etc.
Note: I know these approach was already suggested in multiple solutions some years ago, I wanted to add my humble contribution.
First of all, I understand this question might be off topic and not in scope of stackoverflow but I still decided to ask since I don't know any other better place.
My question is, if I make an online game based on game engines written in javascript eg CreateJS. The game code is going to be run on the clients machine and since javascript is interpreted, it is viewable by the client.
So if a mutliplayer game is being made where users can compete against each other, what measure are taken to prevent cheating. I'm asking because since the game source is viewable, anyone can simple modify the game source and potentially cheat.
Edit: For the idea of the game, lets make one up which is very simple. Imagine we are making a game like FlappyBird or a game where the further you go in a linear map, the more point you stack up.
At the end of the game, your score is submited via a http request.
Now what is stopping a user from editing the game which causes the points to stack up 10x faster? causing a higher score to be submited?
Edit 2: Or what is stopping the users from submitting a request containing false scores via cURL without ever having to play the game?
Multiplayer games prevent cheating usually by simply verifying the game steps, rather than just the complete game output. Since all other players need to know what other players do, you will have to tell the server every step of the way and let the server "simulate" the game and check if these steps are actually valid or not. The only way to cheat in this case is by writing an AI in your browser that will then produce a feasible set of steps coming to a good result.
You also will have to send these player steps to everyone else. Since in a continuous environment players can perform so many actions per second (e.g. move and turn), you want to make sure to minimize the amount of updates to be sent. E.g. when walking in a straight line, World of Warcraft,for example, only sends an update every 500ms. They might also do not necessarily simulate and verify every single step you take, but only every X steps to avoid people running through walls or jumping over entire buildings etc.
Please note that any fast-paced game will not work well when using AJAX calls. Just setting up a connection can take many times as long as just sending a packet through an established connection. That is why you want to use Websockets in that case.
Of course, minifying and obfuscating your code will put some stones in the ways of a cheater, but depending on the vulnerabilities of your system, they might do very little, since it is usually very easy to find the code that takes care of sending and receiving packets or other core aspects of your game, no matter how well obfuscated it is.
Since you cannot believe your clients, you should make an authoritative server and dumb clients model;
That articles are full of gems for who want implements an multiplayer game
the game state is managed by the server alone. Clients send their
actions to the server. The server updates the game state periodically,
and then sends the new game state back to clients, who just render it
on the screen.
From your point of view, what happened is that you pressed the right
arrow but nothing happened for a tenth of a second; then your
character finally moved one square to the right. This perceived lag
between your inputs and its consequences may not sound like much, but
it’s noticeable – and of course, a lag of half a second isn’t just
noticeable, it actually makes the game unplayable.
So you must implement a Client-side prediction and a Server reconciliation
If you develop a "multiplayer" based game, than you should persist the data on a server, centralized, accessed by ajax within your game.
And you're right, someone could potentially "cheat" by overwriting your code with firebug for example or Greasemonkey before you send your data via a http request (ajax).
In order to prevent this you could load your ajax code for saving data dynamically. You can only prevent it by making it more difficult to overwrite your code. Use for example one-way-token in a virtual session, like the token used in OAuth, like a ticket for a ajax-call. Every other call without the right token should be refuted.
I'm trying to create a tower defence game in Javascript.
It's all going well apart from the pathfinding..
I'm using the astar code from this website: http://www.briangrinstead.com/blog/astar-search-algorithm-in-javascript which uses a binary heap (which I believe is fairly optimal)
The problem i'm having is I want to allow people to block the path of the "attackers". This means that each "attacker" needs to be able to find its way to the exit on its own (as someone could just cut off a single "attacker" and it would need to find its own way to the exit). Now 5/6 attackers can pathfind at any one time with no issue. But say the path is blocked for 10+ attackers, all 10 of them will need to fire its pathfinding script at the same time which just drops the FPS to about 1/2 per sec.
This must be a common problem for anyone who has a lot of entities pathfinding at anyone time, so I imagine there must be a better way than my approach.
So my question is: What is the best way to implement mass pathfinding algorithm to multiple "bots" in the most efficient way.
Thanks,
James
Use Anti-objects, this is the only way to get cheap pathfinding, afaik :
http://www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobjects.pdf
Anti-object basically mean that instead of bots having individual ai, you will have one "swarm ai", which is bound to your game map.
p.s.: Here is another link about pathfinding in general (possibly the best online reference available):
http://theory.stanford.edu/~amitp/GameProgramming/index.html
Just cache the result.
Store the path as the value in a hash table (object), give each node a UUID, concatenate the UUIDs to form a unique hash table key and insert the path into it.
When you retrieve the path back out of the hash table, walk the path, and see if it's still valid, if not, recalculate and insert the new one back in.
There are many optimization that you can do :)
Like c69 said swarm AI or hive mind come to mind :P
As far as I read from here, the fact that captchas are not 100% secure.what can be used instead of captcha? As a programmer what do you think? how to solve this issue?
Edit: thanks for all answers.
This is an unsolved problem, and will become more unsolved as time passes. The better the OCR tools get, the smaller the gap between humans and computers, and the harder it will be to tell them apart. Eventually, computers will be indistinguishable from humans, and then the game will be up.
If your server wants to make sure that a human is at the other end of a TCP pipe, there isn't a turing-test in existence that won't eventually be defeated (and there probably never will be one). CAPTCHA is doomed, it's just a matter of how soon.
Of course, that doesn't mean it's all over as far as human authentication is concerned. It just means that automated turing tests, as convenient as they are, won't be an effective way to achieve this for very much longer.
Captcha involving human reflexion (like calculation, really simple question, and the like).
Session tokens
randomly generated hidden input which requires to be null, on the server side generate a random identifier, keep it in a session for a while. If the input is filled and not null, then it might have been filled by a robot, do your users will fill an hidden input ?
I think it really depends on what you are trying to control over the use of captcha.
Further explanation of a suggestion made by Boris:
randomly generated hidden input which requires to be null
The idea is that your form contains several invisible inputs, their type should probably not be set to hidden, but they should be invisible to a human (e.g. set width or height to 0). The initial content of these fields should be empty. If a human fills out the form, the field will be empty, because the human cannot see the field in order to enter anything into it, but if a bot fills out the form the field will (possibly) not be empty, because bots usually just blindly enter something into every field.
Thus, you can distinguish between a bot and a human based on whether the content of this field is empty.
Although captchas can be broken, Capthca's only add to security reCapthca is very good, and a trained OCR like Tesseract is going to have very limited success in breaking it. However, there are outfits that use Human Computation to break them for pennies. But this makes attacks against your system more expensive, and thats the best you can hope for. Cryptography can be broken with brute-force. All password hashes are breakable, but we still use them because it makes it harder for the attacker.
Most of the "solutions" on this thread are "Security Though Obscurity" and you should be wary of these quick fixes to a very complex problem.
Captcha's are used to determine that an actual human being is doing the request, not a machine. Captcha's and captcha-like systems will upgrade, and so will the technology to break them.
So how do you proof that you're talking to a human and not a computer? You could for instance require users to engage in a chat session and have small conversation. There's no AI nowadays that pass the turing test.
So the answer is, no system is perfect. Don't try to solve this issue, but try to find a way to reduce the impact of this.
In the long run government could run openid servers as digital passports for their citizens.
It would be a clean way to identify human beings and prevent sockpuppeting.
At the moment on my website I opted for simple questions. Some questions I've used in the past:
What is two to the power of one?
What is 2+2? (this one was hacked though so don't use it)
What is the name of this website domain?
What is the sum of two and two?
Some other nice ones could be
type in 'stuff' to this box as a spam check
What does 1337 look like? (using only letters)
the current year is?
The best way I can think of is using something unconventional, like a special hidden field that should be null (or another specific value) that robots will mess with.
If some robot maker adjusts his robot for your site, you'll have to quickly change the captcha to something different. It will (hopefully) take a good while before another robot maker adjusts his robot for your site.
Basically, it's a security through obscurity that has to constantly change to remain obscure.
This won't work very well if someone is specifically targeting your site.
Its just an idea, id used that in my application and works well
you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them
the cookie can be a timestamp or a token that can be validate
Gets the coordinates of the mouse, determine whether the coordinates have changed, you can determine whether it is a robot.
Then encrypt the coordinate data.