[Noisebridge-discuss] access for members and associate members at all hours
Naomi Most
pnaomi at gmail.com
Mon May 12 23:51:40 UTC 2014
> You are relying on an undefined trust model, and a model
> that frankly seems to rely on trust relationships that
> do not exist.
We know. That's what we're working on.
--Naomi
On Mon, May 12, 2014 at 4:42 PM, openfly
<openfly at xn--kgbed8a0h.xn--ngbc5azd> wrote:
> Two key points. Argue their veracity amongst yourselves if you must.
>
> 1. Kicking people out of the space as a method has failed
> utterly for the past 4 years. Some seem to think that
> THIS TIME it will work. I can only point out that
> experience would suggest that you are very very wrong.
>
> The reasons for this could be many.
>
> a) Few people with the will to risk a physical
> altercation
>
> b) Lack of identifable and functional trust
> relationships in the noisebridge trust model.
>
> etc etc.
>
> 2. The Noisebridge membership structure is not a functional
> trust-model for the space to rely upon to enforce any
> trust relationship based authentication mechanism.
>
> In short, you have too many members / associate members
> to reasonably expect folks to track who brought who in
> and is responsible for whom. More to the point, this
> model relies on an implicit trust of all members and
> associate members of noisebridge. Something that
> frankly I see no grounds for believing exists.
>
> Now get angry all you want and spout on about your
> hopes and dreams for a better noisebridge but it's year
> seven or so. If you keep repeating the same mistakes
> you MIGHT consider the posibility that some of your
> fundamental premises may be built upon flawed logic or
> theories that have not faired well in experimentation.
>
> I guess what I am saying is, you guys are talking about
> building filters to stop an undefined element of noisebridge
> visitor.
>
> You are relying on an undefined trust model, and a model
> that frankly seems to rely on trust relationships that
> do not exist.
>
> I'd recommend.. simple logical analysis here.
>
> Drop your emotions off at the local burrito palace and
> let it down a jarritos while you do this.
>
> Work on defining these:
>
> First the firewall style logic ( easy ):
>
> 1. Is the access filter to noisebridge a default deny or a
> default allow? ( I assume most want a default allow )
>
> 2. Who are you specifically excepting ( allow or deny )
> from the default filter rule? Define the folks who
> are exceptions from the default rule. All of them.
>
> Now stop for a second. Give that a look again. Grab a coffee
> or a tea, maybe a yerba mate. Relax. Ponder.
>
> Now for the next part...
>
> Think Trust relationships ( moderately hard ):
>
> 1. What relationships of trust currently exist in Noisebridge?
> Do members trust other members? Do members trust associate
> members? Does anyone trust a visitor. Can you quantify
> a metric of trust as a numeric value?
>
> 2. Take the list of exceptions you developed in the first part,
> draw lines between them where a trust relationship exists.
> Add a numeric value if you can. If there is no trust
> you can probably still draw a line just... broken and red or
> something. That's a high risk relationship right?
>
> Cool. Again. Time to let the brain cycle down a bit. Maybe
> go grab a burrito with your emotions for a bit. Or a tasty
> pastry. Hell be healthy and go do your evening or morning
> exercise routine. Meditate. Just get your mind to take a
> breather.
>
> When your done, come on back next step.
>
> The Trust Model ( Actually hard ):
>
> 1. Draw up some models for how the trust relationships work
> currently. Do some flowcharts for examples of scenarios.
> What happens when a default set enters. What happens when
> a member enters. How do they function once inside? What
> mechanisms might exist that use trust relationships as
> a vector or argument? Start building some lists.
>
> Do number 1 for a while. Lots of scratch work.
>
> Get a feel for what's going on at noisebridge today.
>
> 2. Look at what's been tried in the past same as you did for
> the present. Draw out the flow charts. Identify trust
> relationships that played a role in mechanisms and
> notable real events. Flag stuff that didn't work.
> Weight it if it's a repeat occurrence or particularly
> dangerous. Quantify that into a number if you can.
>
> Okay. This is getting really harsh now. Hope your emotions
> haven't finished their burrito and come back drunk looking to
> get surly. If they have maybe go home for the night and let
> emotions sleep it off. The next part requires you to be zen
> like even.
>
> 3. Come up with some hypothetical fixes. New trust
> relationships. New mechanisms. See how they
> might work using your past flow charts.
> Work with weights if you have em to set
> priorities. See if you can use the trust-relationship
> quantified value to improve mechanisms or filters.
> Try new filters. Swap from default deny to allow or
> vice-versa. See what happens when you do.
>
> This part is kind of fun if you can separate yourself
> from drama or emotions relating to it being anything more
> than an abstract model you are playing with in your head.
>
> Be creative.
>
> 4. Now, here's the bees knees if you can do it. Try to
> take all of your work and build a trust model that
> is an improvement to what noisebridge is currently.
>
> New mechanisms, new relationships and weights, new
> filter sets. Propose something that is an improvement.
>
> Now...
>
>
> At this point. Then we can have this discussion properly.
> Like real live engineers.
>
> Jah rule yah jive ass hackers.
>
> -openfly
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
--
Naomi Theora Most
naomi at nthmost.com
+1-415-728-7490
skype: nthmost
http://twitter.com/nthmost
More information about the Noisebridge-discuss
mailing list