Informazioni personali

Cerca nel blog

Translate

mercoledì 23 giugno 2010

Alex Badalic (1947 – 2010)

è  morto Alex Badalic pioniere italiano del web da fidonet (chi se la ricorda?) ai primi blog.
Un pensiero commosso ai suoi car ed ai molti amici e ammiratori che aveva in Italia.
Arrivederci Alex e grazie.

http://rcm.amazon.com/e/cm?t=portadiferro-20&o=1&p=8&l=bpl&asins=1155855345&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr

giovedì 17 giugno 2010

End of life for CSA? That’s okay!

This is an intersting aticle from network world!

http://www.networkworld.com/community/node/62568

End of life for CSA? That’s okay!

New Cisco endpoint security strategy is a better fit for the cloud and the company

By joltsik on Wed, 06/16/10 – 1:20pm.

 

Earlier this week, Cisco announced its intentions to end-of-life the Cisco Security Agent (CSA) at the end of the year. Cisco will continue to support CSA for another 3 years but it won’t enhance the product any longer.

Moving forward, Cisco’s endpoint security efforts will center upon AnyConnect, an agent-based offering that unfies endpoint connectivity, TrustSec, DLP, threat defenses, and policy management. As far as pure AV protection, Cisco will recommend partner with vendors like Sophos and Trend Micro.

What’s going on here? Is Cisco walking away from an entire product and market? No. In fact, ESG believes this decision demonstrated guts and vision. Cisco has never had any luck with Windows client software and that’s really what CSA is. Cisco may be saying adios to Windows but this move is right down Broadway as it aligns with Cisco’s strengths and market direction. Why? Because:

  1. Windows PCs are no longer the point. We all have PCs, smart phones, Macs, etc., and this list will only grow over time. I want to secure my stuff, not my Windows PC. How can you amalgamate this task? Through the network of course. This is exactly what Cisco wants to do.
  2. Think cloud. Yes, the cloud will provide us all with infrastructure, applications, and services, but it can also by a big honking proxy services. As we virtualize our workloads, this has to happen. Cisco gets this and is already offering cloud-based security services via IronPort and Scansafe. This is the future, not CSA.
  3. The definition of endpoint security has grown. When Cisco acquired Okena, endpoint security was really about malware protection. Now endpoint security extends to identity, access controls, usage policies, and data assurance. Again, most of these other functions can be managed via the network.

Cisco has a fair number of CSA customers so I’m sure some folks within the company wanted to continue to invest in the product. This would have been the easy, “let’s not rock the boat” decision.

Yes, this would have been the easy path but it also would have been the wrong decision. Cisco can now focus on endpoint security from a position of network/cloud strength rather than its Windows PC weakness.

The market is already headed in this direction. Cisco is simply shedding some legacy baggage and positioning the company at the nexus of endpoint, network, and cloud security. This is the absolute right decision.

<

p class=”wp-crosspost-linkback”>
End of life for CSA? That’s okay! was originally published on The Puchi Herald Magazine

venerdì 11 giugno 2010

Comunicato stampa della associazione italiana internet provider

02/03/2010

DECRETO TV: AIIP, ISTITUITO IL GRANDE FRATELLO DI STATO

