Differences between revisions 2 and 3
Revision 2 as of 2005-02-02 02:19:08
Size: 4945
Editor: c-24-30-52-144
Comment:
Revision 3 as of 2005-02-02 06:12:34
Size: 2398
Editor: m7p
Comment: spam removal
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
[http://crazyclaudia.webpark.pl/incest-pictures.html incest pic incest grrl] [http://crazyclaudia.webpark.pl/mom-son-incest.html mom son incest incest toons] [http://crazyclaudia.webpark.pl/family-incest.html family incest free incest photos] [http://crazyclaudia.webpark.pl/incest-quest.html incest story] [http://crazyclaudia.webpark.pl/incest-galleries.html incest galleries incest art] [http://crazyclaudia.webpark.pl/mother-son-incest.html incest sex stories] [http://crazyclaudia.webpark.pl/young-incest.html sister incest] [http://crazyclaudia.webpark.pl/incest-stories.html incest stories free incest porn] [http://crazyclaudia.webpark.pl/incest-stories-free.html incest stories incest art] [http://crazyclaudia.webpark.pl/mother-daughter-incest.html mother daughter incest incest storys] [http://crazyclaudia.webpark.pl/incest-forum.html incest forum incest forums] [http://crazyclaudia.webpark.pl/free-incest-pictures.html incest pictures free incest movies] [http://crazyclaudia.webpark.pl/free-incest-porn.html incest porn incest sites] [http://crazyclaudia.webpark.pl/free-incest-videos.html free incest videos mom incest] [http://crazyclaudia.webpark.pl/incest-sex-stories.html incest sex erotic incest stories] [http://crazyclaudia.webpark.pl/father-daughter-incest.html father daughter incest real incest] [http://crazyclaudia.webpark.pl/erotic-incest-stories.html erotic incest stories young incest] [http://crazyclaudia.webpark.pl/incest-pic.html incest pic incest mom son] [http://crazyclaudia.webpark.pl/incest-forums.html incest forum mature incest] [http://crazyclaudia.webpark.pl/free-erotic-incest-stories.html incest stories mother son incest] [http://crazyclaudia.webpark.pl/gay-incest.html gay incest incest movies] [http://crazyclaudia.webpark.pl/incest-taboo-forum.html incest taboo mother daughter incest] [http://crazyclaudia.webpark.pl/cartoon-incest.html mother and son incest] [http://crazyclaudia.webpark.pl/incest-sites.html incest sites incest grrl] [http://crazyclaudia.webpark.pl/free-incest-movies.html incest movies mom son incest] [http://crazyclaudia.webpark.pl/incest-comics.html incest comics gay family incest] [http://crazyclaudia.webpark.pl/incest-sex.html incest sex incest movies] [http://crazyclaudia.webpark.pl/mature-incest.html incest cartoon] [http://crazyclaudia.webpark.pl/brother-sister-incest.html brother sister incest daughter incest] [http://crazyclaudia.webpark.pl/mother-and-son-incest.html mother and son incest incest free stories] [http://crazyclaudia.webpark.pl/ incest videos]

NoSecurity - the side of the debate that wants to set up a Wireless network in the community and open the proverbial BarnDoors for anyone to join in the coffee shop surfin' fun.

Well, with a wiki, you can use databases to rollback what others have done (in terms of damage) fairly easily (in theory). With networks, what's the equivalent? Once the damage is done (hogged bandwidth, say), you can't undo it - you can try to ban that person, but they can fake a new MAC address. I'm really warming to the idea of a 2- or 3-tiered system

  1. Paid users
  2. Trusted unpaid users
  3. Public at large

You can give full access to 1 & 2, and have an always-on, always-available network for 3. You'd limit their "time on in 24 hours" or bandwidth to 64k - this way, they can do only-so-much damage in a single session, but you let them do whatever they want. Think of it like the bumper car ride - everyone can bump you, you can only bump so many people because you're big & don't perform well, and you can not do much damage since you are slow. -- DanRichardson

  • I agree in part. I agree to the basic trust model, what I suspect I'll take issue with is the implementation. Paid users will pretty much be geographically fixed users, they'll be your neighbors. This is easy to control, you give them a static IP give them a generous and guaranteed chunk of bandwidth and they are good to go. The public at large should be unauthenticated and allowed to connect at random, you would restrict the amount of bandwidth that they can use and run an application like an ActivePortal to restrict the amount of "badness" that they can accomplish from your network. Trusted unpaid users though is gonna be a sticky issue. How do you assign trust? The only real way that I can think of is with usernames and passwords, and I'm fairly against this. In order to implement useful authentication you would now have to maintain a user database, possibly a centralized user database (if you want to trust other nodes trusted users) this has the potential to become an administration nightmare. -- AdamShand


[CategoryPhilosophy]

NoSecurity (last edited 2007-11-23 18:00:53 by localhost)