Portuguese translation

6 files changed, 328 insertions, 29 deletions

diff --git a/about_pt.mdwn b/about_pt.mdwn
new file mode 100644
index 0000000..82a4321
--- /dev/null
+++ b/about_pt.mdwn
@@ -0,0 +1,15 @@
+# Sobre
+
+A versão inicial da política de "Compromisso dos Provedores com a Privacidade" (CPP) foi elaborada por um grupo internacional de participantes. A discussão foi estabelecida em inglês e levou aproximadamente 3 anos usando comunicação cara-a-cara e virtual (criptografada). Como resultado, o documento consensual está disponível nesse site.
+
+## Contato
+
+Os comentários e as dúvidas sobre a política podem ser enviados para
+pcp@lists.tachanka.org - há outra [chave OpenGPG](http://keys.mayfirst.org/pks/lookup?op=get&search=0x77D95A9012B3EEDA)
+associada com esse endereço. Você pode usá-la para enviar um e-mail criptografado:
+
+pub   4096R/0xE5C7B674AC07077F 2013-04-03
+      Key fingerprint = A1D1 ACCE 2B7C 608E 5830  39BB E5C7 B674 AC07 077F
+uid                            PCP (schleuder list) <pcp@lists.tachanka.org>
+sub   4928R/0x6AEF09BF684D2452 2013-04-03
+
diff --git a/best_practices_pt.mdwn b/best_practices_pt.mdwn
index 57f8d6e..8f3e74a 100644
--- a/best_practices_pt.mdwn
+++ b/best_practices_pt.mdwn
@@ -1,61 +1,144 @@
-# Best Practises
+# Anexo: Referências de boas práticas
 
-*Oficina de Boas Praticas 3 Abril 2013*
+Traduções: [[Castellano|best practices es]] [[Português|best practices pt]]
 
-Traduções: [[Inglés|best practices]] [[Espanhol|best practices es]]
+*Esse anexo contêm o texto da política com boas práticas específicas adicionadas abaixo das seções correspondentes. É um trabalho em andamento. Por favor, colabore!*
+
+Obviamente, cada nível de segurança/privacidade requer que você mantenha o seu software atualizado dos problemas de segurança conhecidos.
 
 # E-mail com Exim
 
-## Nvel 1
+## Nível 1
 
 …
 
-## Nvel 2
+## Nível 2
 
-### tls requerido com servidores parceiros, certificado verificados com 'fingerprint'
+### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com impressão digital.
 
- * [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)
+* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)
 
 # E-mail com Postfix
 
