English version below

[IT]

Cosa sta succedendo?

Presto smetteremo di offrire i nostri servizi anche su un Hidden Service Tor dedicato. Non vi preoccupate! Riuscirete ancora ad usare Tor con A/I, solo non passando per l’Hidden Service.

Abbiamo dovuto riconoscere che da un po’ di tempo non stiamo gestendo al meglio il nostro Hidden Service, e che non possiamo permetterci lo sforzo abbastanza considerevole di migliorare questa gestione. Questa decisione è stata ampiamente discussa all’interno del collettivo e siamo giunti alla conclusione che la soluzione migliore per noi e per i nostri utenti sia la dismissione dell’Hidden service.

Le ragioni che sottendono questa decisione sono squisitamente tecniche e le spieghiamo in dettaglio più avanti nel post, per quell@ abbastanza interessat@, ma si riducono a questo: abbiamo costruito la nostra infrastruttura di autenticazione in un modo che rende complicato supportare contemporaneamente “lo spazio dei nomi internet” e “lo spazio dei nomi .onion“. Questo sistema di autenticazione è fondamentale, perché offre una serie di meccanismi di sicurezza implementati dai browser moderni che riteniamo importante avere. Farli funzionare in entrambi i “mondi” ci richiederebbe un considerevole impegno a fronte di quello che crediamo sia un miglioramento limitato.

Potete ancora usare Tor con A/I (e vi incoraggiamo a farlo), visitando direttamente i nostri servizi www.autistici.org, mail.autistici.org o il nome appropriato, invece di usare il nostro vecchio indirizzo .onion, ricordando però di validare il certificato SSL!

Per la spiegazione tecnica dettagliata, continuate a leggere!

Perché ora?

Nessuno dei problemi di cui discuteremo più avanti è una novità, sono già stati ampiamente discussi e le persone che lavorano con Tor ne sono ben al corrente. Quindi perché questa decisione da parte nostra proprio adesso? In effetti il momento coincide con la dismissione dei vecchi Hidden Service V2, condizione che ci ha fatto valutare nuovamente la condizione del nostro Hidden Service che è stato ampiamente trascurato a seguito dell’ultima revisione architetturale dei nostri servizi di qualche tempo fa. Il nostro Hidden Service era in pessime condizioni: la sovrapposizione che ha con il layer SSL incoraggiava gli utenti a tenere pratiche di sicurezza malsane (ad esempio, ignorare completamente tale layer), e comunque il sito web non era utilizzabile attraverso l’indirizzo .onion. Abbiamo deciso di sistemare definitivamente questa situazione.

Qual è il problema?

In ciò che segue, assumiamo che abbiate una certa familiarità con concetti tecnici quali HTTP, cookie, funzionamento interno del browser, ecc.

Il cuore del problema nasce dallo stretto accoppiamento tra il dominio di sicurezza del browser e lo spazio dei nomi (quello internet e quello .onion accennato prima) usato per accedere ai servizi. La problematica nasce quando si prova a servire entrambi gli spazi di nomi contemporaneamente come nel caso di gruppi che, come noi, offrono gli stessi servizi via Internet e via Hidden Service.

Consideriamo il sistema di autenticazione che stiamo usando. Esso fornisce una funzionalità di single sign-on e, come molti servizi simili, si basa molto fortemente sui cookie e, ancora più problematicamente, sui redirect HTTP. Se l’endpoint che deve essere autenticato non ha cognizione dello spazio di nomi utilizzato per raggiungerlo, esso redirigerà ciecamente l’utente non autenticato verso il servizio di login su Internet (e non su quello .onion), commettendo una violazione di dominio che potrebbe essere molto indesiderata per l’utente. Aggiungere questa logica (la capacità di distinguere lo spazio dei nomi di origine) ad ogni endpoint autenticato necessita di una quantità di lavoro molto significativa da parte nostra, senza contare l’aumento di complessità del sistema. La conseguenza sarebbe di finire con due sistemi di autenticazione separati (e fondamentalmente incompatibili, come spiegato più avanti).

