April 2015 - nexa - server-nexa.polito.it

Re: [nexa] "Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)

by Alessio Melandri

Grazie Simone per aver affrontato questo tema. Mi lasciano perplesso alcune argomentazioni di @jhourcle. In particolare "Non-sensitive web traffic does exist." Se scarico un dataset, chessò il dump di Wikipedia, secondo la sua ipotesi, è traffico non sensibile. Tuttavia IMHO lo diventa sul lungo periodo, quando tracciando le abitudini e le configurazioni del browser mi pare si riesca perfino, con una buona percentuale, a identificare un utente che gira su TOR. Qui la questione è intedersi su cosa sia sensibile e non mi scandalizzerei se la risposta fosse *tutto*. Mi è piaciuto invece il voler rimarcare la catena di effetti causata dall'aumento dell'elaborazione dovuto all'HTTPS. Acutizza il digital divide (IMHO solo dove già presente; con un livello decente di banda l'effetto sull'utente finale è poco percettibile) ma anche e oserei dire soprattutto, è una scelta con un forte impatto ecologico. Questo ci mostra che certi software strategici hanno un grande impatto sui consumi mondiali. Come se dall'oggi al domani, con un numero relativamente piccolo di modifiche, si facessero inquinare le automobili attualmente in circolazione di un offset in più. Condivido i rischi legati alla sicurezza ma li vedo anche come una buona opportunità. Specie nel software libero, c'è una correlazione tra quanto si "stressa" una libreria e la sua qualità. Alessio Melandri 2015-04-24 19:27 GMT+02:00 Simone Basso <bassosimone(a)gmail.com>: > Cari tutti, > > tl;dr ho sempre pensato che il traffico HTTP dovrebbe sempre essere > cifrato. Alcune discussioni e articoli letti recentemente mi hanno > fatto capire che il problema e' piu' complesso e articolato, e voglio > convidere con voi quello che ho letto e alcune mie riflessioni. > > Qualche giorno fa ho letto sulla lista NNSquad una email (in calce a > questo messaggio) che penso possa essere utile per trollare^W^W^W > parlare un po' dei costi della crittografia su questa lista. > > La parte piu' interessante di questa email era in realta' una > discussione probabilmente destinata ad andare ancora avanti: > > "Please consider the impacts of banning HTTP": > > https://github.com/WhiteHouse/https/issues/107 > > La discussione viene aperta da Joe Hourclé (@jhourcle), "webserver e > database admin" presso il Solar Data Analysis Center della NASA. > > La discussione ruota attorno alla policy del governo americano che > mira a fare usare HTTPS a tutti i siti del governo: > > > The American people expect government websites to be secure and their > > interactions with those websites to be private. Hypertext Transfer > > Protocol Secure (HTTPS) offers the strongest privacy protection > > available for public web connections with today’s internet technology. > > The use of HTTPS reduces the risk of interception or modification of > > user interactions with government online services. > > > > This proposed initiative, “The HTTPS-Only Standard,” would require the > > use of HTTPS on all publicly accessible Federal websites and web > services. > > > > https://https.cio.gov/ > > Il nucleo dell'argomentazione di @jhourcle e' che HTTPS ha senso per > proteggere informazioni personali; dove non sono coinvolte informazioni > personali, si puo' decidere caso per caso se usare HTTPS oppure se sia > meglio continuare ad usare HTTP. Ossia che la policy "migriamo tutto > ad HTTP adesso" sia eccessivamente strict. > > In particolare @jhourcle sostiene che i dati scientifici sono dati non > sensibili che possono passare in chiaro (magari firmati), che ci sono > dei costi infrastrutturali nel servire grosse quantita' di dati usando > HTTPS, che usando HTTPS aumenta la superficie d'attacco, che ci sono dei > problemi non tanto di migrazione quanto di maintenance. > > Per quanto riguarda i problemi di maintenance, in particolare, @jhourcle > puntualizza che: > > > I'm actually less concerned about the deployed and working than in long > > term maintenance. It's pretty typical to get support initially, but then > > resources are re-assigned once things are rolled out, leaving > > departments and projects to deal with the increased workload on their > > own. Consider it like technical debt -- up-front costs may be > > insignificant when you calculate the reoccurring costs > > [...] > > Many of these science tools were written at the beginning of missions > > that have since ended, and there is no funding to maintain them. > > E questo sicuramente e' un primo spunto di discussione, visto come viene > finanziata la ricerca (ma anche l'open source). > > Un altro spunto viene dalle risposte a @jhourcle, alcune delle quali > mettono in luce possibili conseguenze nefaste di non usare HTTPS. > > Ximin Luo (@infinity0) dice in particolare questa cosa molto > convincente: > > > HTTP as commonly used in web browsers, allows javascript injection > > attacks against your users. Even if your website doesn't have any > > "sensitive information", the attacker gains the ability to abuse your > > users for their own purposes. This is how the recent massive attack on > > Github was carried out - someone, ahem, attacked plaintext HTTP > > advertising traffic on seemingly innocent / unsensitive websites, to > > turn those users effectively into a massive botnet for DDoS against > Github. > > Tornando a quello che penso io, come dicevo la mia posizione di base > sull'argomento era "HTTPS sempre". Poi ho cominciato a capire che il > problema e' un po' piu' complesso durante il workshop NNTools2015 > (http://nexa.polito.it/nntools2015) che abbiamo organizzato qui a Nexa. > > Mi aveva colpito in particolare la presentazione del prof. Marco Mellia > (Politecnico di Torino) relativa al suo paper sui costi di HTTPS: > > > Researchers from CMU, Telefonica, and Politecnico di Torino have > > presented a paper at ACM CoNEXT that quantifies the cost of the "S" in > > HTTPS. The study shows that today major players are embracing end-to-end > > encryption, so that about 50% of web traffic is carried by HTTPS. This > > is a nice testament to the feasibility of having a fully encrypted web. > > The paper pinpoints also the cost of encryption, that manifests itself > > through increases in the page loading time that go above 50%, and > > possible increase in battery usage. However, the major loss due to the > > "S" is the inability to offer any in-network value added services, that > > are offered by middle-boxes, such as caching, proxying, firewalling, > > parental control, etc. > > > > > http://www.yro.slashdot.org/story/14/12/04/1513255/the-cost-of-the-s-in-htt… > > Sinceramente non sono molto interessato alla perdita dei servizi "value > added" nella rete, che probabilmente si possono spostare piu' vicini > agli utenti, ma mi interessa invece molto il discorso relativo a quelle > che sono le performance. Leggevo proprio qualche giorno fa che e' > stato abbastanza difficile per Neflix implementare HTTPS, e che hanno > risolto facendo la parte di cifratura simmetrica nel kernel: > > > Netflix will soon use the HTTPS protocol to authenticate and encrypt > > customer streams, a move that helps ensure what users watch stays > > secret [...] "In order to [...] implement TLS functionality, we > > designed a hybrid TLS scheme whereby session management would stay > > in the application space, but the bulk encryption would be inserted > > into the sendfile data pipeline in the kernel" > > > > > http://arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon… > > Tra l'altro, proprio nei commenti di questo articolo su Neflix qualcuno > suggeriva che forse non e' il caso di cifrare anche i video, che e' un > po' l'argomentazione di @jhourcle. Pero' non cifrare i video puo' voler > dire rivelare le proprie preferenze non solo, diciamo, a Netflix ma > anche al proprio ISP, e questo puo' dare fastidio. > > Tornando alla cifratura nel kernel, ma anche parlando semplicemente di > libssl, l'aumento della superficie di attacco, e' una argomentazione > interessante, che rimarra' vera finche' non salira' la qualita' delle > librerie che implementano SSL. Una variante "light" di questo > scetticismo verso SSL l'avevo gia' letta tempo fa nei sorgenti di Very > Secure FTP daemon (il che non significa che se lo dicono anche loro sia > giustificato lo scetticismo, ma che non e' un'opinione isolata). > > > vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. OpenSSL is > > a massive quantity of code which is essentially parsing complex > > protocol under the full control of remote malicious clients. SSL / > > TLS is disabled by default, both at compile time and run time. This > > forces packagers and administrators to make the decision that they > > trust the OpenSSL library. I personally haven't yet formed an opinion > > on whether I consider the OpenSSL code trustworthy. > > > > https://security.appspot.com/vsftpd/TRUST.txt > > Voi cosa ne pensate? > > Grazie per l'attenzione, > > Simone Basso > http://nexa.polito.it/people/sbasso > > > -------- Forwarded Message -------- > Subject: [ NNSquad ] Negative impact of HTTPS-only on agencies with > nonsensitive data > Date: Mon, 20 Apr 2015 08:32:51 -0700 > From: Lauren Weinstein <lauren(a)vortex.com> > To: nnsquad(a)nnsquad.org > > > Negative impact of HTTPS-only on agencies with nonsensitive data > > This is actually an extremely interesting discussion about the > potential impacts of a U.S. government HTTPS-only initiative on > underfunded government agencies with massive amounts of nonsensitive > legacy data -- in this case, NASA. Do read: > > "Please consider the impacts of banning HTTP": > > https://github.com/WhiteHouse/https/issues/107 > > - - - > > --Lauren-- > Lauren Weinstein (lauren(a)vortex.com) http://www.vortex.com/lauren > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >

