regole di ingaggio
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso? Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono: http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-... Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo? — Beppe
Bryant Walker Smith si è occupato di autonomous driving per anni. Qui trovi il suo profilo e pubblicazioni. Giancarlo 2015-12-27 6:17 GMT-08:00 Giuseppe Attardi <attardi@di.unipi.it>:
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso?
Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono:
http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-...
Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo?
— Beppe
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il 27/12/2015 15:17, Giuseppe Attardi ha scritto:
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso?
Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono: http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-...
Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo?
forse bisogna obbligare alla progettazione di freni e motori "normalmente bloccati/spenti" e lasciare al software di tenerli sbloccati/accesi tale che una volta che il supervisor di turno emette un killall -u googlecar (inteso come l'utente sotto il quale girano tutti e solo i processi della Google Car) a quel punto il freno ed il motore tornano nella valle di minimo energetico e blocca le ruote/spegne il motore (la via di mezzo puo includere una procedura di parcheggio al lato della strada etc etc) comunque i processi supervisionati sono una realta ampiamente usata (vedi ad esempio la subordinazione nel kernel di linux con i namespaces i.e. host GNU/Linux + lxc container) saluti
Temo sia necessario un "salto quantico" di mentalità prima che tecnologico. Un salto umanistico. Con questa tecnologia e tecnicismi NON se ne esce. Sia chiaro a tutti. Come un inseguimento "guardie ladri" anche in campo giuridico. Se non si uscirà anche dal terifficante pensiero unico ubiquitario dei Chicago Boys per un nuovo paradigma socioeconomico non ci sarà nulla da fare. La megamacchina andrà a sbattere. E il Cigno nero volteggia. Se i tecno-logici e i tecno-giuristi non alzano lo sguardo dalle loro tecnicaglie, mentre anche il Panoptikon appare robeta da dilettanti, per accedere a piani superiori, la vedo molto male. Io personalmente mi sono stufato, vorrei buttare tutta la tecnologia e coltivare rose antiche, per recuperare il mio cervello e la mia libertà. Siamo ancora l'uomo del Paleolitico, ma questo non è noto e tenuto in considerazione nella maggior parte degli ambiti "scientifici" soprattutto akkademici, presi coi loro orticelli. Evoluzione zero. Buone Buonissime feste a tutti voi, che leggo silente, con gran piacere. Auguroni! JMPini Invio eseguito dallo smartphone BlackBerry 10. Messaggio originale Da: mutek Inviato: lunedì 28 dicembre 2015 10:04 A: nexa@server-nexa.polito.it >> NEXA server Oggetto: Re: [nexa] regole di ingaggio Il 27/12/2015 15:17, Giuseppe Attardi ha scritto:
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso?
Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono: http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-...
Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo?
forse bisogna obbligare alla progettazione di freni e motori "normalmente bloccati/spenti" e lasciare al software di tenerli sbloccati/accesi tale che una volta che il supervisor di turno emette un killall -u googlecar (inteso come l'utente sotto il quale girano tutti e solo i processi della Google Car) a quel punto il freno ed il motore tornano nella valle di minimo energetico e blocca le ruote/spegne il motore (la via di mezzo puo includere una procedura di parcheggio al lato della strada etc etc) comunque i processi supervisionati sono una realta ampiamente usata (vedi ad esempio la subordinazione nel kernel di linux con i namespaces i.e. host GNU/Linux + lxc container) saluti _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
L'adottabilità di sistemi di guida autonoma non credo sia un problema tecnico ma sociale. Il poliziotto deve poter bloccare un'auto ? E se a bordo c'è un criminale ? E se a bordo c'è uno che sta andando al pronto soccorso ? (Vi ricordo che uno degli argomenti per il traffic management, ribadito dai policymaker in tutto il mondo è poter controllare la latenza per assicurare che l'applicazione salva-vita non funzioni per colpa di qualche decimo di secondo di ritardo, come si concilierebbe con l'idea di un poliziotto che blocca per molti minuti un'auto?) Il vantaggio degli umani è che le difformità rispetto al comportamento atteso vengono giudicate ex post con una responsabilità di un soggetto. Un sistema algoritmico deve prevedere ex ante la difformità dal comportamento atteso ed un sistema non algoritmico ci lascia senza un soggetto responsabile per un giudizio ex post. (A meno di sistemi di proprietà pubblica, sotto controllo pubblico, tale che si possa asserire ex ante la loro estraneità a responsabilità, vuoi per difetti che per errate manutenzioni/patch) Per non parlare poi di security. Essendo tutti i nostri sistemi vulnerabili, soggetti ad attacchi di ddos con botnet e 0days, nel caso di veicoli a guida autonoma con in più una dipendenza da lettura di uno scenario che può essere tampered... Ci fideremmo ad avere molte migliaia di computer da 2 tonnellate che girano a pochi centimetri da dove siamo noi a piedi ? Quelle che stiamo vedendo adesso sono delle grandi demo... Non dico che la tecnologia non verrà usata, ma che secondo me sarà sempre come ausilio alla guida, con "l'autista" responsabile. My cent... Ciao, s. Il 28 dicembre 2015 10:04:17 mutek <mutek@riseup.net> ha scritto:
Il 27/12/2015 15:17, Giuseppe Attardi ha scritto:
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso?
Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono: http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-...
Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo?
forse bisogna obbligare alla progettazione di freni e motori "normalmente bloccati/spenti" e lasciare al software di tenerli sbloccati/accesi tale che una volta che il supervisor di turno emette un killall -u googlecar (inteso come l'utente sotto il quale girano tutti e solo i processi della Google Car) a quel punto il freno ed il motore tornano nella valle di minimo energetico e blocca le ruote/spegne il motore (la via di mezzo puo includere una procedura di parcheggio al lato della strada etc etc) comunque i processi supervisionati sono una realta ampiamente usata (vedi ad esempio la subordinazione nel kernel di linux con i namespaces i.e. host GNU/Linux + lxc container) saluti
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Credo anch'io che ci limiteremo ad applicazioni limitate e che non vedremo mai un impiego generalizzato di auto che si guidano da sole, almeno non in un contesto urbano come quello Europeo. Il pilota automatico segue sempre, senza mai violarle, regole che nella realtà nessun umano segue sempre e alla lettera, e che vengono regolarmente interpretate in senso molto lato dai guidatori. Ad esempio nessun pilota automatico farà una breve retro per far uscire qualcuno dal parcheggio se giudica che sia opportuno, o salirà di 10 cm su un marciapiede per far passare traffico in senso opposto o un'ambulanza. Non lo farà perché è vietato. In alternativa per rendere il sistema adatto a piloti automatici occorrerà adattare le regole vigenti anche per gli umani, e delinearle con un tale dettaglio da rendere un esame di guida impossibile. Il sistema sociotecnico attuale attorno al traffico automobilistico prevede norme (non regole giuridiche, ma norme sociali, non scritte ma seguite da tutti) che richiedono di violare le regole scritte in base al buon senso. I sistemi automatici, per quanto possano essere sofisticati ed approssimare il buon senso, seguono solo le regole codificate senza poterle violare. Ai primi "self-driving mega-jam" ci ripenseremo... Ciao, A On 28/12/2015 10:34, Stefano Quintarelli wrote:
L'adottabilità di sistemi di guida autonoma non credo sia un problema tecnico ma sociale. Il poliziotto deve poter bloccare un'auto ? E se a bordo c'è un criminale ? E se a bordo c'è uno che sta andando al pronto soccorso ? (Vi ricordo che uno degli argomenti per il traffic management, ribadito dai policymaker in tutto il mondo è poter controllare la latenza per assicurare che l'applicazione salva-vita non funzioni per colpa di qualche decimo di secondo di ritardo, come si concilierebbe con l'idea di un poliziotto che blocca per molti minuti un'auto?) Il vantaggio degli umani è che le difformità rispetto al comportamento atteso vengono giudicate ex post con una responsabilità di un soggetto. Un sistema algoritmico deve prevedere ex ante la difformità dal comportamento atteso ed un sistema non algoritmico ci lascia senza un soggetto responsabile per un giudizio ex post. (A meno di sistemi di proprietà pubblica, sotto controllo pubblico, tale che si possa asserire ex ante la loro estraneità a responsabilità, vuoi per difetti che per errate manutenzioni/patch)
Per non parlare poi di security. Essendo tutti i nostri sistemi vulnerabili, soggetti ad attacchi di ddos con botnet e 0days, nel caso di veicoli a guida autonoma con in più una dipendenza da lettura di uno scenario che può essere tampered... Ci fideremmo ad avere molte migliaia di computer da 2 tonnellate che girano a pochi centimetri da dove siamo noi a piedi ?
Quelle che stiamo vedendo adesso sono delle grandi demo...
Non dico che la tecnologia non verrà usata, ma che secondo me sarà sempre come ausilio alla guida, con "l'autista" responsabile.
My cent...
Ciao, s.
Il 28 dicembre 2015 10:04:17 mutek <mutek@riseup.net> ha scritto:
Il 27/12/2015 15:17, Giuseppe Attardi ha scritto:
In un sogno che stavo facendo poco fa mi trovavo a scrivere delle norme per bloccare processi su macchine fuori controllo. Stavo imponendo l’esistenza su ciascuna macchina di un servizio standard, che denominavo ProgramManager, attraverso il quale si poteva intervenire per uccidere un processo. A parte il fatto che non sapevo come fare a garantirne la presenza, dato che le macchine hanno sistemi operativi diversi (forse ci si può basare su SNMP), poi mi chiedevo chi avesse il diritto di intervenire. Allora mi immaginavo che prima di intervenire, si dovesse chiedere al responsabile della macchina. Pensavo che lo si dovesse informare via mail, dandogli 5 minuti di tempo per rispondere. Ma anche questo era difficile, perché in 5 minuti un processo potrebbe averne generati altre migliaia, rendendo difficile poi andarli a uccidere selettivamente. Ricordo che mi é già capitato di non fare in tempo a uccidere i processi, perché l’esecuzione dei comandi di kill richiedeva più tempo della rapidità con cui i nuovi venivano generati. Pensavo però che male che vada, potevo comunque spegnere la macchina o staccarla dalla rete. Ma ora la cosa si complica se la macchina è un server virtuale: spegnerla potrebbe interferire con altre attività legittime in corso sulla stessa macchina. Anche staccarla dalla rete non è più così semplice: non si può semplicemente staccare il cavo. Intanto i cavi posso essere più di uno e poi ci sono le connessioni wireless. Allora bisogna intervenire sul router: ma se poi il problema è sul router stesso?
Mi sono così reso conto che il problema è più complicato di quanto immaginassi e mi chiedevo se qualcuno ha definito delle “regole di ingaggio”, simili a quelle previste per le forze di polizia quando si trovano di fronte a una minaccia. In effetti il termine non è nuovo e lo sta proponendo anche il Pentagono: http://thehill.com/policy/cybersecurity/254206-dod-official-calls-for-cyber-...
Il sogno credo sia stato innescato dalla discussione che avevo avuto a cena su come ci si deve comportare di fronte a una Google car. Come fa la polizia a fermarla? Di chi è la responsabilità per gli incidenti? Chi va in galera per omicidio colposo?
forse bisogna obbligare alla progettazione di freni e motori "normalmente bloccati/spenti" e lasciare al software di tenerli sbloccati/accesi tale che una volta che il supervisor di turno emette un killall -u googlecar (inteso come l'utente sotto il quale girano tutti e solo i processi della Google Car) a quel punto il freno ed il motore tornano nella valle di minimo energetico e blocca le ruote/spegne il motore (la via di mezzo puo includere una procedura di parcheggio al lato della strada etc etc) comunque i processi supervisionati sono una realta ampiamente usata (vedi ad esempio la subordinazione nel kernel di linux con i namespaces i.e. host GNU/Linux + lxc container) saluti
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
participants (6)
-
Alberto Cammozzo -
GC F -
Giuseppe Attardi -
Joanne Maria Pini -
mutek -
Stefano Quintarelli