<div dir="ltr">A friend of mine was listening in on the Groups Review process yesterday and had some insights into why many of the potential 'solutions' won't work, and an idea about the actual 'problem' driving this review.<div><div><br></div><div>"

I think if the issue is trust then this is the wrong conversation. A better conversation is who isn't trusted, why, should they be removed and  what needs to be changed to do that? "</div><div>The above is not what I, personally, think. But I believe that there are some people in the conversation who unfortunately think that.</div><div><br></div><div>I think it might be good to separate these two issues completely, trust and group review.</div><div><br></div><div>If people are not trusted: why, should they be removed, how can this happen in a fair way? </div><div>-- What disrupts trust?</div><div><br></div><div>For the group review (which the OGM has compelled us to do), I am still keen on a survey of interest every year asking individuals if they would still like to have access to the permissions that they currently possess.</div><div>-- If people are like me, then they would lapse their permissions as they become no longer necessary to them.</div><div><br></div><div>Those are my thoughts.</div><div><br></div><div>Grace Rosario</div><div>[MLG]</div><div> <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Ryan Oakley</strong> <span dir="ltr"><<a href="mailto:21793455@student.uwa.edu.au">21793455@student.uwa.edu.au</a>></span><br>Date: Mon, 13 May 2019 at 20:37<br>Subject: Re: Minutes from the meeting that is entertaining<br>To: Grace Rosario <<a href="mailto:20483992@student.uwa.edu.au">20483992@student.uwa.edu.au</a>><br></div><br><br><div dir="auto">Hi Grace,<div dir="auto"><br></div><div dir="auto">So I couldn't help but think about the Wheel problem.</div><div dir="auto"><br></div><div dir="auto">A two tier wheel system is the clear solution. If a change of Wheel needs to be made to fix this issue.</div><div dir="auto"><br></div><div dir="auto">However I would take a different approach to it.</div><div dir="auto"><br></div><div dir="auto">Let's consider that the benefit of being on wheel is non-monetary. Which makes things easier as it's more subjective and there no ingrained "more is better" ideas. As you can't have "more wheel". It's an exchange of value (benefits, good will and power for responsibility).</div><div dir="auto"><br></div><div dir="auto">With that in mind, you could figure out what aspects of wheel is "painful" (things people don't want to do or takes a lot of time) and pair that with what people want less active wheel members not to have (Sudo). </div><div dir="auto"><br></div><div dir="auto">I.e. create a wheel-lite with less power and responsibilities. For this to work you should,</div><div dir="auto"><br></div><div dir="auto">1. Allow people to volunteerarily step down to wheel-lite through action (asking for it) or in action (not meeting requirements). </div><div dir="auto">2. It should be easy to move from wheel-lite back to wheel. </div><div dir="auto"><br></div><div dir="auto">This could potentially benefit wheel members, as when they go though a busy period in their life they can step down to wheel-lite. In addition wheel members who want to continue to provide their services in steering the club can do so with less "pain". </div><div dir="auto"><br></div><div dir="auto">Obviously, don't call it wheel-lite. </div><div dir="auto"><br></div><div dir="auto">The downsides are:</div><div dir="auto"><br></div><div dir="auto">1. If you're honest about this new system some wheel may feel offended by the notion you can't trust them.</div><div dir="auto">2. You could get a growing mass of wheel-lite members who don't do any technical work. This could occur by too many wheel members becoming lite, thus more new members are added to pick up the slack who then become lite members repeat. If this occurs you could adjust the wheel-lite requirements.</div><div dir="auto"><br></div><div dir="auto">The other ideas,</div><div dir="auto"><br></div><div dir="auto">Super wheel loses the value of a dual governance system that UCC having both a representative democracy and a democracy of professionals (autocracy). if super wheel is elected It also comes with all the potential problems of committees (win-lose of democracy, more politics, a few inflicting their will on all, less voices and non committee members not doing work (or having the freedom to do work). </div><div dir="auto"><br></div><div dir="auto">Project based giving of Sudo. The idea is that Sudo will only be given when needed. This makes it harder for getting work done, especially for more casual members. And creates a governance nightmare around giving and removing keys. </div><div dir="auto"><br></div><div dir="auto">Git: not quite sure what the maths guy thought this is. But I think it's idea of creating scripts so machines can be reset at will with a button click. Good idea but doesn't really solve the issue of trust other then creating version tracking. Plus, part of the job of wheel is tech support which usually can't be done via run once scripts. client machines can't be perfectly set up via a script as users touch them and want to use them in unpredictable ways. That said a pre-scripted or created base box is a good idea but I'm pretty sure UCC already does this.</div><div dir="auto"><br></div><div dir="auto">Also a dedicated issue board would be a big improvement, as currently I believe to report technical issues door members attempt to contact a wheel member via messages. This could easily be done via GitHub issues. A shorten link to the repo should be created and posted somewhere in the clubroom or ideally create a UCC desktop wallpaper and deploy it to all the machines. <br></div><div dir="auto"><br></div><div dir="auto">With that said, I think changing governance for this reason is pointless. If the concern is the a wheel member becoming a potential attacker then none of this will stop them becuase social engineering is a thing. A little social engineering will get any wheel member Sudo on any machine or all of them.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">You can't get around giving system administrator extreme power. So don't have system administrator you don't trust. Easier said then done though.</div><div dir="auto"><br></div><div dir="auto">There is the obvious solution that all command line inputs under Sudo must checked by another wheel member via code review before being executed. But wheel members will hate this becuase it's terrible not to mention it would take ages to do anything.</div><div dir="auto"><br></div><div dir="auto">You could also break wheel into roles, i.e. each wheel has a single responsibility and can't change things on other machines. But this only reduces vectors of attacks and impact. It will make it harder for people to do their volunteer work and put more delays to fixing stuff. Not to mention where a wheel member (s) in charge of something are unavailable.</div><div dir="auto"><br></div><div dir="auto">I think if the issue is trust then this is the wrong conversation. A better conversation is who isn't trusted, why, should they be removed and  what needs to be changed to do that?</div><div dir="auto"><br></div><div dir="auto"> Or reduce vectors of attack. Do a risk assessment of a wheel member going rogue, the impact and cost of fixing it. Then take measures to reduce impact and cost of fixing.</div><div dir="auto"><br></div><div dir="auto">Make a disaster recovery plan and find a way to protect sensitive data. And obviously make sure logs are protected. This assuming none of this isn't already in place.</div><div dir="auto"><br></div><div dir="auto">I think this primarily a  person and technology problem not a governance problem.  </div><div dir="auto"><br></div><div dir="auto">This isn't a formal analysis as I don't know enough about UCC's governance to do that and I am lacking some important information.</div><div dir="auto"><br></div><div dir="auto">I hope this helpful. </div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Ryan Oakley</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon., 13 May 2019, 6:42 pm Grace Rosario, <<a href="mailto:20483992@student.uwa.edu.au" target="_blank">20483992@student.uwa.edu.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div>
</blockquote></div>
</div></div></div></div>