April 24, 2015

"Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)

by Simone Basso

Cari tutti, tl;dr ho sempre pensato che il traffico HTTP dovrebbe sempre essere cifrato. Alcune discussioni e articoli letti recentemente mi hanno fatto capire che il problema e' piu' complesso e articolato, e voglio convidere con voi quello che ho letto e alcune mie riflessioni. Qualche giorno fa ho letto sulla lista NNSquad una email (in calce a questo messaggio) che penso possa essere utile per trollare^W^W^W parlare un po' dei costi della crittografia su questa lista. La parte piu' interessante di questa email era in realta' una discussione probabilmente destinata ad andare ancora avanti: "Please consider the impacts of banning HTTP": https://github.com/WhiteHouse/https/issues/107 La discussione viene aperta da Joe Hourclé (@jhourcle), "webserver e database admin" presso il Solar Data Analysis Center della NASA. La discussione ruota attorno alla policy del governo americano che mira a fare usare HTTPS a tutti i siti del governo: > The American people expect government websites to be secure and their > interactions with those websites to be private. Hypertext Transfer > Protocol Secure (HTTPS) offers the strongest privacy protection > available for public web connections with today’s internet technology. > The use of HTTPS reduces the risk of interception or modification of > user interactions with government online services. > > This proposed initiative, “The HTTPS-Only Standard,” would require the > use of HTTPS on all publicly accessible Federal websites and web services. > > https://https.cio.gov/ Il nucleo dell'argomentazione di @jhourcle e' che HTTPS ha senso per proteggere informazioni personali; dove non sono coinvolte informazioni personali, si puo' decidere caso per caso se usare HTTPS oppure se sia meglio continuare ad usare HTTP. Ossia che la policy "migriamo tutto ad HTTP adesso" sia eccessivamente strict. In particolare @jhourcle sostiene che i dati scientifici sono dati non sensibili che possono passare in chiaro (magari firmati), che ci sono dei costi infrastrutturali nel servire grosse quantita' di dati usando HTTPS, che usando HTTPS aumenta la superficie d'attacco, che ci sono dei problemi non tanto di migrazione quanto di maintenance. Per quanto riguarda i problemi di maintenance, in particolare, @jhourcle puntualizza che: > I'm actually less concerned about the deployed and working than in long > term maintenance. It's pretty typical to get support initially, but then > resources are re-assigned once things are rolled out, leaving > departments and projects to deal with the increased workload on their > own. Consider it like technical debt -- up-front costs may be > insignificant when you calculate the reoccurring costs > [...] > Many of these science tools were written at the beginning of missions > that have since ended, and there is no funding to maintain them. E questo sicuramente e' un primo spunto di discussione, visto come viene finanziata la ricerca (ma anche l'open source). Un altro spunto viene dalle risposte a @jhourcle, alcune delle quali mettono in luce possibili conseguenze nefaste di non usare HTTPS. Ximin Luo (@infinity0) dice in particolare questa cosa molto convincente: > HTTP as commonly used in web browsers, allows javascript injection > attacks against your users. Even if your website doesn't have any > "sensitive information", the attacker gains the ability to abuse your > users for their own purposes. This is how the recent massive attack on > Github was carried out - someone, ahem, attacked plaintext HTTP > advertising traffic on seemingly innocent / unsensitive websites, to > turn those users effectively into a massive botnet for DDoS against Github. Tornando a quello che penso io, come dicevo la mia posizione di base sull'argomento era "HTTPS sempre". Poi ho cominciato a capire che il problema e' un po' piu' complesso durante il workshop NNTools2015 (http://nexa.polito.it/nntools2015) che abbiamo organizzato qui a Nexa. Mi aveva colpito in particolare la presentazione del prof. Marco Mellia (Politecnico di Torino) relativa al suo paper sui costi di HTTPS: > Researchers from CMU, Telefonica, and Politecnico di Torino have > presented a paper at ACM CoNEXT that quantifies the cost of the "S" in > HTTPS. The study shows that today major players are embracing end-to-end > encryption, so that about 50% of web traffic is carried by HTTPS. This > is a nice testament to the feasibility of having a fully encrypted web. > The paper pinpoints also the cost of encryption, that manifests itself > through increases in the page loading time that go above 50%, and > possible increase in battery usage. However, the major loss due to the > "S" is the inability to offer any in-network value added services, that > are offered by middle-boxes, such as caching, proxying, firewalling, > parental control, etc. > > http://www.yro.slashdot.org/story/14/12/04/1513255/the-cost-of-the-s-in-htt… Sinceramente non sono molto interessato alla perdita dei servizi "value added" nella rete, che probabilmente si possono spostare piu' vicini agli utenti, ma mi interessa invece molto il discorso relativo a quelle che sono le performance. Leggevo proprio qualche giorno fa che e' stato abbastanza difficile per Neflix implementare HTTPS, e che hanno risolto facendo la parte di cifratura simmetrica nel kernel: > Netflix will soon use the HTTPS protocol to authenticate and encrypt > customer streams, a move that helps ensure what users watch stays > secret [...] "In order to [...] implement TLS functionality, we > designed a hybrid TLS scheme whereby session management would stay > in the application space, but the bulk encryption would be inserted > into the sendfile data pipeline in the kernel" > > http://arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon… Tra l'altro, proprio nei commenti di questo articolo su Neflix qualcuno suggeriva che forse non e' il caso di cifrare anche i video, che e' un po' l'argomentazione di @jhourcle. Pero' non cifrare i video puo' voler dire rivelare le proprie preferenze non solo, diciamo, a Netflix ma anche al proprio ISP, e questo puo' dare fastidio. Tornando alla cifratura nel kernel, ma anche parlando semplicemente di libssl, l'aumento della superficie di attacco, e' una argomentazione interessante, che rimarra' vera finche' non salira' la qualita' delle librerie che implementano SSL. Una variante "light" di questo scetticismo verso SSL l'avevo gia' letta tempo fa nei sorgenti di Very Secure FTP daemon (il che non significa che se lo dicono anche loro sia giustificato lo scetticismo, ma che non e' un'opinione isolata). > vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. OpenSSL is > a massive quantity of code which is essentially parsing complex > protocol under the full control of remote malicious clients. SSL / > TLS is disabled by default, both at compile time and run time. This > forces packagers and administrators to make the decision that they > trust the OpenSSL library. I personally haven't yet formed an opinion > on whether I consider the OpenSSL code trustworthy. > > https://security.appspot.com/vsftpd/TRUST.txt Voi cosa ne pensate? Grazie per l'attenzione, Simone Basso http://nexa.polito.it/people/sbasso -------- Forwarded Message -------- Subject: [ NNSquad ] Negative impact of HTTPS-only on agencies with nonsensitive data Date: Mon, 20 Apr 2015 08:32:51 -0700 From: Lauren Weinstein <lauren(a)vortex.com> To: nnsquad(a)nnsquad.org Negative impact of HTTPS-only on agencies with nonsensitive data This is actually an extremely interesting discussion about the potential impacts of a U.S. government HTTPS-only initiative on underfunded government agencies with massive amounts of nonsensitive legacy data -- in this case, NASA. Do read: "Please consider the impacts of banning HTTP": https://github.com/WhiteHouse/https/issues/107 - - - --Lauren-- Lauren Weinstein (lauren(a)vortex.com) http://www.vortex.com/lauren Founder: - Network Neutrality Squad: http://www.nnsquad.org - PRIVACY Forum: http://www.vortex.com/privacy-info Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info Member: ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com Google+: http://google.com/+LaurenWeinstein Twitter: http://twitter.com/laurenweinstein Tel: +1 (818) 225-2800 / Skype: vortex.com

