Per legge il deposito telematico nell’ambito del Processo Civile Telematico si considera effettuato nel momento in cui viene generata la PEC di avvenuta consegna presso il sistema informatico ministeriale (Art. 16-bis c. 7, D.L 18 ottobre 2012, n. 179).

Ipotizziamo ora questo scenario:

1. Viene effettuato entro il termine rituale un deposito telematico di atto di costituzione, memoria o altro atto soggetto a decadenza,

2. Il deposito viene respinto per un problema tecnico del sistema informatico ministeriale, oppure il cancelliere lo rifiuta per qualsiasi motivo,

3. Ritenendo tempestivo e regolare il deposito ed ingiustificato il rifiuto, l’Avvocato ricorre al giudice, chiedendo l’accettazione retrodatata del deposito.

Nel presentare l’istanza si allegherà (tra l’altro) la ricevuta di avvenuta consegna del deposito telematico (la seconda PEC), che attesta la data di invio del deposito e contiene quanto inviato.

Ed è qui che subentra una difficoltà: l’allegato a questa PEC, contenente l’atto ed i documenti inviati per il deposito, è un file “cifrato”, denominato solitamente “Atto.enc”, che può essere aperto solamente dal sistema informatico ministeriale, che è il solo depositario dei certificati crittografici necessari. Non ne è possibile l'apertura diretta del file né da parte dalla cancelleria né dal giudice.

4. Per quanto sopra descritto, la procedura deve essere che, se il Giudice ritiene di ammettere l’istanza di parte, deve disporre per l’Avvocato il reinvio del deposito e per il cancelliere l’accettazione di questo con data forzata a quella del deposito iniziale (entro il termine).

Per attestare che il ri-deposito autorizzato è conforme al primo invio si deve di riutilizzare esattamente lo stesso file Atto.enc, attestando l’equivalenza dell’impronta informatica o hash, per l’allegato alle due ricevute PEC, eventualmente con una relazione tecnica.

In questo modo anche non potendo verificare il contenuto del file è comunque matematicamente certa l'equivalenza del contenuto.

Rimango a disposizione per l’analisi di scenari come quello appena descritto o casistiche analoghe nell’ambito del Processo telematico.

In questo articolo intendo dimostrare che il documento informatico è intrinsecamente meno affidabile di quello cartaceo poiché sono presenti più passaggi interpretativi tra il mezzo fisico di supporto del significante ed il significato.

In un tradizionale documento cartaceo l’informazione che si riceve è una interpretazione dei segni stampati attraverso convenzioni culturali (alfabeto, lingua).

Passiamo ora ad esaminare un tipico documento informatico di testo, sotto forma di file DOC, che appare come segue nel programma di videoscrittura:

Se si apre lo stesso file con un programma in grado di mostrarne il contenuto letterale (un Text Editor, ad esempio il blocco note) apparirà questo:

È comunemente noto che le informazioni digitali sono memorizzate sotto forma di Byte (a loro volta composto da Bit, la “sequenza di valori binari” di cui al c. i-quinques art.1 del C.A.D.).

Se apriamo il file con un programma in grado di mostrare i Byte (un editor esadecimale, in gergo) avremo:

Questi codici numerici, i Byte, sono poi tradotti in modulazioni elettriche o magnetiche che costituiscono fisicamente la memorizzazione su dischi o chiavette.

L’informazione che l’utente ottiene deriva, come nel caso cartaceo, da una interpretazione dei segni visualizzati attraverso convenzioni culturali ma, in aggiunta, anche attraverso l’elaborazione effettuata dal computer di codici numerici secondo convenzioni tecniche.

È inopinabile che si aggiungono passaggi rispetto a quelli già propri del cartaceo, quindi ulteriori potenziali fonti di traduzione e di errore.

L’eccezione più ovvia è quella secondo cui gli algoritmi di elaborazione sono rigorosi, standardizzati, e quindi daranno infallibilmente sempre lo stesso risultato esatto.

Posso replicare con una serie di esempi di mia esperienza diretta in cui intervengono malfunzionamenti software oppure malintesi nell’utilizzo dei programmi che portano a male interpretare un dato.

Esempi tratti da casi reali

Caso 1: estensione di file errata o mancante

In ambiente operativo MS Windows il tipo file, ovvero la natura del contenuto, è convenzionalmente segnalato dalla “estensione”, la sequenza di tre lettere precedute da un punto al termine del nome del file. Ad esempio un file di videoscrittura può avere il formato “.doc”, una fotografia “.jpg” ecc.