COMUNICATO STAMPA
DECRETO TV: AIIP, ISTITUITO IL GRANDE FRATELLO DI STATO
Il Decreto legislativo approvato ieri dal Consiglio dei Ministri come recepimento della Direttiva 2007/65/CE, va ben oltre il testo comunitario ed istituisce il primo Grande Fratello di Stato
(senza che l’Europa lo abbia previsto)
[Roma] 2 marzo 2010 – L’Associazione Italiana Internet Provider (AIIP) esprime sconcerto e preoccupazione a seguito della pubblicazione su organi di stampa del testo del Decreto di recepimento della direttiva 2007/65/CE, come sarebbe stato approvato dal Consiglio dei Ministri.
Il decreto legislativo prevede infatti che l’Autorità per le Comunicazioni può imporre agli operatori di accesso e internet provider di adottare misure tecniche per proteggere i diritti delle emittenti televisive, come ad esempio il filtraggio dell’accesso alla rete, l’oscuramento di siti e il blocco di servizi.
In questo modo, si sottraggono pericolosamente tali attività al controllo della magistratura civile e penale, trasformando di fatto i provider in sceriffi della rete e violando la vita privata di tutti i cittadini, innanzi tutto di quelli che rispettano la legge.
Questo, purtroppo, è solo uno dei numerosi difetti del provvedimento che si tradurranno, a breve, in danni concreti per i diritti della persona e la libertà di impresa.
Le modifiche introdotte non rispecchiano, se non in parte, le indicazioni delle Commissioni Parlamentari e il risultato è che il testo è ancora in molti punti diverso dalla originaria Direttiva Servizi Media Audiovisivi che vorrebbe attuare.
Benchè i siti privati, i siti non commerciali, i blog e i quotidiani online non debbano più formalmente sottostare alle norme del Decreto, AIIP ha la sensazione che vi sia stato un “giro di vite” sulla possibilità di offrire legittimamente accesso ad Internet e servizi del web 2.0 in Italia.
Il Decreto sembra istituire un regime di controllo per cui sia l’Internet Provider che il Service Provider sono potenziali responsabili editoriali, persino per le violazioni del diritto d’autore compiute da terzi tramite audiovisivi.
Manca completamente ogni riferimento ai basilari principi della Direttiva Commercio Elettronico, che, nel testo comunitario dei Servizi Media, sono richiamati molte volte. Sono i principi alla base del funzionamento di Internet. Prevedono che chi fornisce l’accesso e si limita a trasportare i “pacchetti dati” non è responsabile del contenuto. La loro mancata menzione, unita ad un’ambigua stesura delle norme, comporta che non è certo che il fornitore del solo trasporto sarà esente da responsabilità per il servizio media trasportato e, inoltre, non è certo che il contenuto di terzi non sarà responsabilità della piattaforma ospitante. La conseguenza prevedibile sarà che ogni impresa dovrà istituire controlli e censure e, comunque, ridurre le possibilità di violare le norme alla base. Si tratta di gravissime violazioni della disciplina comunitaria.
Inoltre, riferimenti alla disciplina del diritto d’autore sul web introdotti dal Decreto non sono previsti a livello comunitario in nessuna direttiva ed aggravano questa sensazione di “giro di vite” sulla libertà di fare impresa sul web.
Se questo sarà il regime giuridico dell’accesso ad Internet e del “web 2.0 italiano” in Italia, non solo si ridurrà di molto il mercato dei servizi web 2.0 basati su audiovisivo a tutto beneficio degli Stati che avranno dato corretta attuazione alla Direttiva, ma si pongono i presupposti per vanificare il diritto costituzionale di utilizzare internet per manifestare liberamente il proprio pensiero.
Informazioni su AIIP:
AIIP – Associazione Italiana Internet Provider – è l’associazione di categoria di area Confindustria che rappresenta le aziende italiane eroganti servizi basati anche parzialmente su protocollo IP. L’associazione raccoglie oltre 50 aziende fornitrici di connettività internet fissa e wireless, servizi di voip, vas e servizi su telefonia mobile, servizi di hosting ed IP Television. L’associazione svolge le proprie attività presidiando ogni sede regolamentare con azioni ed interventi atti a garantire la piena concorrenza sul mercato, a tutela di quelle aziende italiane che hanno sempre guidato l’innovazione nel settore delle TLC, e per promuovere lo sviluppo di infrastrutture e servizi che favoriscano lo sviluppo economico del paese. AIIP è interlocutore riconosciuto ed accreditato presso le associazioni di consumatori, Ministero delle Comunicazioni, AGCom e – attraverso ECTA (European Competitive Telecommunications Association) – presso la Commissione UE. L’Associazione, il cui Presidente in carica è Paolo Nuti, è stata fondata nel 1995.


Sede Legale: Via Caldera, 21 – 20153 Milano – Italy – CF 97166260154 – segre@aiip.it Fax 02- 700517563 – Tel 329-3172755
Posta: c.a. Dario Denni Segretario Generale AIIP – c/o Studio Legale Valli – Via del Governo Vecchio 20 – 00186 Roma
2

Allegati

Comunicato stama Decreto Romani

mercoledì 9 giugno 2010

Why limiting SMTP concurrent connections

Cosa succede se non limito le connessioni SMTP in ingresso?

dobbiamo distinguere 2 diversi casi:

  • ricevo un numero di richieste minore della mia capacità di assorbimento
  • ricevo un numero di richieste superiore alla mia capacità di assorbimento.

nel primo caso le implicazioni sono ovviamente minori e quindi, analizzeremo cosa succede nel secondo.