April 24, 2015

"Le sfide giuridiche della robotica di servizio: sicurezza, trattamento dati, diritti e responsabilità", 11 maggio - Università degli Studi di Torino

by Giuseppe Futia

Se non visualizzi correttamente questo messaggio clicca qui <http://nexa.polito.it/2015/05/robotica> NEXA Lunedì 11 maggio 2015, ore 10-17 Università degli Studi di Torino Campus Luigi Einaudi - Aula Magna Lungo Dora Siena, 104 (mappa <https://maps.google.it/maps?q=Campus+Luigi+Einaudi&ll=45.074293,7.699721&sp…>) http://nexa.polito.it/2015/05/robotica Le sfide giuridiche della robotica di servizio: sicurezza, trattamento dati, diritti e responsabilità *Registrazione obbligatoria all'indirizzo*: http://robotica2015.eventbrite.com L'incontro è accreditato dal Consiglio dell’Ordine degli Avvocati di Torino <http://www.ordineavvocatitorino.it/>. La partecipazione è titolo per l'attribuzione di 6 crediti formativi. Il convegno si iscrive nell'ambito di una collaborazione di ricerca in merito agli aspetti giuridici della robotica di servizio in corso tra Telecom Italia e il Centro Nexa su Internet & Società del Politecnico di Torino (DAUIN): http://nexa.polito.it/law-of-service-robots. *IL PROGRAMMA* *10:00 – 10:30* *Apertura dei lavori e saluti* *Gianmaria Ajani* – Rettore dell'Università degli Studi di Torino *Juan Carlos De Martin* – Co-direttore del Centro Nexa su Internet & Società del Politecnico di Torino *Gabriele Elia* – Direttore dell'Open Innovation Research di Telecom Italia Introduce *Ugo Pagallo* – Docente di filosofia del diritto all'Università degli Studi di Torino e Faculty Fellow del Centro Nexa *10:30 – 13:00 **Le sfide giuridiche della robotica di servizio* Presiede *Luca De Biase* (Direttore di Nòva24 e Trustee del Centro Nexa) Intervengono alla tavola rotonda: *Carlo Blengino* (Avvocato e Fellow del Centro Nexa) *Gian Piero Fici* (JOL CRAB Telecom Italia) *Giovanni B. Gallus* (Avvocato e Fellow del Centro Nexa) *Monica A. Senor* (Avvocato e Fellow del Centro Nexa) *Massimo Travostino* (Avvocato e del Fellow del Centro Nexa) *13:00 - 14:45* *Light Lunch* *14:45 - 16:30* *Droni e diritti su beni immateriali, sicurezza e protezione dati, tra problemi aperti e prospettive future* Presiede *Federico Morando* – Director of Research and Policy del Centro Nexa *Mauro Alovisio* (Avvocato e Fellow del Centro Nexa) – /Il regolamento ENAC: problemi e prospettive/ *Marco Ciurcina* (Avvocato e Fellow del Centro Nexa) – /Robotica e diritti su beni immateriali/ *Guido Noto La Diega* (Queen Mary University Of London) – /Robot, privacy e data protection/ *Giuseppe Vaciago* (Avvocato e Fellow del Centro Nexa) – /Robot, digital forensics e cyber security/ *15:45 - 16:30* *Domande dal pubblico* *16:30 - 17:00* *Conclusione dei lavori* *Oreste Calliano* (Docente di diritto privato comparato all'Università degli Studi di Torino e Direttore del Centro Europeo di Diritto dell'Informatica e del Consumo) – /Il progetto europeo SMAT/ *Ugo Pagallo* (Università degli Studi di Torino e Centro Nexa) – /Riflessioni conclusive/ *Scarica la versione PDF della locandina <http://nexa.polito.it/nexacenterfiles/robotica2015.pdf>*. *Per maggiori informazioni potete scrivere a giuseppe.futia(a)polito.it* See our events calendar <http://nexa.polito.it/events> if you're curious about future luncheons, discussions, lectures, and conferences not listed in this email. Our events are free and open to the public, unless otherwise noted. Maggiori informazioni sul Centro Nexa su Internet & Società del Politecnico di Torino sono disponibili all'indirizzo: http://nexa.polito.it/. Weekly Events Newsletter. Sign up <http://nexa.polito.it/mailing-lists> to receive this newsletter if this email was forwarded to you. To manage your subscription preferences, please click here <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>. Connect & get involved: Jobs, internships, and more <http://nexa.polito.it/get-involved> Nexa Center for Internet and Society Newsletter

