1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
__Providers' Commitment for Privacy: _Version 1.0___
Translations: [[Castellano|policy_es]], [[Português|policy_pt]]
[[!toc levels=2]]
# Preamble
This document contains many social and technical issues, that should lead to a more secure handling of private user data.
In light of the increased surveillance and repression measures established by many governments in the first decade of this millennium, it is now even more necessary to improve users' understanding and awareness of privacy matters, as well as the privacy levels offered by tech collectives and groups.
With this draft, we are trying to create more transparency for our users. This document states what users can expect from the tech collectives and groups that signed it, in terms of the use of encryption, logging of ip's and data storage.
Another reason to write this document is to encourage a privacy/security awareness amongst us. This draft can be used to put pressure on sysadmins, collectives and groups to do the right thing. In order to reduce the work involved, the signing tech collectives and groups share knowledge and write down standards that can be implemented by other tech collectives and groups.
This being said, beware:
1. The fact that a tech collective or group signed this document is not a guarantee in itself; as a user you should have a trust relationship with the tech collective or group based on personal relations, not on signatures. Your data can only be as secure as the human beings who maintain the server it is stored on.
2. There is no such thing as a perfectly secure server! Human mistakes and software bugs can disclose your data, reveal your identity, send you to jail and kill your kitten.
3. Nothing that your preferred tech collective or group does will be enough to protect you from intense directed scrutiny from a powerful organization. If you suspect you are the target of special surveillance, you need to take your own privacy into your own hands.
# Description of the security levels
_The computer is to the information industry roughly what the
central power station is to the electrical industry.
-- Peter Drucker_
There is no such thing as service that is both perfectly secure and one that fully protects the end-user's privacy. The policy defined below thus is designed to enumerate different levels of security and privacy. Each tech collective should try to reach the highest possible level. Even at the highest defined level, the ideal setup may be somewhere beyond what is proposed in this document. In many cases it will be impossible to fulfill some points due to various problems: technical, social, resources, etc. The levels defined are intended to make it easier for users of services to understand, and as a result, make better decisions about the security and privacy of their data. They also should serve as guidelines for sysadmins who need an overview of the various aspects involved in these important issues and some of the goals that they should strive to attain.
The policy defines three levels of security and privacy. The first level (level 1) contains basic requirements for services, its defined as less secure and providing less privacy assurances than “level 2”. Fulfilling the requirements of the highest level (level 3) will be the most challenging to implement for the technical collectives and will, in most cases, protect users’ data better. The following descriptions of the levels are meant to give a short overview of the key differences between each. Please refer to the specific list of requirements for more details. Yet beware, the higher the level, the harder it is to achieve or verify for the user.
## Short overview of _level 1_
* Connections to all services are encrypted by default. If a non-encrypted alternative connection is offered, then this must be marked visibly to warn users.
* Mail sent through the service can possibly include user identifiable information (e.g. the IP address of the originating host).
* Only data that is not already publicly accessible has to be stored encrypted (e.g. user private data)
* It is possible that user identifiable logs are stored without encryption.
* Compliance with the policy is reviewed by the administrators at least once in a year.
## Short overview of _level 2_
* Connections between users and the services they use are always encrypted.
* Mails contain no user identifiable information.
* No user identifiable information are stored in logs.
* The operating system of the service and its configuration are only stored encrypted.
* Compliance with the policy is reviewed by the administrators at least once within six months.
## Short overview of _level 3_
* All services are also available as hidden Tor services.
* No logs are stored.
* Compliance with the policy is reviewed by the administrators at least once within three months.
# Modules
Obviously, every security/privacy level requires that you keep your software up to date to the current knowledge of security issues.
## What to do in case of fire?
### Level 1
* Make sure to have means of communication to users when the server goes down. This can be an alternative communication channel (e.g. external mail, phone, ...) or an off-site status web page.
## Mail
### Level 1
* If the server adds the IP address of a user sending a mail through its service anywhere in the email, the user is informed about this.
* The connections between the user and the server are always encrypted.
* Use StartTLS to exchange mails with other servers whenever available.
* The server must have its own SSL certificate signed by one of a given set of certificate authorities. See best practices documents for details.
### Level 2
* The server doesn't add the IP address of a user sending a mail through its service anywhere in the email.
* TLS is required with other level 2 compliant servers. Certificates are verified with fingerprint.
### Level 3
* Mail is also available as an enclaved hidden Tor service.
## Webmail
### Level 1
* The connections between the server and the user are always encrypted.
* If the user's IP address appears in the email headers, this fact is visibly marked as insecure.
### Level 2
* All sessions must be stored as cookies. Session IDs cannot be in the URL.
* The user's IP address does not appear in any email headers.
### Level 3
* Due to the fact that client-side scripting, such as Javascript, can reveal the user's IP address (this is why users of Tor typically disable it), Webmail is functional without it.
* The session ID algorithm and cookies do not use or store the user's IP address, neither in plain text or some garbled form. Sessions are not restricted to IP addresses (since this would prevent access with anonymity tools such as Tor).
* Webmail is also available as an enclaved hidden Tor service.
## Certificates and keys for encrypted stream-based services
### Level 1
* Stream-based communication uses only a well-established set of cryptographic parameters (ciphers, message digests, asymmetric encryption algorithms, etc). See best practices documents for details.
### Level 2
* Private keys are only stored encrypted.
### Level 3
* Private keys are only stored encrypted and off-site.
## Filesystems and Storage
### Level 1
* User data that is not publicly accessible is stored encrypted, using a strong passphrase. See best practices documents for details. This includes mails, databases, list archives, restricted websites and others.
### Level 2
* Swap is stored encrypted.
* The operating system and its configuration is stored encrypted with a strong passphrase. See best practices documents for details.
### Level 3
* Swap is encrypted with a random key on boot.
## Logs
### Level 1
* Logs are stored encrypted or only in memory.
### Level 2
* Logs are anonymized and contain no information that can identify user activities.
### Level 3
* No logs of any kind are stored.
## Users
### Level 1
* Users are advised about good passwords and polices. See best practices documents for details.
### Level 2
* Users are forced to use strong passwords, as measured by a generally accepted password strength algorithm. See best practices documents for details.
* Shell accounts for users are only in vservers, separate boxes, or similar sandboxes. No end user have a login on a server that provides sensitive services. See best practices documents for details.
### Level 3
* Shell accounts are isolated from other users: each user's shell account exists in a chrooted environment that has no visibility into other user's environments (files, processes, etc.).
## Evaluation of policy compliance
### Level 1
* Yearly periodic self-evaluation: checking at least every twelve months that requirements supposed to be achieved actually are.
### Level 2
* Semi-yearly self-evaluation: checking at least every six months that requirements supposed to be achieved actually are.
### Level 3
* Quarterly self-evaluation: checking at least every three months that requirements supposed to be achieved actually are.
## Verification
The current version of the policy is signed with an OpenGPG key
([keyserver](https://keys.mayfirst.org/pks/lookup?op=get&search=0xCE8BA23183EC5CB69760E02F8BC0E739D0645843)). Key
details are as follows:
pub 4096R/D0645843 2011-12-28 [expires: 2013-01-31]
Key fingerprint = CE8B A231 83EC 5CB6 9760 E02F 8BC0 E739 D064 5843
uid Providers Commitment for Privacy
The signed file is [[here|policy-signed.txt]].
|
