Il 26/04/2011 16:47, Stefano Maffulli ha scritto:
2011/4/26 Paolo Brini <paolo.brini@iridiumpg.com>
Richieste di takedown contro progetti (FL)OSS: Dropbox contro Dropship.

da quello che ho letto nell'articolo che hai inviato, la richiesta di takedown è stata inviata per errore e il codice di Dropship sia ancora su github. Ti risulta?

Salve,

certamente, tutti ammettono l'errore DOPO aver inviato la richiesta e averci "provato", come in questo caso. E infatti la richiesta ha provocato la rimozione di Dropship in quasi tutti i mirror. In generale la speranza di chi richiede un takedown è che esso venga soddisfatto indipendentemente dalla legittimità della richiesta stessa perché un hosting provider magari non ha tempo, voglia e competenza per mettersi a difendere le opere di terzi...

Non credo che Ferdowski verrà processato per spergiuro: come è tipico in questi casi si sostiene che la richiesta è partita "in automatico per errore" e non è stata approvata da alcun essere umano... vedi anche update dell'articolo di DeFelippi già linkato.

Credo questa notizia sia da collegare alla pubblicazione di questo articolo su una debolezza di Dropbox:

http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/

if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface.

Questo credo spieghi il nervosismo dei manager di DropBox.

L'articolo è molto interessante! Però credo che la sicurezza di DropBox possa essere migliorata correggendo le vulnerabilità piuttosto che tentando di mantenere segreto un protocollo (la più becera "security through obscurity") ed inviando richieste di takedown a casaccio che a loro volta provocano un effetto Streisand "devastante". :) Anche perché la "trivialità" dell'attacco citata nell'articolo non dipende dalla disponibilità di DropShip...

Ciao,
Paolo