Questo stesso sistema di autenticazione offre la possibilità (e incoraggia) ad usare dei cosiddetti hardware token (dispositivi fisici) per l’autenticazione a due fattori. Anche questi dispositivi sono strettamente legati al dominio del sito visitato, quindi un utente dovrebbe registrare il proprio hardware token due volte per i due spazi di nomi. Ma questo non è possibile, perché all’atto della prima registrazione il sistema avrebbe già associato un hardware token all’account [to be clarified], quindi per poter fare il login adesso via Hidden Service c’è bisogno di un hardware token legato allo spazio dei nomi in chiaro. Problemi simili li avrebbero i password manager.

Al momento quindi fornire i nostri servizi via Hidden Service non è praticabile. Questa necessità di duplicare completamente il sistema di autenticazione risulterebbe in un sistema mal funzionante nel migliore dei casi e in uno insicuro nel peggiore. Ci siamo chiesti, di fronte alla considerevole quantità di lavoro necessaria per affrontare i problemi illustrati poc’anzi, se ne valesse la pena. Negli ultimi 10 anni l’ecosistema SSL delle Certification Authority è significativamente migliorato, sia perché molte più persone si affidano all’integrità dell’infrastruttura di certificazione sia grazie alla nascita di servizi come Letsencrypt. Forse affidarsi ad SSL è diventato meno irragionevole di un tempo.

Considerando le nostre risorse limitate, preferiamo non supportare il caso d’uso dell’Hidden Service, piuttosto che farlo in maniera impropria o errata. Questa decisione non è stata presa a cuor leggero, alcun@ di noi sono avid@ utenti di Tor.

Ritorneremo periodicamente su questa decisione e sui compromessi affrontati prima, e saremo felici di riconsiderare la nostra decisione, se le circostanze (tecniche e non solo) cambieranno in futuro. Se per esempio il naming layer API venisse nativamente supportato da Tor e da Tor Browser Bundle, potremmo più facilmente riconsiderare la nostra posizione.

Grazie per la pazienza e per il supporto.

Domanda: posso ancora usare Tor per connettermi ai vostri servizi?

Certamente! Stiamo solo sospendendo il nostro Hidden Service (servito su .onion). Sui vostri client che usano Tor, potete benissimo continuare ad usare i nostri servizi, solo sostituendo il .onion con i nomi dominio internet www.autistici.org, mail.autistici.org o il nome appropriato, e ricordando di validare i certificati SSL.

Domanda: e per quel che riguarda i servizi non web

L’obiezione è lecita: perché ritirare l’Hidden Service anche per quei servizi che non usano HTTP come trasporto (come ad esempio la chat XMPP e i servizi mail via IMAP/SMTP)? La dimensione del problema qui è minore, ma alcuni dei problemi menzionati prima si applicano anche in questo caso, in maggior parte a causa della sovrapposizione tra il layer SSL e quello Hidden Service per la gestione della fiducia. Preferiamo avere un unico approccio consistente nell’uso dei nostri servizi via Tor.

[EN]

What is happening

We will soon stop offering our services on a dedicated Tor Hidden Service address. Don’t worry, you will still be able to use Tor with A/I, just without the Hidden Service!

We’ve come to recognize that for a while now we haven’t been doing a great job at running Hidden Services, and that we can’t afford the (considerable) effort to do it well. This decision has been debated for some time in the collective, and we came to the conclusion that dismissing the Hidden Service is the best way forward for us and for our users.

The reasons behind this decision are technical and are explained in detail below, for those interested enough, but they boil down to this: we have built our authentication system in such a way that it would be difficult and cumbersome to support both “the Internet name space” and “the .onion name space”. We consider the authentication system very important, it offers a lot of modern browser safety features we care about. Making it function properly in both “worlds” would take considerable amount of work, for what we think would be very little gain.

You can, and should, still use Tor with A/I, just by using www.autistici.org, mail.autistici.org or the appropriate service name in place of the old .onion address, and remembering to validate the associated SSL certificates.