la prima domanda da porsi è: perché saturo le mie connessioni SMTP disponibili in ingresso?

la risposta è evidentemente legata al fatto che che vengono generate moltissime connessioni da molteplici fonti esterne.

una delle prime cose che occorre capire del protocollo SMTP e le implementazioni che ne danno i vari servizi postali è che tutti cercano di scodare le proprie mail nella maniera più efficace ed efficiente possibile.

questo viene di solito ottenuto con due meccanismi:

  1. cercare di aprire il maggior numero di sessioni SMTP concorrenti possibile
  2. cercare di mettere sul canale SMTP aperto il maggior numero di messaggi possibile.

In altre parole quando un mailserver A cerca di spedire posta a mailserver B viene effettuata una transazione tra  i due servers in cui A cerca di allocarsi il maggior numero di risorse possibili su B ed è compito di B porre dei limiti a A.

Il server A cerca di aprire una connessione con il server B attraverso una connessione TCP tramite il classico Handshake a 3 vie e dichiara di voler comunicare tramite il protocollo SMTP.

B risponde generalmente accettando le connessioni TCP e preparandosi a ricevere le connessioni SMTP in ingresso. Il comportamento dal lato SMTP di B non è in realtà dettato da una contrattazione a livello di protocollo SMTP ma alla configurazione della MTA di B.

A in realtà cerca di aprire il maggior numero di connessioni SMTP possibili, su ogni connessione cerca di inviare il massimo numero di messaggi che è possibile inviare. Ancora una volta questo comportamento è dettato dalla configurazione della MTA di A.

Se A supera la capacità ricettiva di B, B smette di accettare ulteriori connessioni.

Il limite raggiunto da B può essere fisico, non avendo più disponibilità di gestire connessioni, o amministrativo.

Questo scenario si ripete anche per tutti gli altri eventuali server presenti su internet che cercano di mandare posta a B.

Vanno considerati in questo scenario 2 aspetti fondamentali:

  • il server B non ha capacità illimitata di ricezione
  • ogni sessione SMTP dura il tempo necessario a mandare il numero di messaggi previsti dal sender, Questo tempo varia a seconda della quantita’ di dati e può essere di breve durata ma anche di diverse decine di secondi.

Questi due fattori concorrono a ridurre la disponibilità di B a ricevere connessioni da sorgenti multiple, quando infatti viene raggiunto il limite di connessioni disponibili viene rifiutata la connessione agli altri emettitori.

Questo comporta a sua volta che gli emettitori che si vedono rifiutato l’accesso al canale SMTP iniziano ad eseguire retry per cercare di ottenere accesso al canale.

Dal momento che il comportamento degli emettitori in termini di numero di connessioni e messaggi inviati per connessione è imprevedibile, occorre cercare di gestire le politiche di accesso al server B in maniera oculata.

Lo scopo delle policy da implementare deve essere quello di consentire al maggior numero di mittenti la possibilità di connettersi, per raggiungere questo scopo occorre innanzi tutto essere sicuri che nessuno dei mittenti possa impadronirsi di tutte le connessioni concorrenti gestibili dal server di posta.

in altre parola ha senso, dal punto amministrativo imporre un limite per connessione che sia

Numero connessioni x Host << numero connessioni effettive disponibili.

In questo modo si evita che una sorgente saturi la destinazione a scapito di altri emettitori.

Va posta anche attenzione al numero di messaggi ammissibili sul canale SMTP.

qui le considerazioni sono più delicate a causa del comportamento estremamente variabile delle MTA su internet.

Alcune implementazioni cercano di mandare sul canale SMTP aperto il maggior numero di messaggi possibile, altre preferiscono puntare sul numero di connessioni concorrenti mandando un solo messaggio per connessione.

La chiave qui ancora una volta e ricordarsi che il canale SMTP viene utilizzato per tutta la durata della trasmissione dei messaggi, il che significa che limitare il numero di messaggi inviati porta alla chiusura anticipata del canale SMTP e quindi alla sua disponibilità ad una altro emettitore.

E’ buona norma quindi cercare di limitare il numero di connessioni per Host in ingresso per rendere e risorse disponibili per gli altri emettitori. Un errore che si compie nel disegno di soluzioni SMTP è spesso quello di considerare che chi ha maggior posta da inviare ha bisogno di una maggiore priorità. Paradossalmente è vero proprio il contrario, chi manda poca posta dovrebbe avere una maggiore priorità di chi ne manda molta, in termini di disservizio il rallentamento è più sensibile rispetto chi manda 4 messaggi che chi ne manda 4000. Del resto questo è lo stesso approccio che si usa nella distribuzione dei task elaborativi nei calcolatori condivisi, dove generalmente i grossi processi elaborativi hanno priorità più bassa rispetto a quelli brevi.

