Providers' Commitment for Privacy (PCP)/ policy

Providers' Commitment for Privacy: Version 1.0

Translations: Castellano, Português

  1. Preamble
  2. Description of the security levels
    1. Short overview of level 1
    2. Short overview of level 2
    3. Short overview of level 3
  3. Modules
    1. What to do in case of fire?
    2. Mail
    3. Webmail
    4. Certificates and keys for encrypted stream-based services
    5. Filesystems and Storage
    6. Logs
    7. Users
    8. Evaluation of policy compliance
    9. Verification

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). 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.