For the detailed technical explanation, see below!

Why now?

None of the following issues are new, as they all have been discussed already and the people working with Tor are familiar with them. So why are we taking this decision now? Well, the timing is coincidental with the deprecation of V2 Hidden Services, which made us consider again the state of our Hidden Service, which had been largely neglected since our latest architectural changes of a few years ago. This state wasn’t good: the overlap of Hidden Services and SSL encouraged the adoption by users of bad security practices (by ignoring the SSL layer), and the web site wasn’t functional at all. We decided that this situation had to be cleared up.

What is the problem

We’re going to assume familiarity with the technical concepts discussed here such as HTTP, cookies, inner workings of the browser, etc.

The problematic issues stem from the strict coupling between the browser’s security domains, and the namespace used to access the websites (the Internet one, or the .onion one). The issues arise once one tries to serve both namespaces at once, as it is the case for groups like ours who are offering the same services both on the Internet and on a Hidden Service.

Let’s consider the authentication system we are using. It provides single sign-on functionality, and like many similar systems, it relies heavily on cookies and, more problematically, on HTTP redirects. If the endpoint under authentication is not aware of the namespace used to reach it, it will blindly redirect the user to a non-onion login server, committing a domain violation which may be very undesirable for the user. Adding this awareness logic to each and every authenticated endpoint is a significant amount of work, and a noticeable increase in the overall complexity of the system. We would fundamentally end up with two separate (and largely incompatible, see below!) authentication systems.

The same authentication system makes use (and encourages) of hardware tokens for 2FA. These are also strictly bound to the web site’s domain name, so a user would need to register the same hardware token twice, once on the public site, once on the onion site. Except that they won’t, because now there’s a hardware token required for the second login, which can’t be validated on the other site yet! Password managers will have a similar problem.

Another surprising aspect in which namespace binding breaks our single sign-on system concerns logouts: the duplication of authentication systems would mean that, if you are logged in on both the public web site and the onion one, logging out from one will not log a user out from the other. This is not surprising if one considers that there is nothing that says that these two authentication systems are in fact related to the same website.

So, at the moment, serving our website over Hidden Service is not really an option. This complete duplication of the authentication system would result in a badly-functioning system at best, an insecure one at worst. When facing the considerable amount of work that it would take to solve the above-mentioned issues, and even if one is willing to ignore the impact of the associated increased complexity, it is worth asking if it would be worthwhile at all? In the last decade the SSL ecosystem of Certification Authority has significantly improved, both because a lot more people rely on the integrity of the certificate infrastructure and because of the appearance of services like Letsencrypt, so perhaps relying on SSL is less unreasonable now than it used to be.

Considering our limited resources, we prefer to not support the Hidden Service use case for the time being, rather than doing it badly and in a broken fashion. This decision has not been taken lightheartedly. Some of us are avid Tor users and support this technology.

We will periodically re-evaluate the trade-offs mentioned above, and will happily reconsider our decision if the circumstances (technical or otherwise) change in the future. For example, we will reconsider our decision if the naming layer API is supported natively by Tor and the Tor Browser Bundle.

Thanks for your patience and support.

Q: Can I still use Tor to connect to your services?

Absolutely yes! We are just suspending the .onion Hidden Service. Just use the Internet names for our services, www.autistici.org, mail.autistici.org or the appropriate service name in place of the old .onion address, with any Tor-enabled client, and remember to validate the associated SSL certificates.

Q: What about non-web services

The objection is legit: why take away the hidden service endpoint for those services that are not HTTP-based (like, for example, the XMPP chat service or the IMAP/SMTP email services). The problem space here is simpler, but some of the concerns mentioned above apply to these services too, mostly due to the overlap of the Hidden Service and SSL trust layers. And we would like to have one single consistent approach for using our services over Tor.

Se siete a Berlino o dintorni, non perdetevi il benefit techno queerfemminista per A/I che si terrà il 16 marzo a partire dalle 22.