April 24, 2015

Il diritto all’oblio su Internet dopo la sentenza Google Spain_Libro

by Alessandro Mantelero

Segnalo a quanti interessati il seguente volume, rilasciato con licenza Creative Commons attribution 4.0 (CC BY-NC-ND 4.0) Il diritto all’oblio su Internet dopo la sentenza Google Spain Curatori: Giorgio Resta e Vincenzo Zeno-Zencovich Editore: RomaTrE-Press Data di pubblicazione: aprile 2015 Pagine: 362 p. ISBN: 978-88-97524-27-4 Il volume costituisce un commentario a tutto tondo della epocale sentenza della Corte di Giustizia UE nel caso noto come Google Spain. La decisione viene analizzata da quattordici esperti della materia nelle prospettive di diritto costituzionale, di diritto privato, del diritto internazionale privato, del diritto penale, delle relazioni internazionali, tenendo sempre in mente i riflessi che essa avrà, in generale, sulle attività sulla rete. Gli Autori evidenziano potenzialità e criticità della sentenza ed i vari aspetti, anche pratici, che deriveranno dalla sua attuazione e come sotto la accattivamente formula del "diritto all'oblio" vi siano questioni e prospettive ben più complesse. http://ojs.romatrepress.uniroma3.it/index.php/oblio -- Avv. Alessandro Mantelero Aggregate Professor, Politecnico di Torino Director of Privacy and Faculty Fellow, Nexa Center for Internet and Society Coordinator, Double Degree program in Management and IP Law, Politecnico di Torino–Tongji University of Shanghai http://staff.polito.it/alessandro.mantelero http://nexa.polito.it/people/amantelero EMAIL POLICY: twice a day (Mon-Fri)