Quali sono i limiti da imporre per host è ovviamente oggetto di discussione, ogni amministratore di rete può fare le proprie considerazioni in merito tenendo però presente almeno due fattori:

  • la effettiva capacità ricettiva della propria piattaforma
  • il livello di esposizione ai flussi SMTP

Volendo dare indicazioni di massima si può partire, per effettuare delle valutazioni, dalla saturazione delle connessioni in ingresso per poi decidere come agire.

Cosi se la piattaforma accetta, ad esempio, 200 connessioni concorrenti  per la saturazione è sensato imporre limiti del tipo 20 connessioni concorrenti per Host. (1 decimo).

Lo scopo, ancora una volta, è garantire un flusso distribuito di una risorsa che non è illimitata.

Se guardiamo quello che fanno i grandi provider di posta come Google, Yahoo o MSNLive vediamo che loro adottano sui loro sistemi questo tipo di strategia in maniera abbastanza severa:

Yahoo.com – 8 concurrent connections, 15 recipients

Hotmail.com – 10 concurrent connections, 25 recipients

Gmail.com – 20 concurrent connections, 100 recipients

Queste limitazioni sono indiscriminate (x host base) e quindi non legate ad uno specifico emettitore e rappresentano il massimo numero di connessioni e messaggi per connessione che un mail server può fare per mandare posta a questi provider.

Si noti come queste limitazioni non implicano poi nella esperienza normale una riduzione della capacità ricettiva di questi providers, ma, al contrario, una migliore distribuzione di questa capacità e quindi, in ultima analisi, un miglior servizio.

NOTA A:

Questo discorso inerente alle limitazioni in ingresso va accoppiato con un generale discorso della gestione della banda e delle connessioni ottenibile, ad esempio, da servizi di reputation.  Il primo non esclude l’altro, ma entrambi concorrono ad un corretto flusso di gestione della messaggistica.

 

NOTA B:

Effettuare un reject di una connessione comporta comportamenti diversi a seconda che si effettui la operazione a livello SMTP o TCP. In entrambi i casi vi sono Pro e Contro ed occorre valutare cosa sia meglio ottenere.

Fare un Reject a livello TCP comporta sicuramente il retry della connessione dello stack TCP, questo avviene generalmente indipendentemente dalla natura della connessione TCP. questo blocco è pero solitamente mal digerito dai Mailservers e i loro amministratori che vedono sommarsi agli errori SMTP sempre presenti anche una serie di errori lato network.

Va pero osservato che il blocco a Livello TCP avviene in maniera molto rapida e non impegna tutto lo stack del protocollo, il risultato è che questa operazione risulta molto leggera ed efficace soprattutto in ambienti dove la decisione venga presa appoggiandosi come discriminante a valori di IP reputation.

In un ambienti in cui si usi ESA quindi può avere senso effettuare il taglio a livello TCP per valori di reputation molto bassi in modo da liberare risorse SMTPin maniera piu veloce.

Il Reject a livello SMTP invece è più impegnativo in termini di risorse ma riduce sensibilmente il numero di retry nel caso il taglio sia effettuato nei confronti di macchine compromesse. I demoni che inviano spam infatti difficilmente fanno retry in queste condizioni. Ha senso quindi effettuare tale reject a questo livello per valori di reputation su cui si applica del throttling (o limitazione di banda) alla connessione.

Sulla piattaforma ESA è possibili anche impostare il Delayed Reject che avviene a Sessione SMTP completamente attivata ed interviene dopo che è stato mandato il “mail from” da parte del mittente.

Questo riduce ulteriormente , statisticamente parlando, il numero di retry da parte delle piattaforme emittenti ma ha come contropartita un maggior impegno della piattaforma di ricezione. Va detto però che in questa maniera si possono ottenere statistiche più puntuali sul numero di mail rigettate perché non legate alla assunzione del moltiplicatore per le connessioni SMTP rigettate (la assunzione solitamente è 3 mail per connessione SMTP rigettata).

Nel complesso una politica sugli ESA che mescoli connessioni rifiutate a livello SMTP col delayed reject e rifiutate a livello TCP risulta piu performante di una basata sul semplice reject SMTP.

 

 

 

 

 