If you are in Berlin or surroundings, don’t miss the queerfeminist techno soli-party in support of A/I on the 16 March starting from 10pm.

(altro…)

**AGGIORNAMENTO IMPORTANTE PER LA VOSTRA SICUREZZA**
**IMPORTANT UPDATE FOR YOUR SECURITY**
**ACTUALIZACION IMPORTANTE PARA VUESTRA SEGURIRDAD**

Ancora brutte notizie.
Durante il processo di reinstallazione dell’infrastuttura abbiamo identificato un’altra vulnerabilità. Da circa due mesi era infatti in corso un tentativo di accaparramento delle password degli account di posta, durato fino a pochi giorni fa. Se vi siete loggati su autistici.org per leggere la posta della webmail, la vostra password è da considerarsi probabilmente compromessa. Ora possiamo comunque dire che questo specifico problema ora è stato risolto ed era sicuramente uno strascico dell’intrusione che vi avevamo precedentemente segnalato.

Dobbiamo quindi consigliarvi nuovamente di cambiare le password dei vostri account, e di scegliere password forti.

Se non vi ricordate come cambiare la password del vostro account, leggete queste istruzioni: https://www.autistici.org/docs/userpanel#passwordchange

Inoltre vi suggeriamo di prendere seriamente in considerazione l’utilizzo dell’autenticazione a due fattori per proteggere il vostro account: coloro che l’avevano impostata non sono stat* infatti interessat* dalla vulnerabilità oggetto di questo aggiornamento.

Ve lo abbiamo detto e ripetuto, a costo di sembrare pedanti, ma la riservatezza delle vostre comunicazioni non dipende solo da noi. Noi ce la stiamo mettendo tutta per mettere in sicurezza l’infrastruttura, voi intanto dovreste provvedere a mettere in sicurezza i vostri account.

Quanto accaduto nelle ultime settimane è significativo: quel che è successo non è ordinaria amministrazione. Non possiamo garantire di aver individuato tutti i problemi – alcuni dei quali sono evidentemente di livello sistemico – che affliggevano la sicurezza della nostra infrastruttura. Per questo crediamo sia necessaria una risposta adeguata. E la nostra risposta, come già accaduto in passato, sarà la completa revisione, che realizzeremo nei prossimi mesi, dell’architettura su cui si basa l’infrastruttura di A/I.

Pubblicheremo in seguito una descrizione più dettagliata del piano e aggiornamenti sull’andamento dei lavori.

Lavori in corso

Ecco un breve elenco dei lavori che abbiamo portato a termine nelle ultime settimane per mettere in sicurezza l’infrastruttura:

• Tutte le macchine che compongono l’infrastuttura sono state reinstallate.
• I bug e le vulnerabilita’ emersi durante il processo di reinstallazione sono stati risolti.
• Tutte le password di amministrazione sono state modificate.
• Abbiamo cominciato il processo di pianificazione del design della nuova infrastruttura.

(altro…)

Nell’ambito della reinstallazione e della messa in sicurezza dell’infrastruttura, abbiamo deciso di generare una nuova chiave GPG, non perché quella precedente fosse palesemente compromessa, ma perché stiamo procedendo con la massima cautela possibile dopo quanto abbiamo scoperto.

La nuova chiave GPG che useremo d’ora in poi è questa. Potete scaricarla anche dai keyserver, per esempio qui.

While reinstalling and securing our infrastructure, we have decided to generate a new GPG key. The key had not been clearly compromised, but we wanted to be as cautious as possible after the breach in our servers.

From now on, the GPG key we will use is this. You can also download it from the keyservers, for example here.

Segui il nostro tweet per aggiornamenti sulla reinstallazione dell’infrastruttura

Read our updates on Twitter for news on the reinstallation of our infrastructure

[English version below]
[Versión en Español mas abajo]
[Portuguese]

Ieri, giovedì 14 settembre, abbiamo scoperto che qualche giorno fa un account di amministratore è stato compromesso. Appena ce ne siamo resi conto, abbiamo cominciato immediatamente a lavorare per risolvere il problema. Abbiamo già realizzato le mitigazioni necessarie e siamo riusciti nuovamente a rimettere tutto in sicurezza. Sono ancora in corso analisi dei log e la reinstallazione dell’infrastruttura.

