February 2000
- datagram protocol design theory? (Question about multithreaded servers) Ola Fosheim Grøstad
- Library error J C Lawrence
- Semi-OT: Linux support in commercial MUDs? Ola Fosheim Grøstad
- From the Apache Referrer logs J C Lawrence
- From the Apache Referrer logs Kris Van Hees
- good muds for ai programming? Robert Zubek
- good muds for ai programming? J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling cg@ami-cg.GraySage.Edmonton.AB.CA
- Event Scheduling J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Miroslav Silovic
- Event Scheduling Jp Calderone
- Event Scheduling Ola Fosheim Grøstad
- Event Scheduling Miroslav Silovic
- Event Scheduling J C Lawrence
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- IO Speed Suggestions Christopher Kohnert
- IO Speed Suggestions J C Lawrence
- Couple of articles Koster, Raph
- Couple of articles Dr Richard A. Bartle
- OT: Soliciting advice from Canadians Alex Oren
- MUD Specific Building pages MichelleThompson
- MUD Specific Building pages J C Lawrence
- Embedding Python icecube@ihug.co.nz
- Embedding Python icecube@ihug.co.nz
- Embedding Python J C Lawrence
- Embedding Python Todd McKimmey
- Embedding Python Oliver Jowett
- Embedding Python Todd McKimmey
- ADMIN: List post rejections J C Lawrence
- distributed objects Kevin Littlejohn
- distributed objects Vijay Weasel Prabhakar
- distributed objects Brandon J. Rickman
- distributed objects J C Lawrence
- distributed objects Koster, Raph
- distributed objects Vijay Weasel Prabhakar
- distributed objects David Bennett
- distributed objects Phillip Lenhardt
- distributed objects cjones@one.net
- distributed objects F. Randall Farmer
- distributed objects Ola Fosheim Grøstad
- distributed objects Kevin Littlejohn
- distributed objects J C Lawrence
- distributed objects Gary Whitten
- distributed objects Balthazaar
- distributed objects J C Lawrence
- distributed objects Ola Fosheim Grøstad
- distributed objects Eli Stevens {Grey}
- distributed objects Jon A. Lambert
- distributed objects Charles Hughes
- distributed objects Caliban Tiresias Darklock
- distributed objects Charles Hughes
- distributed objects J C Lawrence
- distributed objects J C Lawrence
- distributed objects Charles Hughes
- distributed objects Charles Hughes
- distributed objects Laurent Bossavit
- distributed objects Kevin Littlejohn
- distributed objects markm@caplet.com
- distributed objects KevinL
(Wow, an old post ;)
markm@caplet.com wrote:
>
> --<cut>--
> Note: This message was written via the list web archives. There is
> no guarantee that the claimed author is actually the author.
> --<cut>--
> Original message: http://www.kanga.nu/archives/MUD-Dev-L/2000Q1/msg00378.php
>
> On Wed, 16 Feb 2000 21:42:28 -0800
> Kevin Littlejohn <darius@connect.com.au> wrote:
> > > ... don't the solutions outlined at www.erights.org for
> > > implementing secure "purses" also fit the bill for combat systems ?
> >
> > For anyone who hasn't read it:
> > http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
> >
> > Neat system.
>
> Thanks.
>
> > There's still reliance on a bunch of things, that may not be immediately
> > evident, though, to achieve this security. One of them that doesn't apply
> > in Moebius (nor, I believe, in any distributed architecture, where the 'bad
> > guys' have total control over the objects)
>
> I'm not sure I understand your security assumptions, or that you understand
> ours. Please read the "Cypherpunk Reference Scenario" (and variant #3 if you
> wish) at http://www.erights.org/elib/capability/conspire.html#revokability .
> Briefly, Alice is assumed to have total control over the objects running on
> Alice's machine, and Bob is assumed to have total control over objects
> running on Bob's machine, but Alice only has control over objects on Bob's
> machine to the extent that objects on Alice's machine have been given such
> control. See also
> http://www.erights.org/elib/capability/ode/ode-protocol.html#subj-aggregate .
> In a decentralized mutually suspicious world, beware of statements about
> "*the* bad guys" or "*the* objects". There are only particular bad guys and
> particular objects.
Ya. The problem I was looking at at the time, tho, was how do I put all the
attributes for an object in the object, and then trust that the object will
handle it's attributes correctly. Any of the solutions that come out of E
rely on moving the data that needs to be kept secure to a "trusted" place - be
it a bank, or a central server, or whatever.
Put another way, if Alice has total control over Alice's machine, then
anything put on Alice's machine is subject to breakage by her. Thus, you
don't store her purse with her, you store it at a central bank, which is
trusted.
[ Big Snip ]
> > End result - you drag more and more stuff back to the server for
> > verification, until you end up driving the objects data and methods on the
> > server from a remote point.
>
> Yup. That's what we do. It works. But it doesn't centralize any more than
> any other working on-line secure money protocol does. If you know of a way
> to do secure money with a less centralized protocol, that'd be worth a paper
> at FC01 ;)
Fully agreed, it's what you need to do. The reason I've snipped the rest is
because it was an explanation that, once you move the purses to the Bank
machine, you're safe - which I wholeheartedly agree with.
The problem I was facing at the time was that, in my system, I have
potentially one server, where all objects exist and all code runs.
Theoretically, the owner of any object could subvert their own object, replace
their own methods with other methods. I was (foolishly) attempting to find a
way to mix different levels of security to allow _players_ the ability to
write, for example, their own "look" method, which they could then replace the
existing one with. Basically, pretend everyone owns one machine, and has
control over one machine, then run all the E mechanisms on that machine - the
security goes right out the window ;)
I believe E definitely outlines some neat stuff - but it wasn't clear to me
immediately from reading the money example, for instance, what the
pre-requirements were to get security (and lack of clarity can kill security).
The overriding sense I got off E was that it was very good, very well thought
out, but overly obfuscated in explanation - most of the concepts outlines
therein are actually simple concepts, just applied generically, with (for me)
unfamiliar terms.
> > Caveat: I may be wrong, but I can't see where... As EQ and others have
> > demonstrated, people will quite happpily step "out of band" to break these
> > systems
>
> Please show me an out of band attack that threatens E. I'm not saying there
> aren't any, but I'd like to understand what kind of attack you have in mind.
Stretching my memory, but at the time I believe I was thinking in terms of
running E systems on wabi/wine-type virtual machines in debug mode - where you
could take to everything with a good debugger, change values on the fly, etc.
etc. Either that, or the traditional "analysis of traffic patterns" type
attacks to figure out what's happening. I don't think I had anything specific
in mind.
> > I thought replacing the tiles with transparent ones was good, but
> > staggering lag on packets back to the server boggles me.
>
> I haven't read the thread -- only the above message -- so this last comment
> boggles me ;). If it's relevant to our current discussion, please explain
> or point me at something. Otherwise, feel free to drop.
Those two were particular tricks employed in cheating on some games - people
replaced the local tiles for walls in UO with transparent tiles, so when the
server said "a wall here", they got a transparent wall - handy for seeing
people hiding round the corner (and a similar trick was once employed in
Quake, with transparency on water when 3D cards first started getting
sophisticated). Staggering lag was one of the latest Quake hacks, when Quake
went OS - if you lag your packets just enough, you can wait to see if the
server tells you you've been hit, then send a stream of packets to account for
the last few seconds of you moving in the opposite direction.
The other one that's worth mentioning is the person who figured out that the
maps for Quake are CRC-checked locally, and the wall collisions are checked
locally, so he wrote a new map for each level, made the CRC match by adding
and removing junk until it was right, then distributed those as a way to walk
through walls.
Hey, anyone noticed yet that Diablo2 distributes big chunks of map around you
in one go? Good for pre-mapping dungeons and seeing inside buildings outside.
Surprised there's not a "patch" out there to update the overhead map yet...
>
> Hope this clarifies things.
Oh, definitely - I'd missed that purses should be stored on the bank, and had
been trying to solve holding the purses locally. Still haven't, incidentally
;)
KevinL
- distributed objects KevinL
- Distributed Objects Justin Rogers
- Security J C Lawrence
- commercial muds and cable TV (was code base inquiry ) Sellers, Michael
- commercial muds and cable TV (was code base inquiry ) Matthew Mihaly
- commercial muds and cable TV (was code base inq uiry ) Sellers, Michael
- commercial muds and cable TV (was code base inq uiry ) Matthew Mihaly
- business models Matthew Mihaly
- business models Daniel.Harman@barclayscapital.com
- business models Vincent Archer
- business models Dave Rickey
- a shrinking pool of players? Johan J Ingles-le Nobel
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Bryce Harrington
- a shrinking pool of players? Travis S. Casey
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? Ryan P.
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Draymoor
- a shrinking pool of players? Koster, Raph
- The Endeavour Map and MUD Applications Michael Hohensee
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications David Bennett
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Eli Stevens {Grey}
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Koster, Raph
- The Endeavour Map and MUD Applications Lo, Kam
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Joel Dillon
- The Endeavour Map and MUD Applications Justin Rogers
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist J C Lawrence
- Next gen MUD wishlist Chris Jones
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Sellers, Michael
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Codebase Ideas punitac@prodigy.net
- Codebase Ideas Bryce Harrington
- Codebase Ideas Aaron Mitchell
- OT: Money as motivator (was code base inquiry ) J C Lawrence
- OT: Money as motivator (was code base inquiry ) Matthew Mihaly
- Guide Applicant : Player Ratio Geoffrey A. MacDougall
- Guide Applicant : Player Ratio Matthew Mihaly
- MUD-Dev digest, Vol 1 #286 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #286 - 13 msgs Caliban Tiresias Darklock
- MUD-Dev digest, Vol 1 #286 - 13 msgs Koster, Raph
- voice vs. text Matthew Mihaly
- voice vs. text Justin Rogers
- voice vs. text John Bertoglio
- voice vs. text Lovecraft
- voice vs. text Lo, Kam
- voice vs. text Hans-Henrik Staerfeldt
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Justin Rogers
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Dynamic help files, was code base inquiry Richard Woolcock
- OpenSource licenses for game rules? J C Lawrence
- To all the devoted! (fwd) J C Lawrence
- Newbies Johan J Ingles-le Nobel
- MUD-Dev digest, Vol 1 #288 - 9 msgs Dr. Cat
- (fwd) Commercial-use Restrictions on Code Bases (was: help me find 100% free graphical mud) J C Lawrence
- (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...'] J C Lawrence
- Distribution Geir Harald Hansen
- player persistence Matthew Mihaly
- [Off-topic] GDC-2000 Derek Snider
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 Justin Lockshaw
- [Off-topic] GDC-2000 Christopher Allen
- [Off-topic] GDC-2000 Matthew Mihaly
- [Off-topic] GDC-2000 Joe Andrieu
- [Off-topic] GDC-2000 Kristen L. Koster
- [Off-topic] GDC-2000 Richard A. Bartle
- [Off-topic] GDC-2000 Bruce
- [Off-topic] GDC-2000 David Bennett
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] AAAI symposium (was: GDC-2000) Robert Zubek
- MSP Richard Ross
- Privateer-style mu*? Bobby Bailey
- Minimum community sizes Dan Root
- Minimum community sizes Koster, Raph
- Minimum community sizes Dan Root
- Minimum community sizes adam@treyarch.com
- Minimum community sizes Matthew Mihaly
- Minimum community sizes David Bennett
- Minimum community sizes Matthew Mihaly
- Pike codebase Daniel Podlejski
- chil@gate.net Joel Kelso