Le interfacce che ci ingannano, in pratica: 4 casi di studio | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

Home » Blog » Le interfacce che ci ingannano, in pratica: 4 casi di studio

11/05/2017

Le interfacce che ci ingannano, in pratica: 4 casi di studio

[di Maurizio Boscarol]

Un’interessante articolo del programmatore Quincy Larson racconta molto meglio degli articoli della stampa generalista il dilemma che abbiamo davanti, come “operatori dell’informatica”. Uso questo termine, perché, anche se Larson la vede dal lato programmatore, il problema riguarda tutti noi: designer, analisti, progettisti dell’esperienza, esperti di interfacce, di usabilità, di architettura dell’informazione, di service design, e quante altre etichette volete assumervi.

Ed è un problema etico. Per nulla teorico, però.

Larson racconta fatti noti e meno noti di come 3 grandi aziende abbiano mentito, tratto profitto e ingannato, al punto da prendersi l’accusa di aver causato delle morti, grazie al software.

Uber, ovvero, come ti aggiro le leggi senza che tu lo sappia

Nelle città in cui non è ancora concesso a Uber di operare, a volte poliziotti in borghese tentano di prendere un passaggio sull’app Uber, con l’obiettivo di multare il conducente in flagrante. Uber ha trovato il modo di evitare i controlli di polizia in un modo molto ingegnoso: identifica i poliziotti sotto copertura riconoscendoli attraverso un incrocio di dati, sia dai social, sia, forse da altre fonti (Larson parla di una banca dati di carte di credito usate dalla polizia). Quando l’utente identificato come appartenente alle forze dell’ordine cerca il passaggio Uber, l’app mostra (a lui, e solo a lui) delle macchine fantasma. Che non esistono, e che lui non vedrà mai arrivare, perché l’app gli mostrerà che devono fermarsi a prendere un altro cliente, o che sono dirette altrove.

Di fatto, il poliziotto non riuscirà mai a incastrare alcun autista Uber abusivo. E rimarrà semplicemente convinto di essere sfortunato, e di non riuscire a prendere un passaggio perché capita sempre nel posto sbagliato al momento sbagliato.

Questa tecnologia, chiamata Greyball, è stata in uso dal 2014, ed è stata sfruttata sia in alcune città USA, come Portland, Las Vegas e Boston, sia a Parigi, in Australia, Cina e Corea del Sud.

Dopo essere stata svelata dal New York Times, e come risposta anche ad altre controversie, Uber ha annunciato una revisione del modo in cui questa tecnologia è stata usata, e ne ha proibito l’uso per aggirare l’intervento delle forze dell’ordine. Attualmente è in corso un’inchiesta federale sull’uso di Greyball dai potenziali risvolti penali.

Zenefits, o il più classico degli imbrogli sulla formazione

Ok, visto come noi in Italia sfruttiamo i soldi europei per la formazione, creando una miridade di corsi inutili, con il tasso di occupazione a seguire fra i più bassi d’Europa, può sembrare una frode ridicola. Ma se prendiamo sul serio le garanzie, non lo è. Zenefits produce software per la gestione di uffici assicurativi. Nel 2016 si è scoperto che, grazie a una estensione proprietaria per il browser, aveva aiutato le agenzie a far saltare ai nuovi assunti un corso online obbligatorio per avere l’abilitazione a operare come agenti assicurativi.

52 ore di corso, con tanto di quiz annessi, saltate, per consentire alle agenzie di sfruttare quelle ore facendo lavorare subito i nuovi arrivati. Un bel risparmio per le agenzie, una bella garanzia in meno per il cliente. Un imbroglio per i certificatori.

Volkswagen, le emissioni differenziali e i 60 morti

Lo scandalo emissioni del 2015 della Volkswagen è noto a tutti, perché abbastanza clamoroso da arrivare sui telegiornali nazionali. Meno noto è il meccanismo usato. In pratica, un software era in grado di identificare i pattern di regolazioni e parametri usati dagli ispettori per il test sulle emissioni, perché evidentemente differivano da quelli di uso comune.

Il resoconto delle emissioni veniva dunque alterato, ma, appunto, solo per le ispezioni.

In pratica, è come se il software funzionasse normalmente, e non fosse ingannevole, tranne durante i test. L’interfaccia di output mentiva, ma solo a poche specifiche domande: quelle che ponevano gli ispettori.

L’andamento del titolo Volkswagen con il crollo in corrispondenza dello scandalo di settembre-ottobre 2015

Rispetto agli altri casi citati, questo è anche il più grave. Volkswagen è accusata di aver venduto 10 milioni di macchine che inquinavano fino a 40 volte il limite consentito (negli USA).

Stime del MIT sostengono che questo avrebbe contribuito ad un aumento del cancro ai polmoni, causando una morte prematura di 60 persone solo in America.

Il farmaco adatto a tutte le situazioni