Stiamo analizzando i dettagli della situazione per sapere esattamente che cosa è successo. Data la natura dell’intrusione, potenzialmente tutti i dati degli utenti sono stati accessibili agli intrusi, ma al momento non abbiamo prove del fatto che siano state toccate delle caselle di posta.

Come misura di sicurezza minima, dovresti cambiare tutte le tue password e le domande di recupero dei tuoi account (email, webdav, lista di email e newsletter, noblogs.org). Ti consigliamo di usare una password forte.

Inoltre raccomandiamo sempre caldamente, se ancora non lo hai ancora fatto, di attivare l’autenticazione a due fattori (2FA) per tenere il tuo account più al sicuro.

Nel caso l’autenticazione 2FA fosse già stata abilitata, dovrai resettarla, disattivandola e riattivandola.

Se ne hai la possibilità, scarica sempre i messaggi di posta sul tuo computer, conservandoli con la dovuta cautela, invece di lasciarli sui nostri server. Inoltre per maggior sicurezza ricorda sempre di crittografare le tue comunicazioni:

* email
* chat

[English version]

Yesterday, on Thursday 14 September, we found out that a few days ago an admin account had been compromised. As soon as we spotted this intrusion, we immediately got to work for solving the problem. We have already taken the necessary mitigation measures and have secured the machines. We are still analyzing logs and reinstalling the infrastructure.

We are examining the details of the situation to figure out what happened exactly. Given the nature of this intrusion, all users’ data might have potentially been accessed by the intruders, but so far we have found no evidence that someone touched the mailboxes.

As a minimum security requirement, you should change all your passwords and the recovery questions for your accounts (email, webdav, mailing lists and newsletters, noblogs.org). We recommend to create strong passwords for this.

We also strongly suggest, if you haven’t done so already, to activate 2-factor authentication to secure the access to your account.

If you have already enabled 2-factor authentication, you should reset that too, by deactivating it and activating it again.

If you can, always download your email messages to your personal computer, storing them with care, instead of keeping them in our servers. Also, remember to secure your communications by encrypting them:

* email
* chat

[Español]

Ayer, jueves 14 de Septiembre, hemos descubierto hace unos días que una cuenta de administración de nuestra infraestructura había sido violada. En cuanto nos hemos dado cuenta hemos empezado a trabajar para resolver el problema. Hemos tomados las medidas de mitigación necesarias y hemos puesto en seguridad las maquinas. Estamos todavía analizando los logs y reinstalando la infraestructura.

Estamos también examinando los detalles de la situación para averiguar lo que ha ocurrido. Dada la naturaleza de la violación, los intrusos han tenido acceso a todos los datos de los usuarios, pero en este momento no tenemos pruebas de que hayan tocado las cuentas de correo.

Como medida mínima de seguridad, tienes que cambiar las contraseñas y las preguntas de seguridad de todas tus cuentas (email, webdav, listas de correo y newsletters, noblogs.org). Te recomendamos de crear contraseñas fuertes.

También te recomendamos, si no lo has hecho todavía, activar la autenticación de dos factores (2FA).

Si ya tenias la autenticación de dos factores habilitada, tendrás que resetearla, deshabilitandola y volviendo a habilitarla.

Si puedes, descargate siempre los mensajes de tu correo en tu ordenador personal, y guardalos con cuidado, en vez de dejarlos en nuestros servidores. También recuérdate de cifrar tus comunicaciones:

* correo
* chat

[Portuguese]

No dia 14 de Setembro, descobrimos depois de alguns dias que uma conta de administração da nossa infraestrutura foi violada.
Na hora que descobrimos isso, começamos imediatamente e trabalhar para resolver o problema. Já realizamos as mitigações necessárias e conseguimos assegurar novamente las maquinas

