Consider performing a 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.
Being on this side of the fence I object to the term NoSecurity.
I prefer the wiki concept of SoftSecurity adapted to networks (eg. NetworkSoftSecurity). An example implementation of this would be an ActivePortal. -- AdamShand
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
- Paid users
- Trusted unpaid users
- 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