Un altro autore, Bill Sourour, in un altro articolo fa un altro esempio personale, risalente a diversi anni fa, quando venne incaricato di realizzare un sito informativo di carattere medico-sanitario. Questi siti avevano il divieto di reclamizzare direttamente dei farmaci, così il committente aveva richiesto che il sito ponesse domande all’utente sui propri sintomi e poi, qualunque fossero le risposte (tranne in caso di accertata allergia ai componenti, suppongo per evitare cause legali) che l’utente venisse comunque rimandato alla reclame di un farmaco specifico, sempre lo stesso, fingendo che fosse una scelta basata sulle sue risposte.

L’autore scoprì poco dopo aver realizzato l’algoritmo che il farmaco era sotto accusa perché aumentava, in una piccola percentuale di utilizzatori, le tendenze suicide!

Non è tutto: Sourour scoprì poco dopo che la sorella assumeva il farmaco e fece di tutto per convincerla ad abbandonarlo, per fortuna con successo. Naturalmente, non si sentì benissimo ad aver realizzato il software che guidava l’utente sul sito, e poco dopo si dimise dall’agenzia web per cui lavorava.

Il codice può mentire. E lo fa attraverso le interfacce

Il punto è chiaro, e anche ovvio: con il codice si può mentire. E si può anche uccidere: non per forza con intenzione, ma anche semplicemente con dei bachi, come il caso del software Toyota che causava involontarie accelerazioni che hanno ucciso almeno 89 persone.

Qui però ci troviamo di fronte a software che mentono consapevolmente. Ed è ancora più facile che farlo di persona, perché non c’è il contatto diretto con le persone (come nel front-end degli sportelli o nei call-center). E’ facile per i progettisti sentirsi a posto con la coscienza, anche se sanno che stanno progettando un meccanismo fraudolento, perché in realtà non lo stanno somministrando loro: svolgono solo un lavoro.

Ma dovrebbe essere ancora più chiaro che non è il codice a mentire: il codice fa quello che gli diciamo di fare. Il codice è il nostro discorso, la nostra retorica, l’architettura delle azioni e delle reazioni che noi progettiamo.

Poiché il codice è nascosto, sono le interfacce, quelle che alla fine dicono il vero o mentono. Perché è attraverso la componente di interfaccia che il codice agisce e si fa capire, si relaziona con gli utenti. Di questo potenziale manipolatorio avevamo già parlato in passato, e sappiamo che anche i social hanno un forte orientamento persuasivo. Qui andiamo ancora oltre: non modifichiamo solo la probabilità dei comportamenti, ma mentiamo agli utenti attraverso il codice.

L’effetto placebo dei codici etici

Il problema dell’etica nelle nuove tecnologie è presente almeno dagli anni ’40, quando Norman Wiener scrisse Cybernetics: Or Control and Communication in the Animal and the Machine. In seguito approfondì il tema con The Human Use of Human Beings.

Un codice etico è in realtà già in vigore per i membri dell’American Computer Machinery (ACM), la principale associazione e comunità di pratiche in ambito informatico. Ciò non ha impedito che anche in realtà informatiche nordamericane si realizzassero pratiche fraudolente attraverso il codice.

L’ACM sta provando ad aggiornare il proprio codice etico, con il progetto di licenziarlo entro il 2018.

Ma, proprio come i codici etici in ambito medico non garantiscono da medici imbroglioni, come potrà un nuovo codice etico in ambito informatico garantirci dalla presumibile crescente pressione da parte dei committenti a produrre codice e interfacce che servano soprattutto a difendere i loro interessi, piuttosto che il bene della società nel suo insieme?

Esiste un modo legale per difendersi?

Il tema da porsi è semmai se l’attuale impianto legislativo e sanzionatorio sia adeguato a scoraggiare comportamenti che poi, una volta messi in atto, sono difficili da scoprire, perché “nascosti” dietro algoritmi chiusi in una scatola nera, che potrebbero anche non rivelarsi mai come truffaldini in modo palese, se l’interfaccia mente bene. E molto diversi dalle tradizionali “frodi informatiche” di cui si parla di solito sui giornali, associate a imprecisati soggetti oscuri, esperti informatici solitari che agiscono individualmente o per conto del miglior offerente. No, qui parliamo di software ufficiali di grandi gruppi.

Il problema diventa quindi di metodologie di controllo, in primis, e in seguito di meccanismi di sanzione.

Un tema molto difficile da affrontare, e su cui è molto probabile continueremo a interrogarci ancora a lungo.

Ulteriori letture

Focus on Ethic sul sito dell’FBI

Professional code of ethics in Software development

Software engineering ethics

12 ethical dilemmas gnawing at developers today

Ethics and software development

An Introduction to Software Engineering Ethics

Professional Ethics of Software Engineers: An Ethical Framework

Tag: , ,

Iscriviti alla newsletter di usabile.it:

Circa una mail al mese con gli aggiornamenti più significativi.

Commenta


 

torna su Torna su

Privacy Policy