Estamos analisando os detalhes da situação para saber exatamente o que aconteceu. Considerando a naturaleza de la violação, os intrusos tiveram acesso a todos os dados de usuários, mas nesse momento não temos prova que tocaram as contas de email.

Como medida minima de segurança, tem que mudar sua senhas e suas perguntas de seguridade de todas suas contas (email, webdav, listas, newsletter, noblogs.org). Recomendamos usar senhas forte.

Também recomendamos, se ainda você não está ativo, ativar a autenticação 2FA

Se você já tem 2FA habilitada, você precisa reconfigurá-la, desativando e reativando a mesma.

Se pode, baixa sempre suas emails no seu computador, e guardá-las com cuidado, em lugar de manter as email dentro do nossos servidores. Também lembra-se de criptografar suas comunicações:

Para maior segurança lembra sempre de encriptar suas comunicações:

* email
* bate-papo

[English version below]

Nelle ultime settimane abbiamo aggiornato l’infrastruttura di Autistici/Inventati, concentrandoci in particolare sul servizio di instant messagging Jabber/XMPP. L’obiettivo era permettervi di usare Jabber su dispositivi mobili, offrendo un’alternativa ai sistemi più diffusi, che sono centralizzati, appartengono spesso a grandi aziende e sono quindi esposti a misure censorie e repressive. Inoltre abbiamo scritto nuovi manuali per facilitare la configurazione di nuovi client per il nostro server Jabber.

Dettagli tecnici e nuove funzionalità

(altro…)

[English version below]

Con grande gioia vi annunciamo un altro passo avanti negli strumenti che mettiamo a disposizione per una comunicazione libera e autonoma.

tl;dr: grazie a Let’s Encrypt la CA non serve più!

… che poi vorrebbe dire: avete presenti quei messaggi inquietanti che vi mandava il vostro browser quando aprivate le pagine di A/I e di Noblogs? Be’, quella storia è finita! Ora potete andare a festeggiare, oppure continuare a leggere le nostre spiegazioni più sotto (noi vi raccomandiamo la seconda opzione…). Ma soprattutto ricordate: se continuate a ricevere messaggi inquietanti, stavolta vale la pena di preoccuparsi.

Come sapete, i nostri servizi online supportano – o in certi casi richiedono – l’uso di SSL, un sistema crittografico basato sulla distribuzione di certificati che garantiscono una connessione sicura ai vari server. L’integrità di questi certificati è fondamentale e non abbiamo mai accettato di partecipare al sistema di distribuzione commerciale dei certificati SSL; questo avrebbe significato mettere il rapporto di fiducia tra noi e i nostri utenti nelle mani di soggetti di cui non ci si può fidare: stati, forze “dell’ordine”, aziende il cui solo fine è il profitto.
Perciò finora abbiamo gestito la cosa autonomamente con una nostra Autorità di Certificazione (CA). Il rovescio della medaglia era la necessità – per i nostri utenti, ma anche per i semplici visitatori dei siti web – di seguire una procedura un po’ complicata per installare il certificato della nostra CA.

Non siamo mai state completamente contente di questa situazione, perché crediamo che per risultare efficace la crittografia debba essere utilizzabile senza difficoltà. Da questo punto di vista, il progetto Let’s Encrypt è un’importante risorsa per chiunque usi internet, ma il beneficio per noi e voi è ancora maggiore, perché l’utilizzo di SSL con i server di A/I ora diventa più semplice.

Cosa cambia nella pratica?

• La nostra CA e la procedura di installazione del suo certificato scompaiono.
• I certificati SSL dei domini di A/I sono ora firmati dalla CA di Let’s Encrypt.
• … e soprattutto il certificato della CA di Let’s Encrypt è già installato nel browser che state usando: Non serve quindi fare nient’altro per poter navigare correttamente sui nostri siti web via HTTPS o per stabilire una connessione sicura con i nostri server di posta.
• L’unica cosa che vi raccomandiamo di fare è di controllare che i vostri
  client siano tutti configurati per non accettare certificati SSL non validi
  (come per esempio consigliavamo di fare per Xchat).

