sul tema CA-FB, mi permetto di condividere questo mio articolo che e' stato poi ripreso da piu' parti.. ciao, s.
pure essendo abbastanza un profano su queste tematiche, mi permetto un commento, riportando uno stralcio dell’articolo:
The GDPR introduces the concept of profile portability, whereby a user can move her profile form one service provider to another, like we do when porting our telephone profile – the mobile phone number – from an operator to another. Introducing this form of ownership of one’s own profile data is important, but is certainly not enough. Portability must be complemented by interconnection: the operator to which we port our profile should be interconnected to the source operator so that we don’t loose contact with our online friends, like the operator to which we port our telephone number is interconnected and interoperates with the source operator. There is no technical reason why Whatsapp or Facebook operate like closed silos compared to SMS or email that work seamlessly across a multtude of service providers.
This provision, when introduced for dominant intermediaries, would spur competition and mitigate the data concentration problem. Fragmenting user data inhibits the creation of such big data that can be exploited for questionable political purposes.
la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori. La portabilità di un profilo in altri servizi, ad esempio WA o FB, richiederebbe una standardizzazione della struttura dei dati di interesse. Le strutture dei vari social network sono probabilmente semplici, ma immagino che ognuno cerchi di aggiungere qualcosa. La portabilità piena si potrebbe ottenere solo se tutti i fornitori offrissero la stessa “capacità espressiva”. Ma ciò è possibile? Saluti, -Paolo Atzeni
Il giorno 15 apr 2018, alle ore 15:54, Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto:
sul tema CA-FB, mi permetto di condividere questo mio articolo che e' stato poi ripreso da piu' parti..
ciao, s. <2018.03.25 Cambridge Analytica.docx>_______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Inoltre qualcuno ha contestato il "monopolio" di FB. In realtà di Social ne esistono tantissimi, ma il pregio di FB è esattamente quello di essere il più diffuso, per cui posso trovarvi la maggior parte della conoscenze del mio presente e del mio passato, quindi portare i dati da un Social all'altro, a parte la difficoltà tecnica di trasferimento, fa comunque perdere molto dell'appeal di un'unica piazza virtuale dove "incontrare" tutti gli amici. Però vorrei fare un'osservazione in controtendenza, dato che in questi giorni tutti si sono concentrati fondamentalmente sull'uso distorto; questo è sicuramente un aspetto grave, e, come giustamente osservato nell'articolo, la giustizia farà il suo corso. Tuttavia, assumendo un uso corretto e trasparente dei dati, si possono anche individuare molte potenzialità del metodo CA: programmi politici mirati sulle reali esigenze percepite dalla popolazione, sviluppo di prodotti calibrati sui gusti del pubblico, campagne di informazione sociale efficaci, il tutto realizzato attraverso sondaggi divertenti che la gente affronta volentieri e non a mezzo di noiose indagine statistiche. Come sempre, il problema è l'uso, non il mezzo Buona settimana a tutti D. ________________________________ From: nexa <nexa-bounces@server-nexa.polito.it> on behalf of Paolo Atzeni <atzeni@dia.uniroma3.it> Sent: Sunday, April 15, 2018 4:11 PM To: Stefano Quintarelli Cc: nexa@server-nexa.polito.it Subject: Re: [nexa] articolo pure essendo abbastanza un profano su queste tematiche, mi permetto un commento, riportando uno stralcio dell’articolo: The GDPR introduces the concept of profile portability, whereby a user can move her profile form one service provider to another, like we do when porting our telephone profile – the mobile phone number – from an operator to another. Introducing this form of ownership of one’s own profile data is important, but is certainly not enough. Portability must be complemented by interconnection: the operator to which we port our profile should be interconnected to the source operator so that we don’t loose contact with our online friends, like the operator to which we port our telephone number is interconnected and interoperates with the source operator. There is no technical reason why Whatsapp or Facebook operate like closed silos compared to SMS or email that work seamlessly across a multtude of service providers. This provision, when introduced for dominant intermediaries, would spur competition and mitigate the data concentration problem. Fragmenting user data inhibits the creation of such big data that can be exploited for questionable political purposes. la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori. La portabilità di un profilo in altri servizi, ad esempio WA o FB, richiederebbe una standardizzazione della struttura dei dati di interesse. Le strutture dei vari social network sono probabilmente semplici, ma immagino che ognuno cerchi di aggiungere qualcosa. La portabilità piena si potrebbe ottenere solo se tutti i fornitori offrissero la stessa “capacità espressiva”. Ma ciò è possibile? Saluti, -Paolo Atzeni Il giorno 15 apr 2018, alle ore 15:54, Stefano Quintarelli <stefano@quintarelli.it<mailto:stefano@quintarelli.it>> ha scritto: sul tema CA-FB, mi permetto di condividere questo mio articolo che e' stato poi ripreso da piu' parti.. ciao, s. <2018.03.25 Cambridge Analytica.docx>_______________________________________________ nexa mailing list nexa@server-nexa.polito.it<mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
no prob... cito due tecnologie che indirizzano a questo aspetto: SOLID https://solidplatform.org/ SOLID ha una pproccio piu' tradizionale e si basa su standard w3c esistenti. i server (applicazione e dati) si parlano tra loro tramite protocolli, usano API RESTful e RDF per codificare e scmabiare i metadati. ogni risorsa ha un URL e le applicazioni usano dei comandi via HTTP per accedere, creare, modificare o cancellare dati. puoi chiedere cosa c'e' in un container o aggiornarlo. IPFS https://ipfs.io/ ipfs ha un aspetto di particolare interesse, per me. immagina un DNS a livello di dati. tu non ti devi preoccupare del metodo di accesso al dato ne' di dove si trovi, c'e' un servizio di rete che te lo risolve. per cui tu semplicemente dici di leggere o scrivere dati associati ad una determinata chiave e cio' avviene, a prescindere da dove il dato si trovi e quale sia il metodo di accesso usato. tu che sei il padrone del tuo profilo puoi decidere di spostare i tuoi dati da un luogo all'altro (anche su una tua chiavetta USB, basta che sia raggiungibile!) ed aggiornare il puntatore in questa sorta di DNS. l'applicazione usa il nome del dato per accedervi, non la localizzazione. IPFS usa un hash che e' l'indirizzo fisico del dato ma per gli umani, per renderlo piu' semplice, si usa IPNS che e' l'indirizzo human-readable del dato. ciao!, s. On 15/04/2018 18:11, Paolo Atzeni wrote:
pure essendo abbastanza un profano su queste tematiche, mi permetto un commento, riportando uno stralcio dell’articolo:
The GDPR introduces the concept of profile portability, whereby a user can move her profile form one service provider to another, like we do when porting our telephone profile – the mobile phone number – from an operator to another. Introducing this form of ownership of one’s own profile data is important, but is certainly not enough. Portability must be complemented by interconnection: the operator to which we port our profile should be interconnected to the source operator so that we don’t loose contact with our online friends, like the operator to which we port our telephone number is interconnected and interoperates with the source operator. There is no technical reason why Whatsapp or Facebook operate like closed silos compared to SMS or email that work seamlessly across a multtude of service providers.
This provision, when introduced for dominant intermediaries, would spur competition and mitigate the data concentration problem. Fragmenting user data inhibits the creation of such big data that can be exploited for questionable political purposes.
la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori. La portabilità di un profilo in altri servizi, ad esempio WA o FB, richiederebbe una standardizzazione della struttura dei dati di interesse. Le strutture dei vari social network sono probabilmente semplici, ma immagino che ognuno cerchi di aggiungere qualcosa. La portabilità piena si potrebbe ottenere solo se tutti i fornitori offrissero la stessa “capacità espressiva”. Ma ciò è possibile? Saluti,
-Paolo Atzeni
Il giorno 15 apr 2018, alle ore 15:54, Stefano Quintarelli <stefano@quintarelli.it <mailto:stefano@quintarelli.it>> ha scritto:
sul tema CA-FB, mi permetto di condividere questo mio articolo che e' stato poi ripreso da piu' parti..
ciao, s. <2018.03.25 Cambridge Analytica.docx>_______________________________________________ nexa mailing list nexa@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On 2018-04-15 18:11, Paolo Atzeni wrote:
la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori.
e questo è esattamente uno dei motivi, oltre all'inevitabilità di architetture veramente basate sugli **individui**,per cui da anni sostengo che sostuire "piattaforme" con ALTRE piattaforme è un'idea sballata in partenza, e che qualsiasi soluzione realistica non può non avere come prima, anche se certo non definitiva fase, il passaggio per "nuvole" **personali** cioè siti/server individuali, ognuno con un suo normale nome di dominio tipo nome-cognome.com. Vedi i primi tre punti di questi requisiti, che mi permetto di RIsegnalare solo perché vedo certi punti inevitabili tornare ripetutamente a galla, ma solo accompagnati a soluzioni tipo SOLID, che per quanto promettente mi pare troppo radicale per essere, realisticamente, il **prossimo** passo senza alcun passaggio intermedio: http://per-cloud.com/percloud-proposal/#requirements NB: al 90% dei commenti su queste mie affermazioni ho molto probabilmente risposto su questa lista un mese fa, vedi questo e altri thread: http://server-nexa.polito.it/pipermail/nexa/2018-March/013048.html quindi riparliamone pure quanto volete, ma almeno ripartendo da lì. -- http://mfioretti.com
la piattaforma personale e' un caso degenere (in senso matematico) della molteplicita' di piattaforme per cui l'interoperabilita' e la portabilità sono prerequisiti. ciao, s. On 16/04/2018 08:47, M. Fioretti wrote:
On 2018-04-15 18:11, Paolo Atzeni wrote:
la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori.
e questo è esattamente uno dei motivi, oltre all'inevitabilità di architetture veramente basate sugli **individui**,per cui da anni sostengo che sostuire "piattaforme" con ALTRE piattaforme è un'idea sballata in partenza, e che qualsiasi soluzione realistica non può non avere come prima, anche se certo non definitiva fase, il passaggio per "nuvole" **personali** cioè siti/server individuali, ognuno con un suo normale nome di dominio tipo nome-cognome.com.
Vedi i primi tre punti di questi requisiti, che mi permetto di RIsegnalare solo perché vedo certi punti inevitabili tornare ripetutamente a galla, ma solo accompagnati a soluzioni tipo SOLID, che per quanto promettente mi pare troppo radicale per essere, realisticamente, il **prossimo** passo senza alcun passaggio intermedio:
http://per-cloud.com/percloud-proposal/#requirements
NB: al 90% dei commenti su queste mie affermazioni ho molto probabilmente risposto su questa lista un mese fa, vedi questo e altri thread:
http://server-nexa.polito.it/pipermail/nexa/2018-March/013048.html
quindi riparliamone pure quanto volete, ma almeno ripartendo da lì.
On 2018-04-16 10:57, Stefano Quintarelli wrote:
la piattaforma personale e' un caso degenere (in senso matematico) della molteplicita' di piattaforme per cui l'interoperabilita' e la portabilità sono prerequisiti.
non sono sicuro che sia così, anche in senso matematico: a me la nuvola o piattaforma personale pare l'unico modo possibile per garantire portabilità vera, almeno nel medio/lungo periodo, e le degenerazioni sono il resto. Se TUTTO quello che sei, fai, scrivi... non ha una etichetta sua permanente e parzialmente comune a tutto quello che è tuo, come fai a "portarti" appresso tutti quei dati quando cambi piattaforma di supporto? Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo? Quando dico che bisogna passare da e.g. marco@gmail + twitter/marco + facebook/marco .. a email@marco / blogging@marco / blogging@marco, con "marco" che è un normale dominio web, di questo parlo. Come fanno ad esserci vere portabilità, espandibilità e interoperabilità a lungo termine se non organizzi le cose in quel modo? Marco
On 16/04/2018 08:47, M. Fioretti wrote:
On 2018-04-15 18:11, Paolo Atzeni wrote:
la portabilità del “profilo telefonico" è facilitata dalla semplicità del profilo stesso, che è costituito dal solo numero, ed è quindi uguale per tutti i fornitori.
e questo è esattamente uno dei motivi, oltre all'inevitabilità di architetture veramente basate sugli **individui**,per cui da anni sostengo che sostuire "piattaforme" con ALTRE piattaforme è un'idea sballata in partenza, e che qualsiasi soluzione realistica non può non avere come prima, anche se certo non definitiva fase, il passaggio per "nuvole" **personali** cioè siti/server individuali, ognuno con un suo normale nome di dominio tipo nome-cognome.com.
Vedi i primi tre punti di questi requisiti, che mi permetto di RIsegnalare solo perché vedo certi punti inevitabili tornare ripetutamente a galla, ma solo accompagnati a soluzioni tipo SOLID, che per quanto promettente mi pare troppo radicale per essere, realisticamente, il **prossimo** passo senza alcun passaggio intermedio:
http://per-cloud.com/percloud-proposal/#requirements
NB: al 90% dei commenti su queste mie affermazioni ho molto probabilmente risposto su questa lista un mese fa, vedi questo e altri thread:
http://server-nexa.polito.it/pipermail/nexa/2018-March/013048.html
quindi riparliamone pure quanto volete, ma almeno ripartendo da lì.
in IPFS e' un hash del dato On 16/04/2018 11:09, M. Fioretti wrote:
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo?
On 2018-04-16 11:13, Stefano Quintarelli wrote:
in IPFS e' un hash del dato
l'avevo letto. Devo ancora capire se e come è compatibile "all'indietro", col resto del web attuale. Che è un altro motivo per cui io propondo i nomi dominio personali, dicendo io per primo che sono una soluzione transitoria. Marco
On 16/04/2018 11:09, M. Fioretti wrote:
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo?
i dominii sono limitati ipfs gestisce i nomi mnemonici con IPNS On 16/04/2018 11:21, M. Fioretti wrote:
On 2018-04-16 11:13, Stefano Quintarelli wrote:
in IPFS e' un hash del dato
l'avevo letto. Devo ancora capire se e come è compatibile "all'indietro", col resto del web attuale. Che è un altro motivo per cui io propondo i nomi dominio personali, dicendo io per primo che sono una soluzione transitoria.
Marco
On 16/04/2018 11:09, M. Fioretti wrote:
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo?
On 2018-04-16 11:25, Stefano Quintarelli wrote:
i dominii sono limitati
perché, come, quanto, esattamente? Questa è un'obiezione che era già uscita fuori a marzo, ma è rimasta appesa.
ipfs gestisce i nomi mnemonici con IPNS
On 16/04/2018 11:21, M. Fioretti wrote:
On 2018-04-16 11:13, Stefano Quintarelli wrote:
in IPFS e' un hash del dato
l'avevo letto. Devo ancora capire se e come è compatibile "all'indietro", col resto del web attuale. Che è un altro motivo per cui io propondo i nomi dominio personali, dicendo io per primo che sono una soluzione transitoria.
Marco
On 16/04/2018 11:09, M. Fioretti wrote:
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo?
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
On 2018-04-16 13:11, M. Fioretti wrote:
On 2018-04-16 11:25, Stefano Quintarelli wrote:
i dominii sono limitati
perché, come, quanto, esattamente? Questa è un'obiezione che era già uscita fuori a marzo, ma è rimasta appesa.
mi riferisco alla parte "The maximum number of characters you can have in a website address..." di questo messaggio: http://server-nexa.polito.it/pipermail/nexa/2018-March/013064.html ovvero, magari sbaglio, non lo escludo affatto, ma ho chiesto un mese fa dov'era l'errore e nessuno ha risposto. Marco
ipfs gestisce i nomi mnemonici con IPNS
On 16/04/2018 11:21, M. Fioretti wrote:
On 2018-04-16 11:13, Stefano Quintarelli wrote:
in IPFS e' un hash del dato
l'avevo letto. Devo ancora capire se e come è compatibile "all'indietro", col resto del web attuale. Che è un altro motivo per cui io propondo i nomi dominio personali, dicendo io per primo che sono una soluzione transitoria.
Marco
On 16/04/2018 11:09, M. Fioretti wrote:
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo?
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Il 16 aprile 2018 13:18, M. Fioretti <mfioretti@nexaima.net> ha scritto:
On 2018-04-16 13:11, M. Fioretti wrote:
On 2018-04-16 11:25, Stefano Quintarelli wrote:
i dominii sono limitati
perché, come, quanto, esattamente? Questa è un'obiezione che era già uscita fuori a marzo, ma è rimasta appesa.
mi riferisco alla parte "The maximum number of characters you can have in a website address..." di questo messaggio:
http://server-nexa.polito.it/pipermail/nexa/2018-March/013064.html
Scusa a marzo non avevo colto la domanda. Fai probabilmente riferimento al RFC 1034: https://tools.ietf.org/html/rfc1034 Il dominio consiste in una sequenza di nodi separati da un punto: "www.tesio.it." rappresenta 4 nodi ovvero, da destra a sinistra, "" (ovvero la stringa vuota, riservata per il nodo radice), "it", "tesio" e "www". Ciascuno di questi nodi viene rappresentato da una sequenza alfanumerica la cui lunghezza non può superare i 63 byte, mentre nel complesso, "to simplify implementations", il dominio non puo superare i 255 byte (vedi sezione 3.1 del RFC). Giacomo
On 2018-04-16 22:12, Giacomo Tesio wrote:
Il 16 aprile 2018 13:18, M. Fioretti <mfioretti@nexaima.net> ha scritto:
On 2018-04-16 13:11, M. Fioretti wrote:
On 2018-04-16 11:25, Stefano Quintarelli wrote:
i dominii sono limitati
perché, come, quanto, esattamente? Questa è un'obiezione che era già uscita fuori a marzo, ma è rimasta appesa.
mi riferisco alla parte "The maximum number of characters you can have in a website address..." di questo messaggio:
http://server-nexa.polito.it/pipermail/nexa/2018-March/013064.html
Scusa a marzo non avevo colto la domanda.
Fai probabilmente riferimento al RFC 1034: https://tools.ietf.org/html/rfc1034
Il dominio consiste in una sequenza di nodi separati da un punto...Ciascuno di questi nodi viene rappresentato da una sequenza alfanumerica la cui lunghezza non può superare i 63 byte, mentre nel complesso, "to simplify implementations", il dominio non puo superare i 255 byte (vedi sezione 3.1 del RFC).
appunto: o mi sfugge qualcosa, o non ci siamo proprio capiti da qualche parte a monte. Se un nodo può arrivare a 63 byte, significa che può avere ~2 seguito da una ventina di zeri di combinazioni diverse. Fossero pure la metà quelle effettivamente usabili, perché non potrebbero bastare a fare nomi di dominio unici, combinandoli con vari TLD, tipo marcofioretti-123456789abcdef.com marcofioretti-123456789abcdef.net marcofioretti-123456789abcdef.org ??? Marco -- http://mfioretti.com
Il 16/04/2018 11:09, M. Fioretti ha scritto:
On 2018-04-16 10:57, Stefano Quintarelli wrote:
la piattaforma personale e' un caso degenere (in senso matematico) della molteplicita' di piattaforme per cui l'interoperabilita' e la portabilità sono prerequisiti.
non sono sicuro che sia così, anche in senso matematico: a me la nuvola o piattaforma personale pare l'unico modo possibile per garantire portabilità vera, almeno nel medio/lungo periodo, e le degenerazioni sono il resto.
Se TUTTO quello che sei, fai, scrivi... non ha una etichetta sua permanente e parzialmente comune a tutto quello che è tuo, come fai a "portarti" appresso tutti quei dati quando cambi piattaforma di supporto?
Ma come fai ad avere una tale etichetta permanente, se la parte comune di quell'etichetta non è composta tutta e solo da **te**, dal tuo nome o pseudonimo? Quando dico che bisogna passare da e.g. marco@gmail + twitter/marco + facebook/marco .. a email@marco / blogging@marco / blogging@marco, con "marco" che è un normale dominio web, di questo parlo. Come fanno ad esserci vere portabilità, espandibilità e interoperabilità a lungo termine se non organizzi le cose in quel modo?
se puo aiutare, in Tor c'è un sistema dei nomi molto personale (privato) e trasportabile (anche stampati su carta) tanto quanto una coppia di chiavi pub/priv permettendo quindi di fare questi giochetti che mi ricordano tanto le ricerche al PARC sui Fluid Documents e Fluid Data che seguono automaticamente il fruitore nella sua prossimita. C'è ancora qualche problema di usbilita sulla pronunciabilita di questi nomi che peggiorano al miglioramento della sicurezza ma è gia un discreto successo Anzi, rispetto agli hash, se si "mina" qualche parola si rischia addirittura di produrre qualcosa di piu guardabile tipo: facebookcorewwwi.onion l'incredibile famigerato appunto saluti Luca
Il giorno 16 aprile 2018 10:57, Stefano Quintarelli <stefano@quintarelli.it> ha scritto:
la piattaforma personale e' un caso degenere (in senso matematico) della molteplicita' di piattaforme per cui l'interoperabilita' e la portabilità sono prerequisiti.
Detta in questo modo, risulta evidente una straordinaria opportunità di business. Che ne dite, rifondiamo la Olivetti? Giacomo
participants (6)
-
Diego Giorio -
Giacomo Tesio -
Luca Cappelletti -
M. Fioretti -
Paolo Atzeni -
Stefano Quintarelli