martedì 8 giugno 2010

E-mail providers: unlimited o limiti di invio

Domanda
Ma un buon sistema di posta deve consentire l’invio illimitato di messaggi da parte di un utente verso il mondo sterno o ci possonodevono essere limitazioni in merito?
Risposta:
In un mondo ideale non ci dovrebbero essere limitazioni di sorta, si assume qui la buona fede del mittente che manda messaggi legittimi a legittimi destinatari.
Purtroppo molte volte questa situazione non è vera,  ed un utente potrebbe a sua insaputa essere vittima e tramite di invio di mail massive (UBE) anche potenzialmente pericolose.
Questo può avvenire in diversi modi ma è tanto più facile quanto il client di posta si trova esposto a rischi di hacking. in particolare soffrono di questo problema le webmail in cui i client è perennemente esposto.
Se poi passiamo da un ambiente aziendale eo limitato a quello di un provider la superficie di esposizione aumenta vertiginosamente.
Il risultato è che negli ultimi anni si è visto un proliferare di meccanismi volti a verificare che l’utente di una webmail sia effettivamente umano.
Questi meccanismi consistono fondamentalmente in processi di autenticazionericonoscimento dell’utente basati sulla tecnologia captcha  e su pesanti limitazioni in termini di numero di messaggi e di recipient ammessi in una certa finestra temporale.
Sono sempre meno i provider di servizi di posta elettronica che non ricorrono a queste semplici operazioni per ridurre il numero di fake users o bot, per non parlare di utenze compromesse, che producono milioni di messaggi di spam ogni giorno.
Queste limitazioni sono di solito disponibili nelle pagine dei diversi fornitori di servizi con una spiegazione del perché vengono adottate certe misure, se, ad esempio visitiamo le faq di google troviamo come indicazione generica un totale di massimo 500 destinatari via webmail o 100 via client smtp ed unimprecisato numero di errori di invio giustificando queste limitazioni con la necessità di ridurre l’invio di Spam.
Questo approccio rientra in un più contesto più generico  che vede cambiare le abitudini dei provider di servizi di messaggistica al fine di dare una maggiore sensibilità e conoscenza dei problemi legati al flooding di email presso gli utenti e proteggersi a loro volta da diventare centro di smistamento di spazzatura.
A queste limitazioni in outbound i provider aggiungono anche limitazioni alla ricezione di posta, tipicamente riducendo il numero di connesioni concorrenti accettate da un singolo IP ed il numero di mail per sessione smtp. per questo tipo di limitazioni si può fare riferimento ad un mio precedente articolo del giugno 2009 dove davo indicazion in merito (l’articolo lo trovate qui).
Applicare ai flussi di posta tali limitazioni ha consentito ai big della posta (yahoo, google, live, yandex …) di ridurre sensibilmente la loro esposizione al rischio di invio di messaggistica non desiderata, anche se non ad eliminarlo del tutto, e ha avuto solo un impatto marginale nei confronti della affezione degli utenti che sembrano aver apprezzato lo sforzo rivolto a rendere il servizio migliore.
I provider in realtà hanno avuto in questa maniera una contropartita interessante anche dal punto di vista economico, vivendo anche sulla pubblicità che paga in funzione delle loro sottoscrizioni aver ripulito i loro database di utenti li ha resi più appetibili e “valuable” nei confronti della vendita dei loro spazi pubblicitari. infatti a nessuno interesserebbe essere esposto su una pagina di una webmail usata da un roboot che manda spam, e sapere che vi sono ottime possibilità che la controparte sia umana rende la vendita dello slot pubblicitario molto più appetibile.
Una volta tanto la messa in sicurezza e la apposizione di limiti ad un servizio si rivela un generatore di revenue e non un costo 🙂
Se i grandi oramai si sono allineati in questo senso perché non tutti fanno cosi? e perché c’è ancora tanto spam?
lo spam oggi come oggi viene generato prevalentemente da botnet i cui partecipanti sono, per la maggior parte, home computer o laptop di ignari utenti. anche il traffico spam proveniente dagli isp è solitamente legato non ai sistemi di posta offerti ma dalle leased line ed i relativi IP.
ciononostante una maggiore attenzione anche da parte delle aziende nelle configurazioni dei limiti di ingresso ed uscita della posta potrebbe portare a benefici per tutto il sistema.
A