Troverete informazioni aggiornate nella pagina di documentazione specifica su SSL.

[English version]

We have some good news about the tools for a free and autonomous communication we provide you with.

tl;dr: thanks to Let’s Encrypt our CA has become useless!
(altro…)

[English version below]

2FA, ovvero: raddoppia la sicurezza della tua mail

Il 2015 è quasi finito e, come (quasi) tutti gli anni, abbiamo preparato un regalo speciale per scongiurare la sfiga delle feste e, soprattutto, delle intrusioni nelle caselle di posta. Si tratta di un pensierino dal nome un po’ criptico, ma abbastanza fondamentale di questi tempi. Si chiama 2FA, che vuole dire “two-factor authentication”, autenticazione a due fattori, e il concetto è molto semplice: una volta che lo avrai attivato, per entrare nella tua webmail avrai bisogno di una cosa che sai (la tua password) e di una cosa che hai (il tuo smartphone). In questo modo diventerà più difficile per qualche malintenzionato leggere le tue mail, perché anche se qualcuno riuscisse a intrufolarsi in qualche modo nel tuo computer e a soffiarti la password, avrebbe bisogno anche di rubarti il telefono per accedere alla tua casella. Semplice, no? E allora cosa aspetti?

Attiva subito la 2FA per la tua mailbox!

Per farlo bastano pochi passi:

1. Accedi al tuo pannello utente.
2. Clicca sul tuo nome utente in alto a destra sulla barra nera.
3. Nel menu a tendina che si è appena aperto, clicca su “Abilita autenticazione a doppio fattore (OTP)”.
4. Segui le istruzioni (in sostanza devi installare un’app sul tuo telefono, impostare la domanda di recupero della password se non l’hai ancora fatto e alla fine cliccare sul tasto “Abilita”).

Un paio di avvertimenti importanti:

• La 2FA è per la webmail: per il resto dovrai generare una password specifica.
  Per i client di posta come Thunderbird e per Jabber/XMPP (Pidgin, Jitsi) avrai bisogno di una password generata appositamente, che potrai usare soltanto per un particolare client su un particolare dispositivo. Per creare una password per il tuo client di posta o per Jabber/XMPP, leggi queste istruzioni.
• Una volta che avrai attivato l’autenticazione a due fattori, il tuo punto debole sarà proprio la domanda di recupero della password: se infatti qualcuno vuole accedere alla tua casella di posta e non ci riesce perché non ha il tuo telefono, potrebbe semplicemente provare a resettare la tua password. Per questo è essenziale che la tua domanda di recupero riguardi davvero qualcosa che nessun altro può sapere, e addirittura alcuni consigliano di usare una domanda e una risposta di fantasia. In sintesi l’essenziale è ricordare che:
  1. Se perdi il telefono, l’unico modo di avere accesso alla tua casella di posta è attraverso la domanda di recupero.
  2. Se la risposta alla domanda si trova sui social network, la tua casella non sarà sicura anche se hai impostato l’autenticazione a due fattori.
• Se non hai uno smartphone e non hai nessuna intenzione di procurartene uno, una soluzione c’è, ma è complicata e prevede l’acquisto di una YubiKey. Troverai il comando per configurare la YubiKey nella pagina di istruzioni che si aprirà quando cliccherai il tasto “Abilita”. Se vuoi saperne di più, segui questo blog, dove prossimamente vogliamo pubblicare un post di approfondimento.

Il tuo sostegno è sempre essenziale

Nel 2016 Autistici/Inventati compie 15 anni, e in questi 15 anni abbiamo creato un’infrastruttura resistente che ha permesso di comunicare e di esistere in rete a tanti gruppi e individui attivi nelle lotte più diverse per un mondo migliore (o almeno un po’ meno tetro e deprimente).

Dato che non prendiamo neanche il becco di un quattrino per tenere in piedi questi servizi, l’esistenza di questa infrastruttura è soprattutto merito della nostra comunità di utenti, che continuano a sostenerci con le loro donazioni.

