Re: Membership

[Brian Behlendorf <brian collab net>]

Hi folks, sorry about the delay.  I've got thoughts on lots of the other
threads I'll try and put into email tonight.  But to respond to this:

On Tue, 11 Jul 2000, Alan Cox wrote (quoting David Mason):
> > Kjartan sums up what I was trying to say very well here. My problem is
> > that trying to generalize situations in which people donate to the
> > project is rather dangerous territory. I feel like people with real
> > important contributions could be ignored simply because they did not
> > meet some sort of screening process. 
> 
> Also unless the US folks sign up to strong data protection the non US groups
> would generally not be permitted to provide any kind of personal data
> (eg name, email addr pairs) to the US body.

That does map to my understanding of European data security laws, if the
non-US developers do give their data to European-chartered orgs.  If
the non-US developers give their data directly to the US-chartered org,
then there's no such requirement (though they should clearly respect the
same principles).

> Which reminds me - Collab.net have said nothing on providing a strong data
> protection statement. I do not believe the Gnome foundation should use
> or work with Collab.net long term without such. 
> 
> Anyone from Collab.net care to make suitable noises

We believe it's important, of course - all the sites we run that involve
any sort of data collection have a privacy policy, which generally state
that your data will not be shared with anyone outside the organization
that runs the site.  

Let me ask, though: what is it we're trying to protect?  Our situation is
much different than, say, Amazon.com; an open source project should have
lots of transparancy, where people's actions are very visible and only
that which absolutely has to be kept private, is.  Let me try and
enumerate those items for sake of conversation:

  Authentication: i.e., how do we know that someone checking in code as
    Miguel really is Miguel?  Public keys give us that, and there's no
    need to keep that private.  In the short term we can use simple
    name/passwords (over SSL of course) for commits and stuff, moving to
    certs in the long run (whenever the gnome.org machinery supports it).

  Voting anonymity (if desired): knowing *who* someone is is covered by
    the above case.  Keeping the map of who voted on what confidential...
    well, there's no magic bullet for unless you want to set up a fairly
    complex token-passing system that would allow people to anonymize
    their votes by trading one-time keys.  Anyone know of an open source
    system to do this?  I am aware of some commercial attempts at this.
    Even the electronic voting trial in Arizona, if I recall correctly,
    did not use a cryptographically secure anonymization system; the 
    company was audited by federal elections officials who "made sure"
    that the map of who voted for what was dumped as soon as the tally
    was considered final.  Of course one could scour old disk drives to
    find that data, by the same token one could do genetic testing on
    dust left on physical votes... =)

    My recommendation here would be to either have the map of who voted
    for who be public, or assign an elections official to conduct a vote
    (who's not running for anything themselves) who will be responsible
    for maintaining the anonymity.  In Apache I do not believe we've ever
    had an anonymous vote.

  Email addresses, the map of foo@gnome.org to another address.  It's 
    debatable whether this should be closed or not; my feelings would
    be that it should be published, that gnome.org should not be an
    anonymizer service (there are plenty of those kinds of tools out
    there, like zeroknowlege, and it takes a real infrastructure to 
    run that - not Gnome's reason to exist).  Do people today do POP/IMAP
    directly with a gnome.org server?  To whatever degree gnome.org 
    provides ISP-like features like that, then it'll have to take on
    the same issues ISPs do, such as dealing with the potential for a 
    knock on the door from the feds with a subpeona in hand.  It might
    just be better to forward gnome.org mail offsite, and only keep mail
    logs around a few days for debugging purposes.

  Web traffic logs, who visited what, anonymous or per-login; I think a 
    privacy policy should state that those logs (including the associated
    cookies) will *only* stay with gnome.org, meaning only gnome.org
    officers and optionally other gnome.org members (however defined) may
    look at them, and they may not give them to others. This should be
    incorporated into the charter of the organization so that only a
    revision of the charter (a big deal) can change that.  This should
    cover all access logs of any sort.  Of course, like above, if the feds
    come knocking you have to provide it, and of course this is not
    specific to the US.

  Board-private documents, private list (like this one) archives, etc.  

What are other areas where gnome.org may be collecting data that needs
protection?  Again, remember, only protect that which absolutely must be
protected, is the mindset I would use.  I'd even go so far as to say
board-private documents and discussion list archives should be public,
perhaps after a period of time.  

If you'd like collab.net to draft a privacy document for gnome based on
the above principles (probably just notably about traffic logs and
authentication, but extending to ISP-like issues if gnome.org does provide
that) then we'd be happy to.

	Brian