[nb-soc] [Noisebridge-discuss] Access control & Safety, both personal and general space.

Kelly hurtstotouchfire at gmail.com
Thu Feb 9 22:13:41 UTC 2012


Oh also in case it's not clear, hard keys are a totally reasonable
complement to this system. Doorcodes are issued to members but
presumably they are only used by members friends. Members should have
keys. This basically means that members manage their own set of
doorcodes, asking for new ones as needed.

This way, filtering of who gets in to noisebridge is distributed
across members and across people in the community who have doorcodes,
rather than putting all of the pressure on the person who answers the
door.

-K

On Thu, Feb 9, 2012 at 14:09, Kelly <hurtstotouchfire at gmail.com> wrote:
> Hi folks.
>
> I'm really tired of discussing and ready to DO, but discussion is
> unavoidable to get consensus. And I'm not talking about formal
> consensus, I'm talking about when the community rallies around
> something.
>
> Let's start with this: I'm not new, I'm familiar with the several
> rounds of debate we've had on this topic, and I think I have a system
> that will work. I think the basic idea is compatible with
> Noisebridge's values, but there are a few implementation issues that I
> would appreciate input on. And by input I mean, come to a soceng
> meeting, a tuesday meeting or email me directly.
>
> I'll make a wiki page soon (I am also in workhell and lifehell right
> now so please be patient), hopefully by Saturday.
>
> Here's the basic outline of what I'm proposing:
>
> - Door can be buzzed open by entering one of a large set of acceptable
> numeric doorcodes.
> - Doorcodes are made by some system at Noisebridge and propagate virally
> - Doorbell is removed (this is the one part we need to debate and debug)
> - Ability to buzz people in from the interior of noisebridge is
> removed so that people in the space are freed of the burden to check
> out everyone who enters -- because no one likes this and as far as I
> can tell no one does it.
> - internet buzzing-in-ability remains (this is part of why I think we
> need to remove the doorbell)
> - Doorcodes can be disabled if they correlate with problem nights at
> Noisebridge or known problem individuals
>
> Doorcodes are generated in a variety of ways (pick any subset of the following):
> - Unique doorcodes are given to all members
> - A separate pool of doorcodes is maintained on pony and can be
> accessed by anyone already in the space (I feel this has great
> potential for an awesome device)
> - Doorcodes can be generated for twittering/publicizing along with 5mof, etc.
> - Doorcode is provided to individuals who request them at tuesday meetings
> - etc
>
> We would need to maintain the Rooster Brigade
> (https://www.noisebridge.net/wiki/Rooster_Brigade) at least for a
> while so we would know when there was an influx of people living at
> noisebridge.
>
> Open questions include what to actually track about the doorcodes. I
> am a big fan of what I think of as Leif's attitude on data collection.
> If we don't want it subpoenaed, we shouldn't have it in the first
> place. I think that it will actually be reasonably doable to provide
> either a subset of "anonymous" doorcodes or to largely not keep
> records on whose codes are whose in the first place.
>
> It's worth being able to tell if a code was generated for a member or
> for an event or for the website, but I don't think that they need to
> be linked to names in any way. If you as a member have  a unique
> doorcode, you know what it is. And if it gets disabled you know it got
> somehow correlated with an unfortunate event. And you can then get a
> new one and give the new one to your friends.
>
> I will comment briefly on David's outline as well because it's a good outline:
>
>> - Keep the gate shut. An open gate attracts people who just want an open
>> gate, indifferent to the community behind it.
>
> I generally agree with this except that it might be necessary to have
> the gate open for events.
>
>> - Pass out simple keys to dues paying members and other people who are
>> vetted through a voting process.
>
> I think that this is unenforceable. Keys are distributed through a
> process of social approval. I think that having "keying" discussions
> about individuals at the tuesday meeting is a reasonably excellent
> thing to do, but that a formal process with authoritative restrictions
> will never fly.
>
>> - Make sure people know about alternate ways of entry like gatebot (which I
>> hear is getting fixed)
>
> Gatebot is fixed. I generally hope that doorcodes will replace most of
> this use once they are implemented.
>
>> - Make sure the door chime can be heard. Give people a hard time if they
>> buzz someone in without staying to greet them.
>
> I disagree entirely with this. There is *no way* that we can get
> everyone in noisebridge to filter people entering. This will always be
> our greatest loophole until we get rid of the doorbell entirely. I am
> theoretically in favor of getting rid of the doorbell entirely. I'm
> concerned now with how we can sufficiently rid ourselves of the need
> for it. I am hoping that wide enough dissemination of doorcodes in
> combination with gatebot will be enough.
>
>> - Have an institutionalized way to identify and remove people who are not
>> playing nice with others. Present a unified front to make them leave.
>
> We have this already. https://www.noisebridge.net/wiki/Mediation It
> works on a small scale with people who are actually a part of the
> community but are causing problems. It does not work when there is a
> sub-group of people in the space, mostly late at night but also
> sometimes all day, who are not particularly interconnected with the
> community and blatantly do not respect our One Rule.  These people
> have no social obligation to excellence. And social pressure is really
> our only tool. That and cops. But we don't like to resort to that.
> This, I think, is in part an access problem. These people would not be
> given keys or doorcodes, hopefully, if we implement doorcodes right
> and we trust our key distributors.
>
> -Kelly
>
>
> On Wed, Feb 8, 2012 at 08:58, Davidfine <d at vidfine.com> wrote:
>> Hi Christopher,
>> I totally recognize your enthusiasm for this kind of problem solving. I
>> recognize in myself that same drive to solve problems with technology or, as
>> they say, "dude, put a cryptography on it". I don't want to quash that
>> enthusiasm in a new member, but I'm going to offer my perspective on the
>> door issue- which is a unique problem because the way we implement it is a
>> direct expression of who we are as a community.
>>
>> There are some circumstances where your A->B->C model would work very well,
>> but I think Noisebridge needs something simpler. We want unknown people to
>> be able to access the space, and we want people who don't know how to use
>> cryptography to enter the space, and we want people who have heard of
>> Noisebridge but have no other point of contact to enter the space. In
>> addition to all that, the community is sort of nebulous and difficult to
>> organize around one standard way of doing anything.
>>
>> The issue isn't really that bad people can gain entry. It's that we're not
>> good at kicking them out. Part of that is a side effect of anarchistic
>> philosophies, part is that people don't like confrontation. But anarchists
>> have to be good neighbors, and good neighbors sometimes need to lay the
>> smack down on bad neighbors. Or put another way, we as a community need to
>> enforce a code of conduct.
>>
>> What I think we need to do is:
>> - Keep the gate shut. An open gate attracts people who just want an open
>> gate, indifferent to the community behind it.
>> - Pass out simple keys to dues paying members and other people who are
>> vetted through a voting process.
>> - Make sure people know about alternate ways of entry like gatebot (which I
>> hear is getting fixed)
>> - Make sure the door chime can be heard. Give people a hard time if they
>> buzz someone in without staying to greet them.
>> - Have an institutionalized way to identify and remove people who are not
>> playing nice with others. Present a unified front to make them leave.
>>
>> I'm totally into cryptographic ID and web of trust stuff, and if you want to
>> work on that stuff with me let's get together. Leif is working on a
>> cryptographic voting system involving blind signing that would be great to
>> package for wider consumption. And man, we need a better way to manage OTR
>> and PGP keys...
>> Welcome to Noisebridge!
>> --D
>>
>>
>>
>> On 2/8/12 2:46 AM, Christopher Maujean wrote:
>>
>> Hello folks,
>>
>> Last night was my first time at Noisebridge and I'm glad I picked a meeting
>> night. I had already done my homework and read the wiki. Having experienced
>> the prepared rhetoric, and the direct, in person culture, I can say that I
>> intend to come often from this point forward.
>>
>> That said, I would like to volunteer to assist with the implementation of a
>> key system similar to the one proposed by (I think?)Kelly.
>>
>> The background as I see it:
>>
>> In order to maintain the open access that seems to me to be a core part of
>> the Noisebridge culture, there needs to be a way to allow free admittance to
>> all, while enabling the banning of the few bad apples. Paraphrasing Neal
>> Stephenson perhaps, As hire As and Bs, and Bs hire Cs... If we map this to
>> the Noisebridge culture: Excellent people bring both Excellent people, and
>> Good people. Good people bring both Good people and possibly not so good
>> people, the not so good people are likely to inundate the space with people
>> who are, with out a doubt, absolutely not what Noisebridge is about.
>>
>> It makes sense to optimize access control as a filtering system to distill
>> the As and Bs, while keeping the Cs engaged, but not in charge, as the Cs do
>> provide benefit by feeding the system via association to previously
>> undiscovered or unaffiliated Bs and As. Of primary importance, is to float
>> the As and Bs to the top, while keeping the Ds and friends out in the
>> Mission.
>>
>> The proposal (or Mapping swingers hot tub access to hackerspace):
>>
>> An application that can generate, validate and revoke access keys, has an
>> appropriate web api and can open the gate, given an un-revoked key.
>>
>> "Can generate, validate and revoke access keys" is pretty much covered by a
>> (probably trivial) integration of one or more of many implementations of
>> open source public key systems. "Can open the gate" is something I would
>> certainly like to learn and I'm certain multiple people in the space can
>> implement while I ask stupid questions. "Has an appropriate web api" is
>> something I can help with on multiple levels.
>>
>> The basic process as I think would be cool, is that members would be able to
>> use the api to generate keys. Those keys could be given out and virally
>> passed along to potentially like minded people to allow access to the space.
>> In a nutshell an un-revoked key == access to the space.
>>
>> Members would have the privilege of revoking any public keys that were used
>> in a particular time period, perhaps within a given hour. As a member, if
>> your only key were revoked in this way, you would merely fire up your handy
>> dandy key generation app, and make you a new one. Any non-member who was
>> existing in the space only on keys that happened to be revoked, would have
>> to contact members to get new keys. This could be done by pressing the
>> button and mooning the camera, email, telephony, telepathy, whatever.
>>
>> This system will allow As and Bs to hand keys out, with reasonable assurance
>> that if a D or worse does get a key, it can be revoked, the name and picture
>> posted, and the relevant A or B who made the original key notified that
>> their key ended up in the hands of the C or D in question that turned out to
>> be a "bad apple". Perhaps some timing can be implemented so that stale keys
>> can't be written in chalk in Thieves Cant on the sidewalk and remain active
>> for long. Social engineering can help with this, as a member who
>> consistently has keys revoked can be spoken to, ostracized or whatever
>> is necessary to solve the problem.
>>
>> The painless, "happy path" transition to this system will probably require
>> some period where keys are being made and revoked daily or even more often.
>> I believe that this would settle down quickly into a more steady, flat
>> pattern.
>>
>> Obviously, this is not a completely specced out idea, but I think it has
>> potential.
>>
>> I propose the api be implemented in erlang, as this will allow me to learn
>> the language, assuming I'm involved in the making. It could be built quite
>> quickly in ruby, but I think erlang would be more fun.
>>
>> Is anyone interested in discussing this further?
>>
>> --Christopher
>>
>>
>>
>> _______________________________________________
>> Noisebridge-discuss mailing list
>> Noisebridge-discuss at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>>
>>
>>
>> _______________________________________________
>> Noisebridge-discuss mailing list
>> Noisebridge-discuss at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>>



More information about the Socialengineering mailing list