ore 10:20 CEST
Da circa 6 ore uno dei server non è raggiungibile, stiam lavorando per recuperarlo.
ore 16:20 CEST
I servizi sono stati ripristinati.
10:20 CEST
For about 6 hours one of the servers has been unreachable, we are working to recover it.
16:20 CEST
Service has been restored.
17:15
AGGIORNAMENTO: Risolto! – UPDATED: Fixed!
_______________________________________________________________
C’è un qualche problema al login di alcuni server di posta, ci stiam lavorando
There are issues on login, we are working to fix.
Ciao,
questa email arriva da un sistema automatizzato di Autistici/Inventati che controlla lo spazio usato dagli account di posta. Il tuo account “XXXXXXXXXXX@inventati.org” sta usando *1.2 GB* di spazio!
Questo è TANTISSIMO, per favore cerca di cancellare o archiviare messaggi vecchi il prima possibile, non possiamo tollerare a lungo termine che le utenti usino così tanto spazio (è anche un po’ ingiusto
verso tutti gli altri)…
Grazie,
Autistici/Inventati”
____
Nelle ultime settimane abbiamo ripreso la buona pratica, che era già attiva qualche anno fa, di avvisare chi supera la quota del GIGA (1miliardo di Byte) nelle caselle mail.
Ovvero se il peso di un 1 Kilobyte (KB) in formato testo equivale circa ad una mezza pagina scritta, 1GB significa che avete lo spazio di 500’000 pagine per la vostra corrispondenza,
detti anche 1’000 libri belli spessi, ovvero da 500 pagine l’uno.
Ecco è troppo, vi chiediamo di essere persone più leggere e di ridurre l’archiviazione sui nostri server possibilmente alle mail che vi servono solo davvero al momento.
grazie!
Similmente potresti ricevere degli avvisi da parte nostra riguardo all’uso del disco se hai delle risorse hostate da noi o che ti ricordano di aggiornare il sito.
In nessun caso, mai forniamo un link da seguire su cui autenticarti! Quello lo sai tu.
Occhio al phishing!
Se ti è possibile, come collettivo o singola, passa ad un doppio fattore di autenticazione, sia sulla casella email che sui tuoi siti web e noblogs.org
Poi, qualunque cosa abbiate fatto, ne approfittiamo per ricordarvi di farvi il vostro backup. :)
(BACKUP = la copia di quello che avete nel PC, su un altro hardisk da tenere al sicuro e possibilmente tutto cifrato.)
DOMANDE FREQUENTI SU QUESTO ARGOMENTO:
POP3 la posta si scarica sul mio computer, ma se poi io apro la mia webmail da un altro computer o dal tablet vedrò, o non vedrò, le mail salvate?
se la scarichi con POP3 e la cancelli dal server sara’ visibile solo sul dispositivo dove l’hai scaricata.
Puoi scegliere di non cancellare tutta la posta dal server ma solo quella piu’ vecchia di tot (in automatico nelle opzioni di thunderbird, o a mano da webmail) in modo da tenere tutta la posta recente sul server e disponibile ai vari dispositivi, oppure spostare in cartelle dedicate tutta la posta “importante”,
da tenere sempre, perche’ POP3 scarica solo la INBOX, e scaricare/cancellare dal server tutto il resto.
puoi vedere la guida qui’ per come configurare thunderbird con POP3: https://www.autistici.org/docs/mail/thunderbird
e puoi definire anche per quanti giorni lasciare i msg sul server.
Come si fa a scaricare anche le cartelle su Thunderbird?
Se non vuoi usare POP3, che è un protocollo che a differenza di IMAP, ti fa scaricare la tua posta su un solo computer, puoi attivamente scaricare ogni tanto la tua posta che occupa molto spazio così
https://www.autistici.org/docs/mail/archive
Lo spazio che usi sul server viene ricalcolato una volta al giorno, quindi devi aspettare un po’ prima di vedere quanto spazio hai salvato scaricando le email.
Tutte le altre domande frequenti… https://www.autistici.org/docs/faq/
Hello,
this is the automated system at Autistici/Inventati that looks after e-mail accounts. Your email account “XXXXXXXXXXXXXXXXX@autistici.org” is using at least 1.2 GB of space!
This is REALLY A LOT, please delete or download and archive some emails as soon as possible, we can’t tolerate such a high usage of our shared resources (it is a bit unfair to all our other users).
Thank you,
Autistici/Inventati
____
In recent weeks we have resumed the good practice, which was already active a few years ago, of alerting those who exceed the GIGA (1 billion Bytes) quota in their mailboxes.
That is, if the weight of a 1 Kilobyte (KB) in text format is roughly equivalent to half a page of writing, 1GB means you have the space of 500,000 pages for your correspondence,
also called 1,000 nice thick books, that is, 500 pages each.
Here is too much, we ask you to be lighter people and reduce the storage on our servers possibly to the mails you only really need at the moment.
thank you!
Similarly, you may receive notices from us about disk usage if you have resources hosted by us or that remind you to update the site.
Under no circumstances do we ever provide a link for you to follow on which to authenticate! You know that one.
Watch out for phishing!
If you can, as a collective or individual, switch to double factor authentication, both on the email box and on your websites and noblogs.org
Then, whatever you have done, take the opportunity to remind you to make your own backup. :)
(BACKUP = the copy of what you have in your PC, on another hardisk to keep safe and possibly all encrypted).
FREQUENTLY ASKED QUESTIONS ABOUT THIS TOPIC:
POP3 mail downloads to my computer, but if I then open my webemail from another computer or tablet will I see, or not see, the saved emails?
if you download it with POP3 and delete it from the server it will only be visible on the device where you downloaded it.
You can choose not to delete all mail from the server but only that older than tot (automatically in thunderbird options, or by hand from webmail) so that you keep all recent mail on the server and available to the various devices, or move all “important” mail to dedicated folders,
to keep at all times, because POP3 downloads only the INBOX, and download/delete everything else from the server.
you can see the guide here for how to configure thunderbird with POP3: https://www.autistici.org/docs/mail/thunderbird
and you can also define for how many days to leave the msg’s on the server.
How do you also download folders to thunderbird?
If you don’t want to use POP3, which is a protocol that unlike IMAP, makes you download your mail to only one computer, you can actively download your mail that takes up a lot of space from time to time like this
https://www.autistici.org/docs/mail/archive
The space you use on the server is recalculated once a day, so you have to wait a while before you see how much space you’ve saved by downloading emails.
All the others Frequently asked questions: https://www.autistici.org/docs/faq/
Settimana scorsa ci siamo accorte che il sistema di videocall si era bloccato.
Ci spiace, abbiam sistemato è tutto tornato ad operare su: https://vc.autistici.org/
Intanto ne approfittiamo per dire che:
Abbiamo uno dei server di ingresso, che risponde in modo un po altalenante. Se non vi da la pagina, fate un refresh!
L’anomalia è dovuta ad uno dei nostri provider che ha un problema, siam fiduciosi che a breve sistemino.
Che cos’è un server di ingresso?
Ah.. ma allora non avete letto l’Orangebook del 2004, che descrive la forma della nostra infrastruttura!?
We have one of the server that answer to the web request, that is not working as usual, so if you have a problem, please first refresh!
The problem is due to an issue from one of our servers provider, we trust that will be resolved soon.
What is an “enter server”?
Ah.. but so you didn’t read the Orangebook in the 2004, that describes the shape of our infrastructure!?
–> English version at the bottom <–
–> Español abajo <—
[ITA]
Visto che PGP/GPG è ancora usato (e usabile) per la crittazione della posta, abbiamo deciso di facilitarne l’utilizzo: adesso è possibile associare la propria chiave GPG al proprio account di posta, rendendola “scopribile” automaticamente dai corrispondenti.
Dal vostro pannello utente, dopo il login, troverete modo di caricare la vostra chiave GPG: https://www.autistici.org/docs/userpanel#pgp
Che significa in pratica? Mediante il protocollo WKD (per maggiori dettagli vedi https://wiki.gnupg.org/WKD) un corrispondente può trovare la chiave per, per esempio, utente@autistici.org, facendo una richiesta HTTPS e delegando in pratica la discovery delle chiavi a chi gestisce l’infrastruttura della posta (siamo noi! yeah). Questo meccanismo fornisce un’alternativa ai classici keyserver PGP, che da tempo non godono di buona salute.
Noi abbiamo fatto una parte, ora sta a voi creare la vostra chiave GPG, se non ne avete già una, scegliere un client di posta che vi permetta di cifrare, per esempio Thunderbird, e caricare le vostre chiavi pubbliche sui nostri server.
Vi ricordiamo che questo è solo un pezzo della vostra sicurezza e vi tocca sempre stare all’occhio prima alla vostra sicurezza fisica e poi a dove appoggiate le vostre risorse per la comunicazione, quindi nei vostri device una cura particolare alla scelta di un sistema operativo open e poi attenzione ad i comportamenti collettivi che tenete online. Ma questo ve lo abbiamo già detto altre volte.
Per i più smanettoni qui trovate il codice del servizio che abbiamo implementato, sviluppato in collaborazione con i compagni/e di sindominio.net: https://git.autistici.org/ai3/tools/wkd, nella speranza sia utile anche ad altri gestori di server radicali.
A/I
[EN]
Since PGP/GPG is still used (and usable) for mail encryption, we decided to make it easier to use: it is now possible to associate your GPG key with your mail account, making it “discoverable” automatically by correspondents.
From your user panel, after logging in, you will find a way to upload your GPG key: https://www.autistici.org/docs/userpanel#pgp
What does this mean in practice? By means of the WKD protocol (see https://wiki.gnupg.org/WKD for more details) a correspondent can find the key for, say, utente@autistici.org, by making an HTTPS request and basically delegating key discovery to those who manages the mail infrastructure (that’s us! yeah). This mechanism provides an alternative to classic PGP keyservers, which have been long been in poor health.
We’ve done a part, now it’s up to you to create your own GPG key, if you don’t already have one, choose a mail client that allows you to encrypt, for example Thunderbird, and upload your public keys to our servers.
We remind you that this is just one piece of your security, and you always have to be on the lookout first for your physical security and then for where you back up your communication resources, so in your devices, special care to choose an open operating system and then attention to the collective behaviors you keep online. But we’ve told you this before.
For the more geeky ones here is the code for the service we implemented, developed in collaboration with fellow members of sindominio.net: https://git.autistici.org/ai3/tools/wkd, in the hope that it will be useful to other radical server operators as well.
A/I
[ES]
Visto que PGP/GPG todavía se usa (y se puede usar) para el cifrado del correo electrónico, hemos decidido facilitar su uso: ahora es posible asociar tu clave PGP a tu cuenta de correo electrónico, haciéndola “descubrible” automáticamente a tu correspondencia.
Desde el panel de usuario, después de iniciar sesión, encontraréis el modo de subir vuestra clave GPG: https://www.autistici.org/docs/userpanel#pgp
¿Qué significa en la práctica? Mediante el protocolo WKD (para más detalles ver https://wiki.gnupg.org/WKD) alguien con quien te escribes podrá encontrar tu clave, por ejemplo usuario@autistici.org, haciendo una petición HTTPS y delegando el descubrimiento de claves a quien gestiona la infraestructura del correo (somos nosotros! yeah). Este mecanismo ofrece una alternativa a los servidores clásicos PGP, que desde hace tiempo no gozan de buena salud.
Nosotros hemos hecho una parte, ahora os toca a vosotrxs crearos una clave GPG si no tenéis todavía, elegir un cliente de e-mail que permita el cifrado, por ejemplo Thunderbird, y subir vuestra clave a nuestros servidores.
Os recordamos que esto sólo es una parte de vuestra seguridad y que siempre debéis estar atentxs primero a vuestra seguridad física y luego a donde ponéis vuestros recursos para la comunicación, así que tened especial cuidado de elegir un sistema operativo abierto para vuestros dispositivos y luego prestad atención al comportamiento colectivo que tenéis en línea. Pero esto ya os lo hemos dicho otras veces.
Para lxs más avanzadxs, aquí está el código fuente que hemos implementado, desarrollado en colaboración con lxs compas de sindominio.net:
https://git.autistici.org/ai3/tools/wkd, con la esperanza que sea útil para otrxs gestores de servidores radicales.
A/I
[English below]
In data 2022-05-07 faremo un aggiornamento del nostro servizio jabber. In conseguenza di ciò si perderà la storia delle comunicazioni di tutte le chat room.
È da un po’ di tempo che siamo insoddisfatti dello stato del nostro servizio di chat jabber (uno dei servizi che offriamo, compresi nell’account di posta). Provando ad essere sintetici, il motivo è legato alla scelta, forse inadeguata per noi, del tipo di server con cui offriamo questo servizio. Attualmente usiamo ejabberd che, pur essendo un’interessante pezzo di software, è risultato di difficile configurazione e gestione. Un’alternativa esiste: prosody. Abbiamo lavorato nelle ultime settimane ad un piano di migrazione, che comprende anche la migrazione della lista di contatti (il cosiddetto roster) e dei messaggi offline. Speriamo non ci siano intoppi. Posteremo aggiornamenti sullo stato della migrazione alla fine di questo articolo.
[English version]
On 2022-05-07 we will migrate our jabber service. Because of that, the history of all chat rooms will be lost.
It has been a while now that we feel uncomfortable with the state of our chat jabber service (it’s one of the services we offer, together with the email account). Trying to explain in short: the reason is related to the choice we made of the kind of software we use to offer such service. Currently, we are using ejabberd that, although being an interesting piece of software, is tricky to manage and configure. There is an alternative: prosody. Recently, we have worked to a migration plan, that includes the transfer of the roster (the list of known contacts) and of the offline messages. We hope the transition will be smooth. We will post updates at the bottom of this article.
Aggiornamento 1 [2022-05-08]: la migrazione è cominciata con un giorno di ritardo; stiamo procedendo e sistemando alcuni problemi che non permettono l’autenticazione degli utenti al servizio.
Update 1 [2022-05-08]: the migration started one day later; we are fixing some issues that prevent users from authenticating.
Aggiornamento 2 [2022-05-08]: la migrazione è terminata; se incontrate problemi scrivete a help@autistici.org
Update 2 [2022-05-08]: the migration just concluded; in case of any problem, write to help@autistici.org
[IT]
Oggi abbiamo aggiornato i servizi di autenticazione di A/I. Con questo aggiornamento abbiamo modernizzato il supporto per un secondo fattore di autenticazione hardware (hardware token), che è stato purtroppo semi-rotto per lungo tempo, ed ora è invece nuovamente funzionale al 100%. Con questo aggiornamento sono state anche introdotte delle lievi modifiche all’aspetto del form di login, non vi allarmate!
Le chiavi 2FA hardware sono ormai diventate relativamente economiche, ed offrono il migliore livello di protezione contro phishing e furto di credenziali attualmente disponibile, quindi vi incoraggiamo caldamente ad utilizzarle.
Per associare un token hardware al proprio account, dal pannello si può selezionare “Gestione Account” > “Abilita 2FA” > “Registra un nuovo token hardware“.
[EN]
Today we updated A/I’s authentication services to modernize our support for hardware tokens as a second factor for authentication (2FA). The support for hardware tokens had been broken for a long while, but it’s now once again 100% functional. With this change we’ve also introduced some small changes to the layout of the login form – do not be alarmed, this is expected.
Hardware tokens have become relatively affordable, and they offer the best available level of protection against phishing and credential theft, so we strongly encourage you to use one for your account.
To register a new hardware token, from A/I’s user panel select “Account Management” > “Enable 2FA” > “Register a new hardware token“.
English version below
[IT]
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!
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.
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.
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.
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]
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!
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.
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.
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.
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.
[IT]
Aggiornamento: La manutenzione è terminata, Noblogs è di nuovo in funzione.
Nei giorni del 15 e 16 maggio 2021 ci saranno degli aggiornamenti a Noblogs che ci obbligano a sospendere temporalmente la possibilità di pubblicare nuovi articoli. Anche la lettura dei blog potrebbe non funzionare per alcune ore, ed in generale vi consigliamo di non accedere finché la manutanzione non sarà terminata.
Vi terremo aggiornat* sull’andamento dei lavori. Per favore, aspettate almeno fino al giorno 17 maggio per segnalarci dei problemi con Noblogs: non ci bombardate di segnalazioni mentre ci stiamo lavorando sopra!
[EN]
Update: Maintenance is over, Noblogs is up and running once more!
During the days of May 15th and 16th 2021 we are planning an update to Noblogs that will force us to temporarily suspend the publishing of new blog posts. Expect generalal unavalaibility of the service during these days, and please avoid accessing it until the manteinance is over.
We will keep you updated. Please, wait until May 17th before contacting us about any issue you are facing with Noblogs: we are most probably working on it, and it might get fixed soon.
[ES]
Actualización: Hemos terminado la manutención, Noblogs ya está funcionando normalmente!
En los días del 15 y 16 de Mayo 2021 vamos a efectuar una actualización de Noblogs, que nos obliga a suspender temporalmente la posibilidad de creare nuevas entradas y posts. Es también posible que para unas horas no sea posible acceder al servicio de ninguna forma (ni siquiera solamente para leer), así que os aconsejamos de no usarlo hasta que la manutención se haya terminado.
Os vamos a tener informad*s sobre el estado de la situación. Por favor, esperar al día 17 para contactarnos sobre eventuales problemas con Noblogs, ya que es probable que ya estamos trabajando en ellos!
Aggiornamenti noblogs