Archive for the ‘Avvisi’ Category

Videocall ripristinate / video conference service is running again

martedì, Settembre 27th, 2022

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:

  • è continuamente aggiornato
  • è monitorato in modo che ci avverta se si pianta
  • conferenza col maggior numero di persone del 2022: 30 persone
  • conferenze al giorno fino a 10
Se vi va di leggere la comparazione con altri servizi di videochatting ed i dettagli, qui su wikipedia:

 


Last week we noticed the videoconf system was blocked.
We apologize for it, but now all is back online on https://vc.autistici.org/.
Meanwhile we take this chance to report that:* it’s being kept update
* it’s being monitored
* max 30 people attended the same conference in 2022
* up to 10 conferences a day avgIf you fancy reading a video conference software comparison matrix follow this link in wikipedia:
Comparison_of_web_conferencing_software

Ricarica! / Refresh!

lunedì, Settembre 12th, 2022

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!?

Ed ecco per noi la Web Key Directory!

lunedì, Giugno 20th, 2022

–> 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

Migrazione del servizio di chat / Instant messaging service migration

lunedì, Maggio 2nd, 2022

[English below]

In breve

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.

Un po’ di dettaglio

È 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]

TL;DR

On 2022-05-07 we will migrate our jabber service. Because of that, the history of all chat rooms will be lost.

Some more detail

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

2FA

martedì, Dicembre 7th, 2021

