Karen Palen wrote: > After a whole lot of back and forth (much of it in private emails) I think we > are beginning to agree. > > --- On Thu, 1/14/10, John Ward<[email protected]> wrote: > >> I pretty much agree with you. >> My objection is to the notion that >> "fragile filtering" is NOTHING or worse because it only >> generates safe >> feelings. Lots of techniques have actual benefits that are not "real >> security" in some academic sense but are if you measure the effects. >> > My distinction is between what you plan to do as part of the system "defense" > and what you are forced to do to keep things working and keep the "bad guys" > from destroying things. > > This is really a different "plane" from John's view expressed above, but I > see it as complimentary rather than a contradiction. > > >> Client ID string filtering is a poor example of a useful >> fragile filter. >> 1. The threshold for avoiding it is too low. >> 2. The cost of keeping legitimate users out is too high. >> > That we certainly agree on! > > This particular example would require the "bad guys" to actually change > something to identify themselves! > > Since our last email exchange I have found one "private" so called "backup" > system that actually allows the user to select form a set of viewer > identities that is maintained by the client writer! This feature actually > allows the "script kiddie" user to select which viewer identity is sent and > presumably also includes some sort of index to show which identity to use > with which grid! > > Once I can confirm this (with at least more than some You Tube bragging) I > will post some details. > > Karen > > > > I have read most all of the comments concerning this issue. IMO viewer > identification will just be a hassle to the user. Earlier today I used a > Seamonkey browser and was prevented from transacting business because of > using it. My desire to use a particular browser, Seamonkey, was denied. I > certainly didn't want to harm the company that owned or hosted the website. I > guess since Seamonkey is used by more Linux/Unix users that all Seamonkey > users are up to no good and deserve to be banned. My point is to ban based to > ID strings that are true or false is guilt by association just as it is in > the above analogy for Seamonkey users. > > I know the points taken in this very long discussion thread are towards > trying to come up with a proactive approach to Opensim security. I don't > think there is a proactive approach that will work well. I think it must be a > reactive approach. If someone offends, ban. But, automation can certainly > help with identification and culling bad doers.
> > I propose that the ID of the offensive party be based on the MAC address that > I think is part of the HTTP header, if not, there are trace back procedures > that will reveal it. Then, maybe a database of offending MAC's could be > established and keyed inversely with number of bans across Opensims. > The worst offenders are on top of the stack. > > Representatives from several OS organizations could form a group to maintain > the database and it could be built into OS. Then all of opensim would be > doing the same thing. The database could be replicated has a background > process so that all have close the same data at some point. This approach > uses a hardware/frimware address that can only be changed with a great deal > of work or by going to another computer. This is not guilt by association but > identification of hardware from wince bad deeds have come. I suppose someone > with low level knowledge could send the header through a buffer and change > the MAC address on the way out but, I don't think it would be successful as > most ISP's use it to identify authorized equipment attached to their network. > > Thanks for reading. > > Bill > _______________________________________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-users > > > _______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
