Re: [DALnet-services] 2010-02-15 Services changes

Grr, Droid won't let me snip. Wrt multiple founders, I believe this would lead to a lot of fighting over settings, etc. Who has the power to add and remove founders? If more than one person then you'll have takeovers. If a single person, then you're back to the same scenario as having a founder and sops. James Hess <mysidia@gmail.com> wrote:
On Thu, Feb 18, 2010 at 5:51 PM, Vin King <vin.king@gmail.com> wrote:
On Thu, Feb 18, 2010 at 6:41 PM, Kobi Shmueli <kobi@dal.net> wrote: I'm still not entirely certain on the specific need to prevent founders from being on the access lists.
I think it comes as lagniappe -- hand in hand with not being allowed to AKICK founder nicknames, which was a topic of discussion earlier.
I see how preventing a founder to be added to SOp list can be a substantial inconvenience / usability annoyance in some cases.
The founder can't add themselves to SOp list, and tell the other person to SET FOUNDER. The new founder has to manually do any work required to re-SOp the original founder.
The "problem" would be moot if there were a way provided to list multiple "Managers" or "Founders" of a channel like there ought to be.
-- -J _______________________________________________ DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Fri, Feb 19, 2010 at 12:54 PM, Kevin Buley <kevin@buley.org> wrote:
Grr, Droid won't let me snip. Wrt multiple founders, I believe this would lead to a lot of fighting over settings, etc. Who has the power to add and remove founders? If more than one person then you'll have takeovers. If a single person, then you're back to the same scenario as having a founder and sops.
The same could be said of multiple SOPs. Who can add akicks? Who can add and remove AOPs? If more than one person, you have takeovers, etc etc. Efnet and Undernet, over the course of decades, have shown us that people with equal power typically don't step on each others' toes. It happens, but rarely, probably even more rarely than people sharing their chanserv passes on dalnet. OT: I too hate how the droid won't let you properly format replies. Also, my apologies to Kevin for sending a copy of this reply directly. Gmail is not very mailing list friendly.

On Fri, Feb 19, 2010 at 11:54 AM, Kevin Buley <kevin@buley.org> wrote:
Grr, Droid won't let me snip. Wrt multiple founders, I believe this would lead to a lot of fighting over settings, etc. Who has the power to add and remove founders? If more than one person then you'll have takeovers. If a single person, then you're back to the same scenario as having a founder and sops.
On DALnet, perhaps. Using a single password to control the channel is a bit flawed, imo. A system could be implemented where a channel is linked to a specific NickServ registration (e.g., only that individual could give up ownership of a channel), making it easily recoverable and the point about takeovers rather moot. This could allow for founders to grant individuals the ability to modify channel settings, and anything else a founder can typically do for the most part, without the fear of losing the channel or having to share a password. As someone else pointed out, other networks (e.g., GameSurge, Quakenet, Undernet, etc) have shown this typically does not lead to mass chaos. -Jason

On Fri, Feb 19, 2010 at 11:54 AM, Kevin Buley <kevin@buley.org> wrote:
Grr, Droid won't let me snip. Wrt multiple founders, I believe this would lead to a >lot of fighting over settings, etc. Who has the power to add and remove >founders? If more than one person then you'll have takeovers. If a single >person, then you're back to the same scenario as having a founder and sops.
I would suggest that only the person to know the channel password can change the channel password, change the official 'owner of record' for the channel as listed in CS INfO, or /CS DROP the channel. Three actions reserved for a person who knows the channel password. I doubt it would lead to fighting over settings, because the founder can pick additionals they trust. Think of this as giving a neighbor the keys to your house, but not the deed or certain legal rights (such as the authority to bring in a demolition crew and destroy it); this is useful if you go on vacation or something. Yes they can really hurt you in certain ways, but you trust them not to. Even though you gave them (essentially) full unsupervised access. What's significant is you make all or almost all technical abilities available to them, and that is an act of trust. You communicate the intent regarding what they accomplish using that access, what things they accomplish, precautions they should take, things they should not do, etc. You also still own the house., and you can have the locks changed later (if necessary). But your additional founder is essentially "you" when you are not there. Because most founders cannot be available 24/7. Multiple founders or managers does not necessarily mean channels need [or want] multiple owners of record. It could be used to reduce the access level of "shared founders", eliminate password sharing, and therefore improve security. Currently secondary or co-founders have to be given the channel password, in order to be able to change any settings. Unless the founder wants to risk using UNSECURE mode and /NickServ ACCESS list. Either method is not ideal, and reduces security in its own way. For example: currently, if you want to let someone else delete a SOP in an emergency, or do other things like mlock +m. You must give them the channel password. This allows them to also do things like DROP the channel or lock you out. In event case of dispute or abuse, I would expect the owner of the channel password to be able to revoke additional founders' access. But I doubt it would come to that often. -- -J
participants (4)
-
James Hess
-
Jason Hill
-
Kevin Buley
-
Michael Reynolds