April 24, 2015

Fwd: [Creis_Terminal] Loi sur le renseignement : un projet liberticide et grave pour la démocratie

by Mariella Berra

grazie a Casilli -------- Messaggio Inoltrato -------- Oggetto: [Creis_Terminal] Loi sur le renseignement : un projet liberticide et grave pour la démocratie Data: Thu, 23 Apr 2015 11:23:30 +0200 Mittente: Maurice Liscouët <maurice.liscouet(a)univ-nantes.fr> A: creis_terminal(a)lecreis.org Club Droits, Justice & SÃ©curitÃ©s <http://blogs.mediapart.fr/edition/club-droits-justice-securites> Le club Droit, Justice et SÃ©curitÃ©s a pris connaissance avec une grande inquiÃ©tude du projet de loi adoptÃ© par le Gouvernement sur le renseignement. http://blogs.mediapart.fr/edition/club-droits-justice-securites/article/140… -- Maurice LiscouÃ«t

April 23, 2015

la nuova legge francese sull’intelligence spaventa la società civile

by Antonio Casilli

Oggi Carola Frediani su La Stampa "Il tricolore francese è oscurato da una scatola nera" http://www.lastampa.it/2015/04/23/tecnologia/sorveglianza-dentro-le-scatole… Oggi su Le Monde, "Il Manifesto dei 110.000" contro il progetto di legge http://www.lemonde.fr/idees/article/2015/04/23/loi-sur-le-renseignement-le-…

