RIAA Wants To Start Peeking Into Files You Store In The Cloud(techdirt.com)
techdirt.com
RIAA Wants To Start Peeking Into Files You Store In The Cloud
http://www.techdirt.com/articles/20110520/03411314352/riaa-wants-to-start-peeking-into-files-you-store-cloud.shtml
9 comments
100% agree. Encrypt. Not because of what you are afraid today, but for what might happen in the future. You can't even begin to imagine the ways our privacy will be violated tomorrow.
All file locker services should offer a check-box or something by default, before you upload your files, to encrypt them with your own key. That should cover a lot more people than it would if everyone had to do everything by themselves.
Let's take Dropbox for example.
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
With that said, they could offer that "by default" to premium users who already pay for the service to simplify their lives and keep their more profitable customers happy.
What are everyone's views on that, from Dropbox's perspective?
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
With that said, they could offer that "by default" to premium users who already pay for the service to simplify their lives and keep their more profitable customers happy.
What are everyone's views on that, from Dropbox's perspective?
They save a lot of costs by deduplicating copies of files, and it makes file renames/moves/shares really easy for them. Therefore, they wouldn't have the incentive to destroy that advantage: That's one of the major scale advantages they get for covering so many users.
I posted this elsewhere in the thread: That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work. See here for one idea: http://news.ycombinator.com/item?id=2461713
Please also see the further discussions. Crypto gives us powerful tools to mitigate several attacks with minimal compromise on functionality. Unfortunately there are legal ways that are more powerful.
I posted this elsewhere in the thread: That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work. See here for one idea: http://news.ycombinator.com/item?id=2461713
Please also see the further discussions. Crypto gives us powerful tools to mitigate several attacks with minimal compromise on functionality. Unfortunately there are legal ways that are more powerful.
That idea doesn't work. It doesn't stop a third-party from seeing who has copies of a file.
Call me paranoid but I would not even consider that as an alternative to doing the encryption on my own.
This is why I've left some sort of server-side encryption out of the storage product I'm designing. I mean, I'm just using webdav, so it should be easy enough for you to bring your own client with encryption support; something you already trust.
The main benefit of encryption in these situations is that you have to trust your provider a whole lot less... If I get compromised through a OS hole? if you are encrypted, you are covered. If I get compromised through a physical attack, governmental or otherwise? if you are encrypted, you are covered.
If I do the encryption for you, I give away a bunch of those benefits. If I'm completely compromised, you should assume that any keys I have access to are also compromised.
I think giving up "deduplication" is completely reasonable in this regard; the competitive landscape right now is that "cloud backup" costs about 10x what I think it ought to cost for backups (In part due to the fact that many 'cloud backup' services are built to be fast enough to serve webpages; If you let me have 'backup system' level performance, I can do it a whole lot cheaper, but also in part due to the fact that s3 sets the price here, and S3 is still charging "pretty good for 2007" prices.)
The main benefit of encryption in these situations is that you have to trust your provider a whole lot less... If I get compromised through a OS hole? if you are encrypted, you are covered. If I get compromised through a physical attack, governmental or otherwise? if you are encrypted, you are covered.
If I do the encryption for you, I give away a bunch of those benefits. If I'm completely compromised, you should assume that any keys I have access to are also compromised.
I think giving up "deduplication" is completely reasonable in this regard; the competitive landscape right now is that "cloud backup" costs about 10x what I think it ought to cost for backups (In part due to the fact that many 'cloud backup' services are built to be fast enough to serve webpages; If you let me have 'backup system' level performance, I can do it a whole lot cheaper, but also in part due to the fact that s3 sets the price here, and S3 is still charging "pretty good for 2007" prices.)
I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
A really cool application would be one that allowed you to contact your home computer from the web and use that to decrypt stuff transparently on its way to your final destination, then you could still offer web-accessible decrypted files any time the user's main computer was powered on.
A really cool application would be one that allowed you to contact your home computer from the web and use that to decrypt stuff transparently on its way to your final destination, then you could still offer web-accessible decrypted files any time the user's main computer was powered on.
>I think the suggestion was that a client integrate encryption functionality locally, generating and using a key that exists only on a user's computer (or, alternatively, is backed up with AES (or similar) using a passphrase the service doesn't know). You don't have to have access to the key.
yeah. That's also what I am suggesting. but you don't need the provider's help to do that. it's easy enough to encrypt a davfs mount locally on your own box; the provider just needs to support some standard (like webdav.) Then it's up to the user to figure out what client they trust to encrypt the data before it's uploaded.
My point is that if the providers control the encryption (e.g. by providing a proprietary client that has access to the key) you have a lot less protection than if you do the encryption independent of your provider.
yeah. That's also what I am suggesting. but you don't need the provider's help to do that. it's easy enough to encrypt a davfs mount locally on your own box; the provider just needs to support some standard (like webdav.) Then it's up to the user to figure out what client they trust to encrypt the data before it's uploaded.
My point is that if the providers control the encryption (e.g. by providing a proprietary client that has access to the key) you have a lot less protection than if you do the encryption independent of your provider.
Why is the RIAA special? I produce copyrighted material all the time.
I demand the right to start looking at everyone's cloud files too.
I demand the right to start looking at everyone's cloud files too.
For a specific example.
http://news.cnet.com/8301-13578_3-10133425-38.html
Because they've spent 10s of millions $ on bribing politicians ("lobbing") and you haven't.
I'm sure if the MAFIAA thought they could get away with it they'd lobby for mandatory snooping software on everyone's PC so they could check for illegal copies.
Because, y'know, human rights and the rule of law are far less important than preserving the music industry's business model for a few more years.
Because, y'know, human rights and the rule of law are far less important than preserving the music industry's business model for a few more years.
This idea is actually not as crazy as it may seem.
Copyright lobby is usually just one step behind the Chinese policies of restricting access to the illegal content, with the only difference in definition of illegal.
Chinese have developed such tool, [1], and were planning to install it on every new computer sold in China. But later scaled down it's use.
[1] http://en.wikipedia.org/wiki/Green_Dam_Youth_Escort
[1] http://en.wikipedia.org/wiki/Green_Dam_Youth_Escort
Better yet, get rid of general purpose computing for civilians altogether. That's one reason I support Android; if most people end up on locked down platforms like iOS or WP7, it becomes much easier to pass and enforce draconian laws. Remember the CBDTPA (http://en.wikipedia.org/wiki/Consumer_Broadband_and_Digital_...)? It would actually be feasible if everyone were using iPads.
Well, if you were one of the major owners or CEOs of a recording company what would you value more - your own profits or the human rights of the unwashed masses?
Why don't the cloud storage service providers encrypt/store all user content in such a way that it can only be read by the user? I doubt there are any ethical benefits in storing the data in such a way that they (the service providers) can read it. Even if there is I doubt that users would agree to such usage.
I think some storage providers might not be comfortable with the situation where they'd have to tell a paying customer that they can't help them at all when the customer loses the key - they choose simplicity as a feature over appealing to the security-conscious.
As for Dropbox, they need to be able to read the files to serve it to you from their website.
As for Dropbox, they need to be able to read the files to serve it to you from their website.
Can't they implement client side encryption? A javascript based encryption mechanism could be interesting.
And completely unusable for the average consumer (needing them to keep track of their key, and somehow secure their key, and somehow pass their key to every browser they use.)
Because then they can't store only one copy of each duplicate file, skip uploading duplicate files, work with file hashes knowing that the same file will have the same hash, and less pleasantly, they can't do analytics, advertising and recommendations on the types and quantities of stored files.
That's not true. As is, in a lot of crypto problems, there are powerful workarounds that require a lot of work.
See here for one idea: http://news.ycombinator.com/item?id=2461713
Unfortunately, this starts to become a cat-and-mouse game.
Unfortunately, this starts to become a cat-and-mouse game.
I won't pretend I can follow all the implications of that scheme, but it looks like all files are encrypted with an unchangeable hash of the file as the key?
So that all the RIAA has to do is provide a sample mp3 and then DropBox can see who has AES(F, H(F)) stored. Only the files with user generated unknown content can remain mysterious to DropBox, widely used files cannot.
And since you use aes(f, h(f)) you can't change the encryption key on any particular file.
And since the client software needs to use the local DB and since they have the list of files you uploaded, they have most of the plaintext known if they want to try to decrypt the DB maliciously.
But if they do want to, they can leak the password you type in to themselves anyway.
Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?
ZFS does encryption and deduor too, so yes it is possible, but secure trustable ecrypted DropBox where they also do the encryption part?
So that all the RIAA has to do is provide a sample mp3 and then DropBox can see who has AES(F, H(F)) stored. Only the files with user generated unknown content can remain mysterious to DropBox, widely used files cannot.
And since you use aes(f, h(f)) you can't change the encryption key on any particular file.
And since the client software needs to use the local DB and since they have the list of files you uploaded, they have most of the plaintext known if they want to try to decrypt the DB maliciously.
But if they do want to, they can leak the password you type in to themselves anyway.
Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?
ZFS does encryption and deduor too, so yes it is possible, but secure trustable ecrypted DropBox where they also do the encryption part?
So that all the RIAA has to do is provide a sample mp3 and then DropBox can see who has AES(F, H(F)) stored. Only the files with user generated unknown content can remain mysterious to DropBox, widely used files cannot.
No, Dropbox does not know who has what hash. The list of files you have is encrypted by your own key. I realize the scheme is not fixed and there are ideas, since no one exactly published a paper on this.
Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?
Yes, unfortunately there is always a trade-off between security and usability. Things like encrypted volumes are not very friendly and intuitive but provide security. Similarly, lots of neat tricks that Dropbox uses might become void. But at least dedup that was one of their strong features still works.
No, Dropbox does not know who has what hash. The list of files you have is encrypted by your own key. I realize the scheme is not fixed and there are ideas, since no one exactly published a paper on this.
Also, how would this scheme interact with DropBox's differential upload and revision tracking feature?
Yes, unfortunately there is always a trade-off between security and usability. Things like encrypted volumes are not very friendly and intuitive but provide security. Similarly, lots of neat tricks that Dropbox uses might become void. But at least dedup that was one of their strong features still works.
No, Dropbox does not know who has what hash.
They don't need to - you upload AES(F, H(F)), so if the RIAA give DropBox a sample "Beyonce: Pop Song #7.mp3" file, DropBox can do H(F), then do AES(F, H(F)), then say "do we have this? Yes. Who uploaded it? Accounts adambloggs1, beatricebloggs2, carltonbloggs3, delaneybloggs4".
They couldn't trawl for the RIAA by filename only, or by file hash only, but they could trawl from an example file.
The safe stuff would be your accounts - since there is nobody to provide an example file for them to hash/encrypt. (Except it wouldn't be totally safe since they could weaken the local database encryption or pass themselves the key to it, and you'd never know).
We can agree that they might be able to do it and keep DeDupe, though.
They don't need to - you upload AES(F, H(F)), so if the RIAA give DropBox a sample "Beyonce: Pop Song #7.mp3" file, DropBox can do H(F), then do AES(F, H(F)), then say "do we have this? Yes. Who uploaded it? Accounts adambloggs1, beatricebloggs2, carltonbloggs3, delaneybloggs4".
They couldn't trawl for the RIAA by filename only, or by file hash only, but they could trawl from an example file.
The safe stuff would be your accounts - since there is nobody to provide an example file for them to hash/encrypt. (Except it wouldn't be totally safe since they could weaken the local database encryption or pass themselves the key to it, and you'd never know).
We can agree that they might be able to do it and keep DeDupe, though.
They don't need to - you upload AES(F, H(F)), so if the RIAA give DropBox a sample "Beyonce: Pop Song #7.mp3" file, DropBox can do H(F), then do AES(F, H(F)), then say "do we have this? Yes. Who uploaded it? Accounts adambloggs1, beatricebloggs2, carltonbloggs3, delaneybloggs4".
I've worked it out and if I'm not incorrect the table that adambloggs1 that has (hash2(file1), hash2(file2), ..., hash2(file10)) which are adambloggs1 10 files can be stored remotely encrypted by the client's key (derived from his password in a secure way that Dropbox cannot). What this means is that whenever the client has to send across hashes to dropbox to sync across files, he gets his encrypted database from dropbox, decrypts it remotely and proceeds to give dropbox relevant hash information.
There are 2 problems definitely that can compromise the system:
1. Dropbox decides to store your requests because of a subpoena (effectively they're logging you---which is not required for functionality). Then the encryption is useless.
2. If dropbox does not log you, then can collude and catch you in the act (i.e., an online attack)
So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.
This system makes sure that RIAA cannot trawl by filename or hash only unless dropbox stores logs or some activity is done online.
I've worked it out and if I'm not incorrect the table that adambloggs1 that has (hash2(file1), hash2(file2), ..., hash2(file10)) which are adambloggs1 10 files can be stored remotely encrypted by the client's key (derived from his password in a secure way that Dropbox cannot). What this means is that whenever the client has to send across hashes to dropbox to sync across files, he gets his encrypted database from dropbox, decrypts it remotely and proceeds to give dropbox relevant hash information.
There are 2 problems definitely that can compromise the system:
1. Dropbox decides to store your requests because of a subpoena (effectively they're logging you---which is not required for functionality). Then the encryption is useless.
2. If dropbox does not log you, then can collude and catch you in the act (i.e., an online attack)
So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.
This system makes sure that RIAA cannot trawl by filename or hash only unless dropbox stores logs or some activity is done online.
I was assuming dropbox would do reference counting so they could delete data that nobody is using, and account tracking so they can put storage limits on your account and charge you for using more space.
But they could make a system which didn't do those things and then they would be able to do as you discuss.
Now the limit to what they could do for the RIAA is identify if they have a file stored and delete it or block it from being stored, but only with an example whole file - not by filename or hash.
So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.
Maybe. It depends what you are guarding against. If you fundamentally do not trust dropbox, then it is no better than nothing. If you do want to keep copied music files then it is pretty much no better than nothing. If you want convenience and features it is worse than nothing. If you want a basic security that stops dropbox easily trawling your most personal files, it is better than nothing.
But they could make a system which didn't do those things and then they would be able to do as you discuss.
Now the limit to what they could do for the RIAA is identify if they have a file stored and delete it or block it from being stored, but only with an example whole file - not by filename or hash.
So the solution is ugly, and reasonable, but has some weaknesses. Yet, it is better than nothing.
Maybe. It depends what you are guarding against. If you fundamentally do not trust dropbox, then it is no better than nothing. If you do want to keep copied music files then it is pretty much no better than nothing. If you want convenience and features it is worse than nothing. If you want a basic security that stops dropbox easily trawling your most personal files, it is better than nothing.
I was assuming dropbox would do reference counting so they could delete data that nobody is using, and account tracking so they can put storage limits on your account and charge you for using more space.
Definitely. There are a few problems that can "de-anonymize" users. I don't claim that the outline presented would be very robust.
Maybe. It depends what you are guarding against.
I agree, that requires more qualification. I think in the context of subpoenas or trawling, there are some definite advantages.
Definitely. There are a few problems that can "de-anonymize" users. I don't claim that the outline presented would be very robust.
Maybe. It depends what you are guarding against.
I agree, that requires more qualification. I think in the context of subpoenas or trawling, there are some definite advantages.
There are cloud storage providers doing this. See for instance the tarsnap.com solution. Data is stored but with a key in your end. In other words, it is cloud storage done right.
The RIAA really has become a disturbing entity.
The politicians who are willing to accept and act on their greased palm offers are the real problem. In a normal, non-corrupt system, the RIAA would never come anywhere near receiving such powers, anymore than Jim McJones down the street.
The RIAA is about to discover client-side encryption by default :)
I welcome thee, dear MAFIAA, to bring out your inspective forces upon the encrypted bits of my tarsnap.com archives.
I hereby promise they positively do contain copyrighted materials indeed, and I thus encourage your troops to spend considerable time trying to decipher whatever it is that I've stored in these clouds of the 2010's internet.
I hereby promise they positively do contain copyrighted materials indeed, and I thus encourage your troops to spend considerable time trying to decipher whatever it is that I've stored in these clouds of the 2010's internet.
I guess it is time to start encrypting the files I got in the cloud. None of which are copyright'ed or especially secret but better safe than sorry.
If you're uploading anything remotely important to a third-party service, you should encrypt all of it beforehand. As we see time and time again, it can be really surprising how easy it is for an insider, a random script kiddie, or in this case, a company with a posse of anxious lawyers to grab your data. You need to encrypt that data before it ever leaves your disk for persistent storage on someone else's infrastructure. Encrypt encrypt encrypt.