-- [ Picked text/plain from multipart/alternative ] It'd help if the lock wasn't broken to begin with or having to replace the entire safe if the lock was picked or the secret combination guessed.
On 9/11/06, Edward Luna <[EMAIL PROTECTED]> wrote: > > Any lock can be opened and any safe can be cracked... Valve is > restricted by the law of the diminishing return; much like the OSHA > cowboy. At some point, onerous safeguards destroy the game they were > intended to protect. The servers are our homes... we need to lock the > doors ourselves. > > -----Original Message----- > From: Whisper [mailto:[EMAIL PROTECTED] > Sent: Monday, September 11, 2006 12:03 AM > To: [email protected] > Subject: Re: [hlds] Re: Scum-sucking Bottom Feeders > > > -- > > [ Picked text/plain from multipart/alternative ] > It is quite simply a case of developers more worried about making the > game > work, rather than making the game code secure at the very beginning from > the > design point onwards. > > As I have said before, if you design a platform with security and > robustness > up most in your mind from the beginning and also assume that whatever > you do > will break and set things up so you can make changes easily for you, and > difficult to circumvent, then you would be well in front to begin with. > > Trying to bolt security onto an product at the end, is nearly always a > losing proposition. > > Take a look a 1 very simple feature that is already built into the game: > sv_consistency > > If sv_consistency was implemented properly, the server admins could > choose > to turn it on and force players to only play with Valve default models, > which as some of you know, would help considerably against numerous VAC > proof cheats currently available. If a user wished to bypass this check > with > a 3rd party program (read cheat) then it would be 1 more thing available > for > VAC to detect. > > The other annoying thing is, in the old days when not as many people had > decent Internet connections and Valve did not have this wonderful update > platform known as STEAM, I would agree, it was difficult to keep clients > maintained, but now with STEAM and huge amounts of bandwidth currently > available (>2GB FOR A BF DEMO OMFG), other than the develpment side, > there > is now no limitation to how often a Anti-Cheat can be updated. > > Any how, I don't know what happens or why, but I would have thought that > making your game a cheat free as possible, and consideration of server > administration as a part of the initial design phase rather as an after > thought, would be primary a consideration to game development these > days. > > On 9/11/06, Frazer <[EMAIL PROTECTED]> wrote: > > > > First, as the OP on this thread, I would like to explain my intent in > > drawing attention to this: simply to raise awareness and to have some > > idea > > what to encourage our game admins to watch for during play. I am sure > > that > > those who want such hacks as these have no difficulty finding them. > Oh > > and > > also...as was suggested in an earlier response - I don't think (last > time > > I > > checked) that I am some kind of list troll. :o) > > > > Second, I wonder to what extent Valve - or for that matter any online > game > > developer - can truly provide a defense against this crap. The > problem is > > that game state is continuously transmitted to the client and all > > rendering > > is under the control of the client. While VAC can, to some extent, > ensure > > that the client executable is not tampered with, unfortunately, short > of > > some very intrusive and, frankly, unwelcome measures, its unlikely > that a > > complete defense is possible. Perhaps something of a Bayesian or > > statistical application which is not examining executables - but is > > watching > > and measuring the behaviour of players to determine what is suspect > and > > what > > is not. (e.g. 20 headshots within 5 minutes and never killed) Then, > > perhaps, some kind of selectable level of tolerance, to be applied by > > server > > admins - much as spam tolerance levels are set today. > > > > In any event, I just wanted to shine a light on it - because, in the > > absence > > of a technical solution, knowledge and vigilance, on the part of the > admin > > community is the first and most effective line of defense. I certainly > had > > no intention of promoting this stuff, nor do I agree that discussing > it is > > useless. The more people understand how they work - the more likely > it > > will > > be detected and dealt with. > > > > > > Frazer > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