http://rcm.amazon.com/e/cm?t=portadiferro-20&o=1&p=8&l=bpl&asins=B0043D2EL8&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr

mercoledì 2 giugno 2010

Proposta: estendiamo le ferie scolastiche fino al 31 dicembre

Evvaiiii

anzi perché non aboliamo del tutto la frequenza scolastica?

Ogni tanto (?) dalla politica italiana escono delle proposte che mi lasciano alcune perplessità, la ultima che mi sovviene è legata alla proposta di estendere le ferie scolastiche alla fine di settembre.

quello che mi ha sconcertato di più sono le motivazioni allegate, in particolare il riferimento al fatto che siamo terra di turismo (ma anche di santi poeti e navigatori).

Mi sorge quindi un dubbio, o meglio una necessità di chiarimento:

l’estensione delle ferie si applica anche ai genitori?

Perché se il motivo è il turismo, e nella fattispecie il turismo interno (non si capisce perché ad un tedesco dovrebbe interessare se un bambino italiano va a scuola a settembre o meno), alla equazione più ferie uguale più vacanze, manca un piccolo pezzettino: i figli in ferie ci vanno da soli o con i genitori?

Se, infatti i figli possono stare a casa fino alla fine di settembre non è cosi per i genitori che, solitamente, sono legati a obblighi lavorativi.

Giustificare la scelta col turismo mi sembra quindi una boutade abbastanza ridicola.

Certo vanno considerate anche le famiglie monoreddito e quelle in cui entrambi i genitori non lavorano, ma francamente anche queste non mi sembrano target opportuno per i discorso di estensione della possibilità di gestione delle ferie.

Lo so che mi ripeto ma trovo sconfortante la assoluta mancanza di un progetto formativo che sta guidando le ultime scelte in tema scolastico del belpaese.

La scuola non è una azienda il cui scopo finale è il profitto, la scuola è una organizzazione il cui scopo è quello di formare, il meglio possibile, i cittadini perché possano contribuire nel miglior modo possibile allo sviluppo delle società in cui vivono.

Ma tutto questo non è possibile senza avere almeno un progetto formativo su cui costruire gli anni di formazione.

Non importa che si sia crociani, montessoriani, adleriani quello che importa che dietro ci sia un progetto formativo che, significa, definire obiettivi, modi, metodi etc etc.

Siamo ben lungi da considerare (passatemi il termine aziendale) la formazione un asset del nostro paese, la siamo gestendo sempre più come un mero centro di costo.

Pagheremo tutto questo nel futuro, ma si sa avendo oramai una visione progettuale che non supera la legislatura, al politico di turno nulla interessa di che Italia erediteranno i nostri figli.

Sigh

Tanti saluti allo stato di diritto

Secondo la legislazione internazionale, se ricordo bene, qualsiasi nave, in acque internazionali, è da considerarsi a tutti gli effetti parte del territorio cui la nave batte bandiera.

Qualsiasi abbordaggio non autorizzato nei confronti di tale battello, sempre secondo la legislazione corrente, è da considerarsi un atto di pirateria.

Diventa quindi difficile poter giustificare, da un punto di vista strettamente legale, la operazione della marina militare israeliana nei confronti del convoglio pacifista diretto verso Gaza. e sono assolutamente comprensibili le reazioni di quelle nazioni, come la Turchia, che a seguito di questo atto di pirateria si sono viste violare il territorio nazionale con un atto illegale che ha, per altro, portato a delle perdite di vite umane.

Poco vale la giustificazione che la reazione dei militari israeliani sia stata legata alla reazione di difesa dei passeggeri eo equipaggio delle navi abbordate. In alcuni paesi sia dal punto di vista culturale che legale, una violazione palese della sovranità territoriale comporta l’obbligo morale di opporre resistenza.

In altre parole a seguito di un attacco del genere perdite di vite umane erano da mettere in conto, una operazione cosi non poteva non essere stata pianificata sapendo che ci sarebbero state vittime tra gli assaltati. Del resto se cosi non fosse non si sarebbe dovuto effettuare un assalto armato.

Ora il problema in questo caso non è tanto le ragioni che hanno spinto Israele a comportarsi in tale modo, ma il palese ed evidente disprezzo dello stato di diritto che pone una questione fondamentale: se un stato sovrano, a seguito di sue motivazioni anche largamente condivisibili, pensa di essere superiore o indipendente dallo stato di diritto internazionale pone, nei fatti, un precedente che potrebbe autorizzare chiunque ad agire in tale modo.

