From: brett l. <wak...@gm...> - 2008-11-28 19:37:04
|
On Thu, Nov 27, 2008 at 8:44 PM, Dave Mitton <da...@mi...> wrote: > Hmm... somehow I broke a filter and these messages were landing in > the wrong folder... > > On 11/25/2008 01:19 PM, brett lentz wrote: >>On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote: >> > Oh... I don't know about that. >> > >> > It's not jumping ahead a turn, it would be the ability to >> retroactively change >> > a turn or an asset that would bother me. "I should have bought that >> > last turn..." >> >>Until we implement an actual PBEM facility, the undo feature allows >>you to do this. >> >> > I would feel more comfortable in this kind of dynamic if the game >> generated a >> > crypto hash of the game state and made it visible to all players >> in the report. >> > And then it should be checked on subsequent turns so that everything >> > was consistent with what was before. >> > >> >> >>What stops someone from generating that hash after they've saved a >>bogus game state? > > The hash would be generated in the log record between every turn. > The hash would reflect the game state, and re-entering the same moves > should generate the same hash. > > >>Being an open-source project, there's nothing that prevents someone >>from compiling and using their own modified version of the game that >>generates correct checksums for invalid data. Being a small project, >>we simply don't have anyone volunteering to implement and maintain >>additional security mechanisms. > > I don't think it's really that hard, but I'm just talking aloud here. > Indeed the mechanism should not care "how" the move got entered, just > that the state of the game is "checksumed" if you will in a manner that is > easy to verify and re-check after the fact. > > >>Further, we let the user manually input the value of their train runs. >>Not only is this error prone, but it is an easy way for someone to >>accidentally give themselves an invalid amount of money. In my >>opinion, having someone getting patches in to implement automated >>route calculation will reduce a major potential source of error and/or >>cheating (depending on your perspective). > > Another user reality that I came to quickly is that you will have to > correct or have users correct their moves. People will screw up, > particularly if they don't have people looking over their shoulder > until the move is posting. An Undo facility is necessary. > People make mistakes and I don't expect the game to get the rules > exactly correct. > Even if does, there will be times to override. > I'm not sure if we're really understanding each other here. I'm not arguing for removing the undo capability. I'm saying that until we automatically calculate the value of the routes, giving the user the ability to manually input the value of the route is a far greater source of potential exploitation. > >>I really don't think this should be a big concern. The nice thing >>about implementing a board game is that everything the app does can be >>done by hand. If you want to validate that the calculations are >>correct, the math is fairly basic and well-known. It should be trivial >>to find out if something isn't right. > > The math can be correct and still things go wrong. > Like what? I can't really think of anything that isn't easy to manually verify. We _are_ talking about a boardgame, after all. Now it seems like you're just fear mongering. > >> > I don't know if your code has this feature, but I put it in my 1830 >> > program when I was debugging. >> > An auditor pass would run between every turn: >> > It would count up all the certificates, tokens, anything I >> > could think of >> > (and that should include cash) to make sure everything was >> > accounted for >> > and that the program didn't "leak" or "duplicate" any >> game materials. >> > >> > >> > Dave. >> >>We currently do not audit the game to that extent. Patches are >>welcome, if you'd like to add it. >> > Maybe one of these days.... at the moment I've been doing some > 10am-11pm hours C++ network authentication programming on Vista. I'm > not the happiest camper. > Understandable. Just using Vista makes me unhappy, I'd hate to actually have to develop for it. > Dave. > > ----Brett. |