Se l’estensione viene cancellata o cambiata impropriamente, ad esempio a causa di un errore nel salvare o rinominare il file, il destinatario potrebbe non riuscire ad aprirlo.

Il file potrebbe non aprirsi e mostrare un errore, oppure potrebbe aprirsi attraverso il programma sbagliato e mostrare una sequenza di caratteri incomprensibili. Su computer Apple o Linux potrebbe aprirsi ugualmente perché questi sistemi riescono a riconoscere un file direttamente dal contenuto oltre che dall’estensione.

Caso 2: File P7M

Una versione ormai obsoleta di un software di firma digitale ha manifestato in certi casi un difetto nel visualizzare il contenuto di file firmati P7M, quindi firmati digitalmente con modalità CADES (si veda il mio articolo sulle firme digitali).

Il problema si manifesta quando vengono aperti in momenti successivi diversi file P7M con nome identico. Un caso frequente è “relata.pdf.p7m”. In questo scenario viene visualizzata correttamente la prima relazione di notifica, mentre aprendo le seguenti, viene visualizzato erroneamente ancora il primo documento. Ciò può comprensibilmente creare panico presso gli studi Legali che temono di avere inviato notifiche PEC clamorosamente (ed inspiegabilmente) errate. In questo caso si tratta di un errore di sola visualizzazione, il contenuto è di fatto corretto.

Caso 3: PDF con firma PADES

Quando ad un documento viene apposta una firma secondo lo standard PADES, non viene modificata la sua estensione PDF. L’unico modo per verificare l’effettiva presenza della firma digitale è quello di aprire il file con un software idoneo: un software di firma digitale oppure il famoso visualizzatore Adobe Reader. La presenza di una firma digitale valida è testimoniata da una barra visualizzata al di sopra del documento:

I problemi sorgono quando un utente visualizza lo stesso file con un visualizzatore generico che non è in grado di rilevare la firma PADES. La situazione si verifica ad esempio in ambiente Apple MAC poiché il sistema operativo OsX apre i file PDF attraverso il visualizzatore integrato “Anteprima” che non mostra alcuna evidenza della firma. L’utente potrebbe erroneamente ritenere che il file sia privo di firma digitale ed eccepire la regolarità di una notifica, di un deposito ecc.

È utile quindi per il mittente rimarcare la presenza di firma digitale inserendo un segno grafico o una dizione che segnali la presenza della firma (in genere il segno grafico viene automaticamente apposto dai software di firma digitale).

Dal punto di vista del destinatario, se si ritiene che il file sia privo di firma dovuta, consiglio di aprirlo con Adobe Reader nella versione X o Dc, oppure Dike od ArubaSign.

Caso 4: Nomi di file contenenti caratteri di punteggiatura e lettera accentate

È noto che non è possibile utilizzare particolari caratteri nel nome dei file, quali ad esempio le barre (\, /), l’asterisco, i due punti ed il punto di domanda.

I caratteri proibiti variano a seconda del sistema informatico utilizzato. Ad esempio MS Windows non ammette \ / : * ? “ <> |. Provare per credere!

I sistemi Apple OsX e GNU/Linux sono più tolleranti, ed è possibile che un file formato su uno di questi sistemi non risulti apribile in MS Windows.

Alcuni caratteri creano problemi se usati nell’oggetto delle email.

In almeno due occasioni ho riscontrato problemi di apertura di atti digitali depositati nel processo telematico oppure notificati via PEC attribuibili alla presenza nel nome del file, di caratteri accentati (à, è, ò, ù, ì) oppure segni quali ° e &. Questi caratteri di per sé possono essere utilizzati nella denominazione ed il file si apre regolarmente sullo stesso computer su cui sono formati, ma si possono manifestare difetti di compatibilità con i sistemi informatici su cui andranno a trovarsi in seguito. Le implicazioni di carattere giuridico sono pesanti e di difficile attribuzione.

Conclusioni

Pur lavorando nel campo informatico, intendo evidenziare i rischi comunque connaturati all’informatizzazione e mettere in guardia gli utenti dai rischi potenziali. Invito a non porre eccessiva fiducia nei mezzi tecnici, che devono essere al servizio dell’Uomo e non viceversa.

Non dare mai per scontato ciò che appare a video e, nei casi dubbi, è importante verificare attentamente e criticamente, rivolgendosi eventualmente ad un consulente specializzato.

Per concludere consiglio di optare per l’utilizzo di “formati aperti” per la memorizzazione dei file, formati cioè basati su protocolli pubblici e condivisi (esempio il PDF, come notoriamente richiesto nel PCT), e “software liberi” per la gestione degli stessi.