Random ideas and comments

lunar: base on SecurityProtocolsWorkingGroup/DraftTwo

Name proposal

lunar: Service Level Agreement For/With/Toward Activists (so either SLAFA, SLAWA, SLATA)

elijah: i would like something that makes sense to non-techies. service level agreement is techy language. i agree that protocols is also a techy word. how about "privacy agreement for autonomous servers"?

lunar: Mh... what about re-using the Debian vocabulary (I did in fact in my previous comments by switching from "protocol" to "policy"...) like "Social contract with the activist community"? Maybe "social" is not suited for a technical document...

Optional sections handling

lunar: We all agree on a "core" rules to follow. Then, for each optional rule, have some additional tag à la Creative Commons.

Examples :

elijah: i like the geekiness of this, but i would like two use the security protocols to educate our users, not just as something that we understand. perhaps this information can be presented in a pretty chart?

lunar: Sure, I was thinking of having something very like it already exists for CC, by having for the core and each optional tag/feature/rules:

lunar: The "policy" should cleary define the way the "cooperation" is made when receiving legal requests for groups doing so. It means:

Security scanner for PHP flaws

lunar: Put aside the fact that the needed software doesn't exist yet, for a further revision of the policy, we should agree that a scanner for known security holes in hosted web applications has to run on the service.

Collective administration

lunar: A server managed by a single human can be seen as very faillible. Should we put in the policy that at least 2 sysadmins are needed?

Email backups

lunar: Should we allow emails backups? RAID like redundancy is fine, but should we allow users to be mistaken when they delete an email, thinking that it's gone for good?

Could be made optional, tag NB (No backups).

Workflow proposal


  1. Have a first version ready at the end of the conference which would fit to a least 3 collectives.
  2. Discuss a bit further (not more than one month) on-line with collectives not present for the final consensus
  3. Put Logo on our websites, release communiqué, do noise.
  4. (Taken from Haskell design process) Name an *Editor*
    • Should be different for each revision
    • Responsible for driving debates to a conclusion
    • Custodian of the policy
    • Responsible for embodying the group's conclusions in the policy
  5. See what's needed to be changed either in servers or policy for other collectives.
  6. Debates a bit
  7. Release next version, rince, repeat

there is no such thing as secure

elijah: while i am eager for agreed security protocols, i also think that blicero's criticism is totally true. there is no such thing as a secure server. we should not tell users they should trust us. we should tell them "this is what we do, trust us if you have a reason to trust us". at the same time, i feel it is vitally important that we make a case why people should dump yahoo/gmail/hotmail etc. so it is tricky.

elijah: also, we should make it clear that the level of security we attempt to provide is for the most number of people for the most amount of time, and that if people suspect they might be the targets of particular state repression, they need to practice special measures. nothing that we do will protect them from intense directed scrutiny from the state and they need to take their own privacy into their own hands

elijah: so, could these things be included in a preamble? a disclaimer at the beginning about trust and security.

lunar: definitely. Encourage them to get off the Internet and use pen & paper when information should not be spread?

Disaster Recovery

Disaster Recovery is an important topic currently missing from the policy draft. Radical Tech Collectives (RTC) should internally document how they will recover from temporary or final loss of * servers and more technical infrastructure (hardware failure, seizure etc.) * people (illness, detention, death) * other (non-technical) infrastructure that is required for other things to work correctly

It should be documented how each of these can be repaced in short term, what knowledge and resources are required and how they could be attained short term (this should also include whom to turn to for help (and money)).

STAMP: SecurityProtocolsWorkingGroup/DraftTwo/Comments (dernière édition le 2008-12-19 18:59:53 par anonyme)