[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“.

Dismissione dell’Hidden Service Tor / Deprecating our Tor Hidden Service

martedì, Giugno 29th, 2021

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.

Manutenzione Noblogs / Noblogs Maintenance

sabato, Maggio 15th, 2021

[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!

Uno per tutti, 5 per mille ad A/I!

mercoledì, Maggio 20th, 2020

[English version below]

Per chi paga le tasse in Italia, da quest’anno è possibile effettuare una donazione ad Autistici/Inventati attraverso la dichiarazione dei redditi, attraverso il meccanismo della donazione del 5 per mille.

Al momento di compilare il Modello CU Unico e 730, nel riquadro dedicato al 5 per mille, inserisci la tua firma ed il codice fiscale “93090910501” sotto alla dicitura:

"SOSTEGNO DEL VOLONTARIATO E DELLE ALTRE ORGANIZZAZIONI NON LUCRATIVE DI UTILITA’ SOCIALE, DELLE ASSOCIAZIONI DI PROMOZIONE SOCIALE E DELLE ASSOCIAZIONI E FONDAZIONI RICONOSCIUTE CHE OPERANO NEI SETTORI DI CUI ALL’ART. 10, C. 1, LETT A), DEL D.LGS. N. 460 DEL 1997"

 

[English version]

If you file taxes in Italy, you can donate to Autistici/Inventati via the so-called “5 per mille”, an option to donate 0.5% of your taxes to a non-profit organization.

To do so, on your “Modello CU Unico” and Form 730, in the section regarding “5 per mille”, you will have to sign your name ad insert the tax code (codice fiscale) “93090910501” where it says:

"SOSTEGNO DEL VOLONTARIATO E DELLE ALTRE ORGANIZZAZIONI NON LUCRATIVE DI UTILITA’ SOCIALE, DELLE ASSOCIAZIONI DI PROMOZIONE SOCIALE E DELLE ASSOCIAZIONI E FONDAZIONI RICONOSCIUTE CHE OPERANO NEI SETTORI DI CUI ALL’ART. 10, C. 1, LETT A), DEL D.LGS. N. 460 DEL 1997"

Videoconferenze per autorganizzarsi in remoto / Video calls for remote self-management

giovedì, Marzo 12th, 2020
[English version below]
Viste le circostanze abbiamo deciso di rendere disponibile, su base sperimentale e per un periodo limitato di tempo, un servizio di videoconferenza aperto a tutti, per supportare attività di gruppo a distanza.
Il servizio è disponibile su vc.autistici.org ed è stato implementato usando il software open source Jitsi.
Il servizio è fruibile liberamente da un computer con webcam o da uno smartphone (usando l’app di Jitsi), senza bisogno di effettuare alcuna registrazione o autenticazione (ovvero è possibile usarlo anche se non si è già utenti di autistici.org). La capacità è limitata, e nel caso dovesse terminare, le condizioni di accesso potrebbero cambiare oppure espanderemo la capacità, vedremo.
Ci interessa però parlarvi di alcune questioni tecniche che è importante sapere prima di usare questo strumento.
  • Autistici/Inventati non mantiene alcuna registrazione della chiamata e nessun identificativo personale dei partecipanti. Questo ovviamente non vale per le persone che partecipano alla chiamata con voi, perciò se non volete che sconosciuti partecipino alla vostra chiamata vi consigliamo di impostare una password per la stanza.
  • Il servizio è pensato per gruppi che condividono la nostra policy, in caso di abuso non ci faremo problemi ad intervenire
  • Pare ci siano incompatibilità con versioni di Firefox non sufficientemente recenti, quindi in caso riscontraste problemi vi consigliamo prima di provare con Chromium.
  • In alcuni casi Jitsi effettua connessioni peer-to-peer, che implica che il proprio indirizzo IP può essere rivelato agli altri partecipanti.
  • Ricordate che è impossibile impedire agli altri partecipanti di registrare le conversazioni, e che le videoconferenze sono suscettibili alle intercettazioni elettroniche ED ambientali contemporaneamente.
Detto questo, non ci resta che augurarvi buon uso del nostro nuovo servizio.
In caso riscontraste problemi ricordate che potete segnalarli all’indirizzo email help@autistici.org.
Buona organizzazione!

(altro…)

A/I is back!

martedì, Ottobre 29th, 2019
English and Spanish version at bottom
Español e inglés a continuación

Dopo il cambio di infrastruttura di questa estate..

Autistici/inventati è di nuovo aperta!
Da oggi potete nuovamente fare richiesta per l’apertura di:

– account mail    (email)
– account jabber  (chat)
– siti noblogs    (blog)
– mailing list    (discussioni)
– newsletter      (informativa)

Per entità, multipersonalità, collettivi, singole o mutanti purche’ come noi antifasciste!

Avete letto la nostra policy? eccola, è importante!

==> https://www.autistici.org/who/policy

Se quindi volete proseguire, dopo aver letto che cosa pensiamo, quali sono i nostri consigli su come per avere a cuore la privacy e l’anonimato delle VOSTRE compagnie,
…allora potete richiedere un servizio qui:

==> https://services.autistici.org/

 


EN

After this summer infrastructure redesign..

Autistici / inventati is back, and is open again!

Starting from today you can request us to create one of the following services:

– mail account   (email)
– jabber account (chat)
– noblogs        (blog)
– mailing list   (ML)
– newsletters    (info)
– websites       (static html)

For entities, multipersonalities, collectives, humans or mutants who believe, like us, in antifascism!

Have you read our policy? Here it is, it’s important:

==> https://www.autistici.org/who/policy

That’s all!

If you want to continue, after reading about what we think, what we are and the best practices to take care of YOUR privacy and anonymity,
..then you can go on and request a service here:

==> https://services.autistici.org/

 


ES

 

Despues del verano, la infrastructura mudò completamente su desing..

Autistici / inventati vuelve y abre nuevamente!

Empezando desde hoy es posible pedirnos la creaciòn de los seguientes servicios:

– correo electronico (email)
– jabber account     (chat)
– noblogs            (bloc)
– listas de correos  (ML)
– web                (html statico)
– newsletters        (informativa)

Para entiadd, multipersonas, collectivos, humanos o mutantes que creen fermamente en el antifacismo!

Has leido nuestra politica y manifesto? Es aqui y es importante!

==> https://www.autistici.org/who/policy

Esto es todo!
Si quieres continuar, despues que has leido que pensamos, quien somos y las practicas mejores para mantenerte segura y anonima,
… entonces puedes seguir y pedirnos un servicio aqui:

==> https://services.autistici.org/