April 23, 2015

Su Open Data e corruzione

by rassu

Buongiorno. Vi segnalo un recente articolo su Open Data e corruzione comparso su "Il Fatto Quotidiano" http://www.ilfattoquotidiano.it/2015/04/18/open-data-rapporto-in-italia-imp… Cordialmente antonio l. rassu cell. +39 335 7550689

April 23, 2015

Wired: "We Can’t Let John Deere Destroy the Very Idea of Ownership"

by J.C. DE MARTIN

KYLE WIENS 04.21.15 *WE CAN’T LET JOHN DEERE DESTROY THE VERY IDEA OF OWNERSHIP *IT’S OFFICIAL: JOHN Deere and General Motors want to eviscerate the notion of ownership. Sure, we pay for their vehicles. But we don’t own them. Not according to their corporate lawyers, anyway. In a particularly spectacular display of corporate delusion, John Deere—the world’s largest agricultural machinery maker —told the Copyright Office that farmers don’t own their tractors. Because computer code snakes through the DNA of modern tractors, farmers receive “an implied license for the life of the vehicle to operate the vehicle.” It’s John Deere’s tractor, folks. You’re just driving it. Several manufacturers recently submitted similar comments to the Copyright Office under an inquiry into the Digital Millennium Copyright Act. DMCA is a vast 1998 copyright law that (among other things) governs the blurry line between software and hardware. The Copyright Office, after reading the comments and holding a hearing, will decide in July which high-tech devices we can modify, hack, and repair—and decide whether John Deere’s twisted vision of ownership will become a reality. […] Continua qui: http://www.wired.com/2015/04/dmca-ownership-john-deere/ * *

