I processi effettivi non sono noti pubblicamente, tuttavia mantengono un blog tecnico ufficiale che fornisce alcune informazioni sugli interni di Dropbox. Ad esempio, il loro post su Streaming File Synchronization (luglio 2014) fornisce una panoramica di alto livello del "Dropbox File System" che determina la gestione di tutti i dati dell'utente in modo estremamente efficiente e affidabile.
File System
Il post spiega molto bene il processo di caricamento e confermano che i file sono frammentati in meno blocchi di lunghezza < = 4 MB il più possibile da archiviare in tale modulo nel loro archivio di blocchi. Sono progressivamente sottoposti a hash (SHA-256) mentre sono isolati e gli hash vengono utilizzati per legare i blocchi nel block store di Dropbox (blockserver). Le associazioni tra gli hash sono persistenti nel meta store (metaserver) e sembrano un po 'come elenchi di directory.
Gli hash fungono da metadati per i blocchi di file (tutta la lunghezza < = 4 MB) che viene utilizzato da Dropbox per determinare se è necessario o meno che il client trasmetta quel blocco come una nuova aggiunta ai propri server. Se il client deve caricare o meno qualsiasi blocco sui server di blocco di Dropbox verrà indicato in una risposta dai loro metaserver quando il client specifica il blocco di un determinato file.
Caricamento dati
Per tutti gli effetti di questa risposta, puoi semplicemente considerare "Server" come un'entità che funge sia da metaserver che da server di blocco; entrambi sono sotto il controllo di Dropbox comunque. Ecco come potrebbe apparire un caricamento tra un server e qualche cliente:
Client: SET "/video.avi" [h1, h2, h3, h4] ---> Server # cmd: try set record
Server: GET [h1, h3, h4] --------------------> Client # err: need h1/h3/h4; h2 exists
Client: ADD [h1, h3, h4], [b1, b3, b4] ------> Server # cmd: add blocks h1/h3/h4
Server: ACK ---------------------------------> Client # ack: blocks stored
Client: SET "/video.avi" [h1, h3, h4] -------> Server # cmd: retry set record
Server: ACK ---------------------------------> Client # ack: record defined
Semplificati / modificati molto, omessi dettagli non pertinenti alla domanda. Intenzionale. Proto forma reale sul blog.
Rilevamento di contenuti
I blocchi di dati e i corrispondenti valori meta / hash sono tenuti in negozi separati l'uno dall'altro. Se i valori hash sono noti in anticipo (ad esempio, dato un enorme database di file con ingombro DMCA e relativi blocchi costitutivi) e stanno solo controllando le voci metastore, suppongo che possano eseguire il rilevamento automatico senza guardare i tuoi file. Sarebbe un tratto abbastanza osceno della lingua inglese, se è quello che intendeva.
Non penso sia improbabile che una parte considerevole dei blocchi di lunghezza massima (in questo caso blocchi di 4 MB) di dati originali e attivamente protetti da copyright rimarrebbero in una copia alterata del materiale protetto, anche se vengono apportate modifiche a alcune porzioni del file fino al punto di oscurare la sua identità visiva e / o udibile dal punto di osservazione di un osservatore umano.
Credo che Dropbox possa effettivamente gestire i video in modo diverso (lo dico sul loro blog, penso), ma non sono sicuro che ricodificheranno i file multimediali in un tipo standard quando vengono riprodotti nel browser (in tal caso, supponiamo che essere un'altra apertura per vedere casualmente cose che non dovrebbero guardare).