Anche se mail, siti, blog, mailing list, VPN e quant’altro sono offerti gratuitamente, infatti, per noi nulla di tutto questo è
gratuito, e, anzi, i costi che sosteniamo sono consistenti. Quindi è venuto il momento di ricordare tutto questo e di pensare a noi: sostienici anche quest’anno con la tua donazione! Anche un contributo minimo può fare la differenza.

Ci sono molti modi per contribuire. Scegli quello che fa meglio al caso tuo qui.

* * *

Dicembre 2015
Collettivo Autistici/Inventati
https://www.inventati.org https://www.autistici.org
contribuisci: https://www.autistici.org/it/donate.html

* * *

ENGLISH VERSION

(altro…)

[English version below]

Ultimamente ci è stato segnalato un tentativo di phishing a nostro nome.
Il testo era questo:

Your AUTISTICI.ORG Mailbox Has Exceeded Its Quota Limit And You May
Not Be Able To Send Or Receive New Mails Until You Re-Validate.

To Re-Validate, Please Click: RE-VALIDATE For More
Storage Data to Be Added To Your Mailbox

Thank You,
AUTISTICI.ORG Mail Team

E come in ogni tentativo di phishing che si rispetti, il link inserito nel testo non rimandava a un nostro sito ma da qualche altra parte dove qualche simpatico gruppo di malintenzionati si sarebbe appropriato del nome utente e della password del/la malcapitato/a.

Sono cose che capitano e che tutte e tutti noi abbiamo già visto, ma giusto per una ripassatina, ecco alcuni consigli:

• Nelle nostre comunicazioni noi non vi chiediamo mai di cliccare su un link: molto più probabilmente il nostro invito sarà di accedere al vostro pannello utente, come fate di solito per leggere la vostra mail, all’indirizzo: https://www.autistici.org/pannello/.
• Quando ricevete una mail che vi chiede con urgenza di cliccare su un link, controllate sempre che il mittente sia chi dice di essere. Nel nostro caso, la mail arriverà da un dominio @ autistici.org — molto probabilmente da info @ autistici . org
• Se l’indirizzo del mittente vi sembra convincente, controllate che anche il link lo sia.
• Per ulteriori informazioni potete leggere questo manuale dell’Electronic Frontier Foundation (in inglese e altre lingue ma non ancora in italiano).

English version
(altro…)

[English version below]

A partire da oggi entrano definitivamente in vigore le direttive del garante della privacy italiano sui cookies e siamo tenute per legge, pena multe salatissime, a inserire su tutti i blog di Noblogs e su tutti i siti che usano cookies un banner che vi richiede il consenso esplicito all’uso dei cookies.

Si tratta esclusivamente di una formalità, e dal punto di vista del funzionamento dei server di A/I non cambia niente: Autistici/Inventati, e quindi NoBlogs, non registra alcuna infomazione sugli utenti né effettua alcuna profilazione.

Ma che cosa sono i cookies, a che servono e perché vengono usati anche su Noblogs e sui siti di A/I?

I cookies sono informazioni registrate nel tuo computer (o smartphone) quando visiti un sito web. Alcuni, quelli che usiamo noi (i cosiddetti cookies tecnici) servono a facilitare e a velocizzare la navigazione, altri a interfacciarsi con servizi come Twitter o Youtube (i “cookies di terze parti”) e altri ancora per profilare gli utenti a scopo commerciale. Questi ultimi non sono usati sui server di A/I per policy, e di conseguenza neanche i nostri utenti possono usarli nei loro siti.

Quindi non sarete profilati se visitate un sito di A/I o un blog di Noblogs. Considerate però che, a prescindere dalla nuova legge e dal banner d’ordinanza, se accedete a un sito o a un social network commerciale i cookies di profilazione non mancano mai. Se questa idea non vi piace, l’ideale è cancellare i cookies ogni volta che chiudete la sessione del browser: un’opzione che si trova nelle impostazioni del vostro browser.


English version
(altro…)