April 22, 2015

Resolution 2045 (2015) On Mass Surveillance

by Carlo Blengino

L'assemblea parlamentare del Consiglio d'Europa ieri ha approvato questa risoluzione che mi pare perfetta: http://assembly.coe.int/nw/xml/XRef/Xref-XML2HTML-en.asp?fileid=21692&lang=… Peccato la UE continui a non farne parte... C. In mobilità

April 22, 2015

The Next Tech

by A Dicorinto

Cari tutti, tutte- forse sapete, forse no, che con Riccardo Luna abbiamo aperto una nuova sezione di Start Up Italia dove raccontare le tecnologie che migliorano il futuro. http://thenexttech.startupitalia.eu/ E allora, oltre a chiedere il vostro feedback per aggiustare il tiro dell'iniziativa vi dico che saremmo felici di avere dai membri di questa lista idee e proposte di collaborazione per raccontare il mondo delle nuove tecnologie e far emergere i talenti italiani che le creano. In particolare io vorrei far emergere quello che si fa nelle nostre università, nei parchi scientifici, nei distretti tecnologici, perchè sono certo che lì c'è una grande riserva di inventività capace anche di reggere il confronto col mercato. Grazie per l'attenzione, a presto -- Arturo Di Corinto www.dicorinto.it ---------------------------------> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003

April 22, 2015