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 :
- SLAWA-0L-ED: Core rules + zero-logging + encrypted data (riseup?)
- SLAWA-LC-NC: Core rules + answer to legal requests + control on the network (No-log)
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:
- Self-explicit name (Zero logging)
- Short code (0L)
- Human readable description: The server does not save at any moment logs with any information able to identify its users. (Is that too technical, even?)
- Tech readable description: In any logs enabled in the server, there should not be any IPs, usernames or too explicit URLs saved anywhere.
- Tech HOWTO: Use syslog-ng with such configuration snipet: [...].
Minimum cooperation to legal requests
lunar: The "policy" should cleary define the way the "cooperation" is made when receiving legal requests for groups doing so. It means:
- Only accept snail mail requests with acknowledgement
- Only accept requests sent by "juge d'instruction" (l10n needed here)
- Never send more than what was exactly asked
- Never keep personal data when not strictly required to by the laws (in France, no need for the real name of an email owner, IIRC)
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
lunar:
- Have a first version ready at the end of the conference which would fit to a least 3 collectives.
- Discuss a bit further (not more than one month) on-line with collectives not present for the final consensus
- Put Logo on our websites, release communiqué, do noise.
- (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
- See what's needed to be changed either in servers or policy for other collectives.
- Debates a bit
- 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)).