-## Nvel 1
+## Nível 1
+
+### Se o servidor adiciona o endereço IP de um usuário que está enviando um e-mail através do seu serviço em qualquer lugar do e-mail, o usuário/a é informado sobre isso.
+
+Não é uma questão de configuração do servidor: você deve usar seus canais de comunicação para passar essa informação para os seus usuários/as (p.e. newsletter, lista de anúncio). Os novos usuários/as devem ser informados, como parte do processo de abertura de nova conta. Você pode também explicar sobre isso em seu site.
+
+### As conexões entre o usuário e o servidor são sempre criptografadas.
+
+* Do lado do servidor: [Configurar o Postfix para usar o certificado X.509](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) acessado em 3 de Abril de 2013
+* Do lado do cliente: Peça para seu provedor a documentação :)
+
+### Usar (Start)TLS para trocar e-mails com outros servidores, sempre que disponível
+
+* Isso é chamado de criptografia *oportunística*.
+
+### O servidor deve ter seu próprio certificado X.509 assinado por uma das autoridades certificadoras.
+
+Há muitos problemas com o ecossistema X.509, parcialmente explicados aqui: http://lair.fifthhorseman.net/~dkg/tls-centralization/
+
+Dependendo do quão bem seus usuários entendem os certificados X.509, nós recomendamos 4 diferentes cenários:
+
+a. Autoridade Certificadora Comercial: geralmente é um serviço pago, mas os usuários/as não ficaram confusos porque seus clientes de e-mails já vem com certificados comerciais, então não haverǽ nenhuma mensagem de alerta sobre certificados não confiáveis. Isso não necessariamente aumenta a segurança da conexão uma vez que um atacante pode emitir certificados, pois uma autoridade certificadora pode ser desonesta ou um Estado, por exemplo. Veja a [Seção de Segurança na Wikipedia](https://en.wikipedia.org/wiki/X.509#Security) para mais detalhes.
+
+b. CaCert: os usuários ainda precisarão validar e instalar o certificado de raíz do CaCert, por que não é incluido em nenhum cliente de e-mail. Mas eles podem já terem feito esse procedimento para utilizar outros provedores. Há também um pacote Debian que torna-o fácil para usuários do Debian/Ubuntu instalarem.
+
+c. Certificados auto assinados/Autoridade própria: motivo contra: não está incluído nos clientes padrões de e-mail dos seus usuários. Eles precisam instalar os certificados (raíz). Se eles não controlam ("pinning") os certificados e possuem outras autoridades comerciais instaladas, você terá nada mais do que problemas. Você arrisca ensinar os seus usuários a ignorar as mensagens de alerta de segurança. Se propriamente aplicado por seu coletivo de cripto-ninjas, isso *pode* ser mais seguro.
+
+d. Monkeysphere: você pode usar as chaves OpenPGP (certificados) para autenticar serviços. Essa é uma solução tecnicamente excelente, no entanto, não é suportada por softwares comuns. Se você têm usuários/as com superpoderes, nós recomendamos experimentar. Mais informações no [site do Monkeysphere](http://monkeysphere.info/)
+
+## Nível 2
+
+### O servidor não adiciona o endereço IP de um usuário/a que está enviando um e-mail através do seu serviço, em nenhum lugar do e-mail.
+
+* [IPs nos cabeçalhos](https://we.riseup.net/debian/mail#postfix)
+
+### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com a impressão digital.
+
+Uma solução equivalente é implementar uma conexão IPsec entre os coletivos relevantes, assim torna desnecessário o uso do TLS.
+Para implementar isso, você precisa saber as impressões digitais atualizadas dos certificados dos grupos que você planeja cooperar dessa forma. Há várias maneiras de se fazer isso, mas depende tanto de um contexto social e técnico, então não iremos detalhá-los aqui, apenas afirmar que isso é um requerimento. Fixar ("pinning") essas impressões digitais e atualizá-las quando mudarem pode ser um aborrecimento (ao menos que um protocolo e uma implementação segura e automatizada para esse propõsito venha a ser desenvolvida).
+
+* [Postfix TLS LEIAME](http://www.postfix.org/TLS_README.html)
+
+## Nível 3
+
+### O e-mail é também disponível como um serviço oculto (hidden service) do Tor.
+
+* [Torproject: Tor Hidden Service documentation](https://www.torproject.org/docs/tor-hidden-service.html.en) → adaptar para as necessidades do servidor de e-mail.
+* Cliente: [torbirdy](https://trac.torproject.org/projects/tor/wiki/torbirdy) é uma extensão útil para fazer uso do serviço oculto.
+
+# Sistemas de arquivos e Armazenamento
+
+## Nível 1
+
+* Os dados do/a usuário/a não são acessíveis publicamente, eles são armazenados criptografados, usando uma senha forte. Veja os documentos de boas práticas para detalhes. Isso inclui e-mails, banco de dados, arquivos de listas, sites restritos e outros.
+
+No GNU/Linux, cryptsetup:
+
+* [Como configurar um sistema de arquivos criptografado em várias etapas?](http://www.debian-administration.org/articles/469)
+* [Configurando um sistema Debian criptografado](http://madduck.net/docs/cryptdisk/)
+
+## Nível 2
+
+### A swap é armazenada criptografada.
+
+Para isso você pode usar cryptsetup também.
+
+### O sistema operacional e sua configuração é armazenada criptografada com uma senha forte. Veja os documentos de boas práticas para os detalhes.
 
-### Se o servidor adiciona a direo IP de um usurio enviando um e-mail atravs de seu servio em qualquer parte do e-mail, o usurio  informado sobre isso.
+Hoje você pode usar muitos instaladores de Sistema Operacional que conseguem isso.
 
-No  um caso de configurao de servidor: voc deveria usar seus canais de comunicao para passar esta informao aos usurios (exemplo: newsletter, anncio da lista de e-mail). Novos usurios deveriam ser informados como parte do proceso de criao de conta. Voc deveria ter isto explicado no seu website.
+Não confie nos discos rígidos que possuem uma camada de discos criptografada, eles são frequentemente mal implementados ou podem vir com backdoors, por exemplo.
 
-### As conexes entre o usurio e o servidor deveriam ser sempre encriptadas.
+## Nível 3
 
-* Lado servidor: [Configurar Postfix para usar certificado X.509](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) de Abril 3 2013
-* Lado cliente: Pea ao seu provedor por documentao :D
+* A swap é criptografada com uma chave aleatória na inicialização.
+* Criar uma área da swap criptografada
 
-### Use (Start)TLS para intercambiar e-mails com outros servidores disponveis em qualquer lugar.
+http://www.microhowto.info/howto/create_an_encrypted_swap_area.html
+https://we.riseup.net/debian/encrypted-swap
+http://linux.die.net/man/5/crypttab -> seção "swap"
 
-### O servidor deve ser seu prprio certificado X.509 assinado por um entre as autoridades de certificado asignadas.
+# Boas práticas (antigo)
 
-H muitos problemas com o ecossistema X.509, parcialmente explicado [aqui](http://lair.fifthhorseman.net/~dkg/tls-centralization/)
+## E-mail
 
-Dependendo do quo seus usurio entendem certificados X.509, recomendamos 4 cenrios diferentes:
+* [IPs no cabeçalho](http://riseuplabs.org/privacy/postfix/): o endereço de IP da casa do/a usuário/a não deve aparecer no cabeçalho do e-mail *nível 2*
+* Se aparecer, os/as usuários/as devem ser informados sobre isso e *nível 1* talvez mostrar o IP do servidor ao invés de localhost com o [hack do riseup](http://riseuplabs.org/privacy/postfix/)
+* A conexão entre o servidor e o usuário/a sempre é criptografada. *Nível 2*
+* A opção de comunicação não-criptografada entre o usuário/a e o servidor deve estar visivelmente marcada como insegura. *Nível 1*
+* [StartTLS-postfix](http://metatron.sh/kmw/Transformers/PostfixCacertVerifyHowto) ou [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls com outros servidores parceiros, certificados verificados versus cacert/... *nível 1*
+* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) - o TLS é requirido com outros servidores parceiros, certificados verificados com impressão digital *nível 2*
 
-a. Certificado Comercial: geralmente custa dinheiro, mas os usurios no se confundem pois os clientes de e-mail j vem com certificados comerciais, ento no haver estas mensagem de cuidado ou perigo relacionadas a certificados que no so confiveis. No aumenta a segurana da conexo, pois o adversrio pode expedir certificados pois uma autoridade de certificado pode ser dbia ou ser um estado, por exemplo. Olhe a esta pgina na Wikipedia https://pt.wikipedia.org/wiki/X.509 para mais detalhes.
+## Os certificados e as chaves são criptografados para os serviços baseados em stream
 
-b. CaCert: Os usurios ainda necesitaro validar e instalar certificados CaCert de root pois ele ainda no estar incluido em nenhum cliente de e-mail. Mas eles j podem ter feito este passo para outros provedores. Tambm h um pacote Debian que faz isso mais fcil de instalar para usurios Debian/Ubuntu.
+* As chaves privadas são armazenadas criptografadas *Nível 2*
+* As chaves privadas são somente armazenadas criptografadas e off-site *Nível 3*
+* Comunicação baseada em stream usa apenas uma configuração bem estabelecida de parâmetros criptográficos (cifras, message digests, algoritmos de criptografia assimética, etc). Veja os documentos de boas práticas para detalhes. *Nível 1*
 
-c. Certificados self-signed (auto-assinados): no esto includos em clientes de e-mail padro. Eles devem instalar certificados root. Se eles no usarem "pinning" de certificado, mas tiverem outro certificado comercial ainda instalado, voc no ganhar nada alm de confuso. Voc se arrisca a ensiar seus usurios em trespassar mensagems de alarme de segurana. Se corretamente aplicado pelo seu coletivo de crypto-ninjas, isto *pode* ser mais seguro.
+Se você estiver usando mod_ssl com apache e uma chave RSA para o servidor, sugerimos:
 
-d. Monkeysphere: Vocpode usar chaves openPGP (certificados) para autenticar servios. Isto  tecnicamente uma soluo excelente, ainda que no realmente reconhecido por softwares populares. Se voc tiver conhecimento, recomendamos que tente. Mais informao em http://monkeysphere.info/
+<code>SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS</code>
 
-## Nvel 2
+## Log
 
-### O servidor no adiciona a IP do usurio enviando um e-mail atravs deste servio em nenhum lugar deste e-mail.
+* Os logs contendo informação de identificação do usuário/a são armazenados criptografados ou apenas na memória. De outro modo os usuários devem ser informados sobre isso. *Nível 1*
+* Os logs não possuem nenhuma informação identificação do usuário/a. *Nível 3*
 
-* [IPs nos cabealhos]( https://we.riseup.net/debian/mail#postfix )
+Logs do Apache sem nenhum endereço IP: [mod_removeip](http://riseuplabs.org/privacy/apache/)
 
-### TLS  requerido com outros servidores que cumpram o level 2. Certificados so verificados com uma 'fingerprint'.
+Usando Debian com Apache2:
 
-A soluo equivalente  implementar um link de IPsec entre os coletivos relevantes, o que faz o uso de TLS desnecessrio.
+      apt-get install libapache2-mod-removeip
+      a2enmod removeip
+      /etc/init.d/apache2 force-reload
 
-De maneira a implementar isto, voc precisa saber
+* Os logs contendo informação sobre as atividades não-individuais dos usuários/as são armazenados criptografados ou apenas memória. *Nível 1*
+* Os logs não possuem nenhum informação sobre as atividades não-individuais dos usuários/as. *Nível 2*
+* Os logs do sistema (não relacionados com as atividades dos usuários/as) são armazenados criptografados ou apenas na memória. *Nível 2*
 
-In order to implement this, you need to know the up-to-date fingerprints of the certificates of the groups that you plan to cooperate with in this way. There are many ways to do this, but it depends too much on social and technical context so we will not detail them here, only state that it is a requirement. Pinning those fingerprints and updating them when changed can be a hassle (unless an automated and secure protocol and implementation for this purpose becomes available).
+Acompanha "Sistemas de arquivos e Armazenamento Nível 2"
 
+* Os logs do sistema (não relacionados com as atividades do usuário) não são armazenados. *Nível 3*
diff --git a/index.mdwn b/index.mdwn
index a230758..d470c31 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -9,7 +9,7 @@ policy. You can find the following information here:
  * Presentation [[slides|pcp28c3.pdf]] from [[28C3|http://events.ccc.de/congress/2011/wiki/Welcome]]
  * Clone the website: "git clone git://git.sarava.org/policy.git"
 
-Access this website as a Tor hidden service using http://xhwel4ofzss5n7ha.onion/
+Access this website as a Tor hidden service using http://crfrudzhbpynkmki.onion
 
 ----
 Wiki powered by [[ikiwiki]].
diff --git a/index_pt.mdwn b/index_pt.mdwn
new file mode 100644
index 0000000..4d56931
--- /dev/null
+++ b/index_pt.mdwn
@@ -0,0 +1,14 @@
+# Política de Compromisso dos Provedores com a Privacidade
+
+Bem vindo ao site da política do Compromisso dos Provedos com a Privacidade (CPP). Você pode encontrar aqui as seguintes informações:
+
+ * O texto da [[policy_pt|política]]
+ * Sugestões para [[best practices_pt|Boas Práticas]]
+ * [[Contact information|Sobre]]
+ * Os [[slides|pcp28c3.pdf]] de apresentação no [[28C3|http://events.ccc.de/congress/2011/wiki/Welcome]]
+ * Como clonar este site: "git clone git://git.sarava.org/policy.git"
+
+Acesse esse site usando o serviço oculto (hidden service) do Tor http://xhwel4ofzss5n7ha.onion/
+
+----
+Wiki powered by [[ikiwiki]].
diff --git a/policy_pt.mdwn b/policy_pt.mdwn
new file mode 100644
index 0000000..3fddb5b
--- /dev/null
+++ b/policy_pt.mdwn
@@ -0,0 +1,183 @@
+__Compromisso dos Provedores com a Privacidade: _Versão 1.0___
+
+Traduções: [[Castelhano|policy_es]], [[Inglês|policy]]
+
+[[!toc levels=2]]
+
+# Preâmbulo
+
+Este documento contém vários aspectos sociais e técnicos que devem levar a um tratamento mais seguro dos dados privados dos usuários.
+
+À luz da vigilâcia crescente e medidas repressivas estabelecidas por muitos governos na primeira década deste milênio, é cada vez mais necessário melhorar o entendimento e a consciência dos usuários/as sobre as questões relacionadas à privacidade, assim como os níveis de privacidade  oferecidos por coletivos técnicos e grupos.
+
+Com esse rascunho, estamos tentando criar mais transparência para nossos usuários/as. Esse documento determina o que os usuários/as podem esperar dos coletivos técnicos e grupos que o assinam, em termos de uso de criptografia, registro de IPs e armazenamento de dados.
+Outra razão para escrever esse documento é encorajar a conscientização sobre a privacidade/segurança entre nós. Esse rascunho deve ser usado para pressionar administradores/as de sistema, coletivos e grupos para fazerem a coisa certa. De forma a reduzir o trabalho envolvido, os coletivos técnicos assinantes e grupos devem compartilhar o conhecimento e escrever padrões que possam ser implementados por outros coletivos técnicos e grupos.
+
+Dito isso, tenha em mente que:
+
+1. O fato de um coletivo técnico ou grupo assinar esse documento não é uma garantia por si só; como usuário/a, você deverá ter uma relação de confiança com o coletivo técnico ou grupo, baseado em relações pessoais, não em assinaturas. Seus dados só podem estar tão seguros como as pessoas que mantém o servidor que os hospeda.
+
+2. Não existe um servidor perfeitamente seguro! Erros humanos e bugs de software podem expor seus dados, revelar sua identidade, enviar você para a cadeia e matar o seu gato.
+
+3. Nada que seu coletivo técnico ou grupo preferido faça será suficiente para protegê-lo/a do escrutínio intenso e direto de uma poderosa organização. Se você suspeita que está sendo alvo de vigilância especial, você precisa agarrar a sua privacidade com as suas próprias mãos.
+ 
+# Descrição dos níveis de segurança
+
+_O computador é para a indústria de informação aproximadamente o que uma usina de energia é para a indústria elétrica. -- Peter Drucker_
+
+Não existe nenhum serviço que seja ao mesmo tempo perfeitamente seguro e que também proteja totalmente a privacidade dos usuários/as finais. A política definida abaixo portanto foi feita para enumerar os diferentes níveis de segurança e privacidade. Cada coletivo técnico deve tentar alcançar o nível mais alto possível. Mesmo o nível mais alto definido, a configuração ideal pode estar além do que está proposto nesse documento. Em muitos casos será impossível preencher alguns pontos devido a vários problemas: técnicos, sociais, recursos etc. Os níveis definidos tem a intenção de tornar mais fácil para os usuários/as dos serviços entenderem, e como resultado, tomarem decisões melhores sobre a segurançá e a privacidade de seus dados. Devem também servir como guias para administradores/as de sistema que precisem de uma visão geral dos vários aspectos envolvidos nessas importantes questões e de alguns objetivos que eles possam esforçar-se para atingir.
+
+A política define três níveis de segurança e privacidade. O primeiro nível (nível 1) contém requisitos básicos para os serviços, é definido como menos seguro e provendo menos garantia de privacidade que o "nível 2". Preenchendo os requisitos do nível mais alto (nível 3) será o maior desafio para coletivos técnicos e irá, na maior parte dos casos, proteger os dados dos usuários melhor. As seguintes descrições dos níveis tem a intenção de dar uma visão geral breve das diferenças principais entre cada um dos níveis. Por favor consulte a lista específica de requisitos para maiores detalhes. E atenção, quanto mais alto o nível, mais difícil é de alcançar ou para os usuários verificarem.
+
+## Resumo do _nível 1_
+
+* As conexões com todos os serviços são criptografadas por padrão. Se uma conexão não criptografada alternativa for oferecida, ela deve ser marcada visivelmente para avisar os usuários/as.
+* Os e-mails enviados através do serviço podem incluir informações que identifiquem o usuário/a (por exemplo, o endereço IP do host de origem)
+* Somente os dados que ainda não são publicamente acessíveis devem ser armazenados criptografados (por exemplo, dados privados do usuário/a)
+* É possível que registros (logs) com dados que identifiquem os usuários/as sejam armazenados sem criptografia.
+* A adequação com essa política é revisada pelos administradores/as pelo menos uma vez por ano.
+
+## Resumo do _nível 2_
+
+* As conexões entre usuários/as e o serviço é sempre criptografada.
+* Os e-mails não contém informações que identifiquem o usuário/a.
+* Nenhuma informação que identifique os usuários/as é armazenada em registros (logs).
+* O sistema operacional do serviço e suas configurações só são armazenados criptografadas.
+* A adequação com essa política é revisada pelos administradores/as pelo menos uma vez a cada seis meses.
+
+## Resumo do _nível 3_
+
+* Todos os serviços também estão disponíveis como serviços ocultos (hidden services) do Tor
+* Não são armazenados registros (logs).
+* A adequação a esta política é revisada pelos administradores/as pelo menos uma vez a cada três meses.
+
+
+# Módulos
+
+Obviamente, cada nível de segurança/privacidade requer que você mantenha o seu software atualizado dos problemas de segurança conhecidos.
+
+## O que fazer em caso de incêndio?
+
+### Nível 1
+
+* Tenha certeza que você tenha meios de se comunicar com os usuários/as quando o servidor ficar offline. Isso pode ser um canal alternativo de comunicação (p.e. e-mail alternativo, telefone, ...) ou uma página web de status  off-site.
+
+## E-mail
+
+### Nível 1
+
+* Se o servidor adiciona o endereço IP de um usuário que está enviando um e-mail através do seu serviço em qualquer lugar do e-mail, o usuário/a é informado sobre isso.
+* As conexões entre o usuário/a e o servidor são sempre criptografadas.
+* Usar (Start)TLS para trocar e-mails com outros servidores, sempre que disponível
+* O servidor deve ter seu próprio certificado SSL assinado por uma das autoridades certificadoras. Veja os documentos de boas práticas para mais detalhes.
+
+### Nível 2
+
+* O servidor não adiciona o endereço IP de um usuário/a que está enviando um e-mail através do seu serviço, em nenhum lugar do e-mail.
+* O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com a impressão digital.
+
+### Nível 3
+
+* O e-mail é também disponível como um serviço oculto (hidden service) do Tor.
+
+## Webmail 
+
+### Nível 1
+
+* As conexões entre o servidor e o usuário/a são sempre criptografadas.
+* Se o endereço de IP do usuário aparece nos cabeçalhos do e-mail, esse fato é visivelmente marcado como inseguro.
+
+### Nível 2
+
+* Todas as sessões deve ser armazenadas como cookies. Os IDs das sessões não podem ser localizadas na URL.
+* O endereço de IP do usuário/a não aparece em nenhum cabeçalho de e-mail.
+
+
+### Nível 3
+
+* Devido ao fato que scripts do lado do cliente, como um Javascript, podem revelar o endereço de IP do usuário/a (essa é a razão porque usuários do Tor geralmente desativam-o), o Webmail é funcional sem isso.
+* O algoritmo de ID da sessão e os cookies não usam ou armazenam o endereço de IP dos usuários/as, nem em texto puro ou embaralhado. As sessões não são restritas para um endereço de IP (uma vez que isso impediria o acesso com ferramentas de anonimato como o Tor).
+* O webmail está também disponível como um serviço oculto (hidden service) do Tor
+
+## Os certificados e as chaves são criptografados para os serviços baseados em stream
+
+### Nível 1
+
+* A comunicação baseada em stream usa apenas uma configuração bem estabelecida de parâmetros criptográficos (cifras, message digests, algoritmos de criptografia assimética, etc). Veja os documentos de boas práticas para detalhes.
+
+### Nível 2
+
+* As chaves privadas são apenas armazenadas criptografadas.
+
+### Nível 3
+
+* As chaves privadas são somente armazenadas criptografadas e off-site.
+
+## Sistema de arquivos e Armazenamento
+
+### Nível 1
+
+Os dados do usuário/a não são acessíveis publicamente, eles são armazenados criptografados, usando uma senha forte. Veja os documentos de boas práticas para detalhes. Isso inclui e-mails, banco de dados, arquivos de listas, sites restritos e outros.
+
+### Nível 2
+
+* A swap é armazenada criptografada.
+* O sistema operacional e sua configuração é armazenada criptografada com uma senha forte. Veja os documentos de boas práticas para detalhes.
+
+### Nível 3
+
+* A swap é criptografada com uma chave aleatória na inicialização.
+
+## Logs
+
+### Nível 1
+
+* Os logs são armazenados criptografados ou apenas na memória.
+
+### Nível 2
+
+* Os logs são anonimizados e não contém nenhuma informação que pode identificar as atividades dos usuários.
+
+### Nível 3
+
+* Nenhum log de nenhum tipo é armazenado.
+
+## Usuários
+
+### Nível 1
+
+* Os usuários/as são aconselhados sobre boas práticas e senhas. Veja os documentos de boas práticas para detalhes.
+
+### Nível 2
+
+* Os usuários/as são forçados a usarem senhas fortes, elas são medidas por um algoritmo bem conhecido de força de senha. Veja os documentos de boas práticas para detalhes.
+* As contas de terminal para usuários/as são apenas em vservers, compartimentos separados ou ambientes similares. Nenhum usuário final possui um login no servidor que provê serviços sensíveis. Veja os documentos de boas práticas para detalhes.
+
+### Nível 3
+
+* As contas de terminal são isoladas dos outros usuários: cada conta shell do usuário existe num ambiente chroot, o qual não é visível para o ambiente de outro usuários (arquivos, processos, etc.).
+
+## Avaliação do cumprimento da política
+
+### Nível 1
+
+* Auto-avaliação anual: verificar no mínimo a cada doze meses se os requisitos que deveriam ter sido alcançados realmente foram.
+
+### Nível 2
+
+* Auto-avaliação semestral: verificar no mínimo a cada seis meses se os requisitos que deveriam ter sido alcançados realmente foram. 
+
+### Nível 3
+
+* Auto-avaliação trimestral: verificar no mínimo a cada três meses se os requisitos que deveriam ter sido alcançados realmente foram. 
+
+## Verificação
+
+A atual versão dessa política é assinada com uma chave OpenPGP ([keyserver](https://keys.mayfirst.org/pks/lookup?op=get&search=0xCE8BA23183EC5CB69760E02F8BC0E739D0645843)). Os detalhes da chaves são esses:
+
+
+    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
+
+O arquivo assinado está [[aqui|policy-signed.txt]].
diff --git a/sidebar_pt.mdwn b/sidebar_pt.mdwn
new file mode 100644
index 0000000..aeef466
--- /dev/null
+++ b/sidebar_pt.mdwn
@@ -0,0 +1,4 @@
+* [Início](/)
+* [[Política]]
+* [[Boas Práticas]]
+* [[Sobre]]