Se a questo punto la Turchia, ad esempio, decidesse di forzare il blocco israeliano verso Gaza con le armi come dovrebbe schierarsi l’Europa ed il resto del mondo?

Accompagnare con navi da guerra Turche una nave civile battente bandiera turca significherebbe difendere, in acque internazionali, la sovranità territoriale di tali navi. un assalto sempre in acque internazionali che portasse ad uno scontro verrebbe letto, secondo la normativa internazionale, come un atto di guerra nei confronti di un paese e quindi comporterebbe la automatica chiamata alle armi di altre nazioni in una escalation poco piacevole.

Pur comprendendo le ragioni di Israele, talvolta sarebbe opportuno per il bene di tutto il pianeta che si usasse un poco più di prudenza nella gestione di vicende di questo tipo.

Mi auguro che la Turchia, la Grecia e le altre nazioni coinvolte che sponsorizzavano, in qualche maniera, questa azione applichino un maggior buon senso alle loro scelte di quello che ha fatto Israele.

A

Tanti saluti allo stato di diritto was originally published on The Puchi Herald Magazine

Tanti saluti allo stato di diritto

Secondo la legislazione internazionale, se ricordo bene, qualsiasi nave, in acque internazionali, è da considerarsi a tutti gli effetti parte del territorio cui la nave batte bandiera.

Qualsiasi abbordaggio non autorizzato nei confronti di tale battello, sempre secondo la legislazione corrente, è da considerarsi un atto di pirateria.

Diventa quindi difficile poter giustificare, da un punto di vista strettamente legale, la operazione della marina militare israeliana nei confronti del convoglio pacifista diretto verso Gaza. e sono assolutamente comprensibili le reazioni di quelle nazioni, come la Turchia, che a seguito di questo atto di pirateria si sono viste violare il territorio nazionale con un atto illegale che ha, per altro, portato a delle perdite di vite umane.

Poco vale la giustificazione che la reazione dei militari israeliani sia stata legata alla reazione di difesa dei passeggeri eo equipaggio delle navi abbordate. In alcuni paesi sia dal punto di vista culturale che legale, una violazione palese della sovranità territoriale comporta l’obbligo morale di opporre resistenza.

In altre parole a seguito di un attacco del genere perdite di vite umane erano da mettere in conto, una operazione cosi non poteva non essere stata pianificata sapendo che ci sarebbero state vittime tra gli assaltati. Del resto se cosi non fosse non si sarebbe dovuto effettuare un assalto armato.

Ora il problema in questo caso non è tanto le ragioni che hanno spinto Israele a comportarsi in tale modo, ma il palese ed evidente disprezzo dello stato di diritto che pone una questione fondamentale: se un stato sovrano, a seguito di sue motivazioni anche largamente condivisibili, pensa di essere superiore o indipendente dallo stato di diritto internazionale pone, nei fatti, un precedente che potrebbe autorizzare chiunque ad agire in tale modo.

Se a questo punto la Turchia, ad esempio, decidesse di forzare il blocco israeliano verso Gaza con le armi come dovrebbe schierarsi l’Europa ed il resto del mondo?

Accompagnare con navi da guerra Turche una nave civile battente bandiera turca significherebbe difendere, in acque internazionali, la sovranità territoriale di tali navi. un assalto sempre in acque internazionali che portasse ad uno scontro verrebbe letto, secondo la normativa internazionale, come un atto di guerra nei confronti di un paese e quindi comporterebbe la automatica chiamata alle armi di altre nazioni in una escalation poco piacevole.

Pur comprendendo le ragioni di Israele, talvolta sarebbe opportuno per il bene di tutto il pianeta che si usasse un poco più di prudenza nella gestione di vicende di questo tipo.

Mi auguro che la Turchia, la Grecia e le altre nazioni coinvolte che sponsorizzavano, in qualche maniera, questa azione applichino un maggior buon senso alle loro scelte di quello che ha fatto Israele.

A

martedì 1 giugno 2010

Going Beta: lab closed

Siccome la fortuna è cieca ma la sfiga ci vede benissimo ho appena subito la dipartita di un po’ di roba elettronica (un desktop, un laptop, 2 stampanti, 1 UPS…) per un problema alla rete elettrica. quindi il mio lab è temporaneamente fuori uso.
Appena si riaprono i battenti ve lo faccio sapere
ciaps
A