Slashdot Mirror
Dropbox's New Policy of Scanning Files For DMCA Issues
Advocatus Diaboli (1627651) writes "This weekend a small corner of the Internet exploded with concern that Dropbox was going too far, actually scanning users' private and directly peer-shared files for potential copyright issues. What's actually going on is a little more complicated than that, but shows that sharing a file on Dropbox isn't always the same as sharing that file directly from your hard drive over something like e-mail or instant messenger. The whole kerfuffle started yesterday evening, when one Darrell Whitelaw tweeted a picture of an error he received when trying to share a link to a Dropbox file with a friend via IM. The Dropbox web page warned him and his friend that 'certain files in this folder can't be shared due to a takedown request in accordance with the DMCA.'"
Its been nice while it lasted, now on to other services!
If you are determined to use drop box, use an open source software as 7zip that will encrypt and zip. Otherwise, stop using drop box and move on to something else. One of the consequences of using the magical cloud is that your are bound to somebody else's rules for how they manage your data. Also note that those rules are subject to change at any time, and you don't have any say in those changes (I guess the only option is to speak with your wallet and move to greener pastures).
But this isn't new, its been going on since Dropbox implemented their DCMA violation checking system a few years ago, and you can see *why* they are doing it.
Lets clarify a few things for those that aren't going to RTFA - this isn't for private shared folders, or for folders within your own Dropbox. This is for when you create *public* links, by either using the "Shared Links" facility or when you create a public link from the old style Public folder.
Thats it. The files Dropbox is including in these scans are *publicly linked* to - and they are fair game if Dropbox wants to stay ahead of the legal system on this front. Dropbox has no idea that you only intend to share it with yourself, or one other person, and there is no mechanism by which you can ensure that yourself anyway.
Yet again its forced outrage against basically something which is common sense - if the file has been taken down before, its going to be again, and the less man power Dropbox expends while handling DCMA requests the better for them as a company.
This whole issue can be summarized as:
1) User wants to ignore copyright law and share something they have no legal right to via a public service
2) Public service being used has no idea how many people will want to access the shared resource but they do know it is copyrighted as they auto match everything uploaded so they can avoid keeping to separate copies of identical files and save storage space and had a DMCA take down request for that same file previously.
3) Public service errs on the side of not getting their arse sued off by the various content owner conglomerates legal attack dogs and refuses to allow the file to be shared even though the person who uploaded it can still see it.
All in all seems pretty reasonable. Until copyright law is changed (like that is ever going to happen) dropbox have to follow it to the letter. I suppose they could have avoided the whole thing by storing more data and then not doing the duplicate file scan thing but even that is no guarantee it would prevent them from being sued to oblivion.
The only safe option for them that would also keep things private would be to use encryption keys that were only kept in the client. That way if you needed to share a particular folder you selected to store that under a different encryption key, and gave that key to other person / people who needed to access it.
The big problem with this is that it then becomes more awkward to provide web access to the files. People are comfortable remembering a username and password, they are not so comfortable remembering a bunch of encryption keys. If you store the encryption keys on a server at your end anywhere then you can access the files so you therefore get the legal responsibility to make sure your system is not being used to flout copyright law. The only legal way to run this sort of service and not be liable for it's misuse is to design it in such a way that you cannot see what is being stored at all.
I dont read
This is news, in the sense that Dropbox now actively crawls your files (DMCA still went about for publicly listed files anyway).
You obviously didn't bother to read the article.
The truth is that they always scan every single file uploaded to make sure they do not already have a copy of that file stored on their network. If they do, they throw your copy in the bin and just add an extra link to that stored copy in your account. That keeps their data usage lower as it means they never store duplicate copies of the same file, even if they are uploaded by completely different people.
So there is no crawling involved, this was done at the point of upload. They found that the same file had already been uploaded by someone else, shared, and that user got the shared copy of that file DMCA'd. Once a file has been DMCA'd in their system it seems it is blocked from being shared so only people uploaded that file also get to download it.
I dont read
Drop Box is nothing more than a gussied up repackaging of a SFTP or FTPS and a nice fancy ol' GUI.
The post office is nothing but a gussied up repackaging of walking to your friend's house and giving him the letter yourself.
The fax machine is nothing but a waffle iron with a phone attached!
No, it's slightly more than that.
You set up a server for SFTP or FTPS and download a nice, friendly little program called FileZilla.
...and then? Will Filezilla run on startup, settle itself inconspicuously in the systray without a running window you could accidentally close, connect to the SFTP server, download files automatically to local directories so they're instantly accessible, then monitor, sync and notify you of any changes? Will it allow you to dish out invitations to share directories and files direct from your desktop, and manage those permissions for an unlimited number of users and directories?
systemd is Roko's Basilisk.
This is what OwnCloud is made for.
I know not everyone is able to set up their OwnCloud server. There are places that will host it and set it up for you.
OwnCloud is great, with one exception: the slightest change to a file necessitates an upload of the entire file. Dropbox does delta syncs using a modified version of rsync, so it only uploads change portions of a file.
For typical files and fast connections, the lack of delta sync is tolerable, but when you're dealing with large files or slower transfer speeds it's an issue: if you, for example, you keep a large TrueCrypt container file in OwnCloud and make a change to a small file stored in the container, OwnCloud needs to reupload the entire container. Dropbox would just update the blocks that changed.
Until OwnCloud implements some sort of delta sync functionality it is considerably less practical than Dropbox.
> Viola!
I fail to understand what a stringed instrument, slightly larger than a violin, has to do with it...
Oolite: Elite-like game. For Mac, Linux and Windows
It's called AppOps. Was in Android hidden, then removed, but still ships in standard Cyanogenmod.
Change a character in the metadata fields, hash changes. If they're scanning the actual video portion of files, add a byte at the end. I don't think that would affect playback.
He wasn't making an analogy between how you find a hash collision and how you win the lottery -- only comparing the odds.
Dropbox uses SHA-256 hashes. I'm assuming this is what they use for this feature, since it's what they use internally for file identification and deduplication. They actually hash 2 MB file chunks, which means that any file more than 2 MB produces multiple hashes (one per chunk, naturally).
The "many chances of winning" you're referring to here is the birthday collision problem. A good, rough approximation is that for an N-bit hash, while the number of different hashes is 2^N, the number you can generate before risking a collision is about 2^(N/2). So, with SHA-256, we run no significant risk of collision until we've generated around 2^128 ~= 10^38 hashes.
The total amount of data stored worldwide is on the order of 1 ZB. That's room enough for about 10^15 2-MB chunks. Of course, some of our files might be smaller than this 2 MB chunk size, enabling us to be more efficient with storage. We might be able to get somewhere around 10^20 different files in there.
That's a strange and untenable use of all of the world's storage, and it still puts us about 18 orders of magnitude short of being able to risk a SHA-256 collision. If you had this giant set of a ton of different files, the probability of a collision existing is about 1 in 10^37.
So, short of a flaw in SHA-256, you can assume that a hash collision will never happen. We know of no such flaws. (If we do, it will almost certainly be the case that the collision only occurs because one of the two files was specifically manipulated to produce the collision.)
On the other hand, the odds of winning the lottery are rarely worse than 1 in 10^9.
I've used EncFS and BoxCryptor with Dropbox from day one and 'd do that with any cloud storage solution, no matter what they claim it is irrelevant. It is my data, by choice I'm retaining the responsibility for it's safety/security.
I'll continue to use Dropbox because I never trusted them and made sure I didn't have to.