AudioSAFE, New online backup concept Options

[Mangix]

will the data be encrypted server-side?

[spoon]

No

[birdie]

will the data be encrypted server-side?

It doesn't make sense if since they will employ deduplication. Of course, you can encrypt all users data using just one encryption key, but that doesn't make sense either.

[googlebot]

It doesn't make sense if since they will employ deduplication.

Deduplication and client-side encryption (without vendor access to the key) is not mutually exclusive. Wuala is the best example, it works beautifully. I'm a big fan of it.

[Ardax]

Deduplication and client-side encryption (without vendor access to the key) is not mutually exclusive. Wuala is the best example, it works beautifully. I'm a big fan of it.

For something particular to audio libraries, I'd think that deduplication across accounts would be extremely useful to the service provider. Especially if audio containers are cracked and audio data treated separately from embedded tags/artwork, with bonus points for taking offset matching into account.

Now, if you're saying that dedupe across accounts w/ client-side encryption is doable, then I'm curious how it'd be implemented.

[Garf]

Especially if audio containers are cracked and audio data treated separately from embedded tags/artwork, with bonus points for taking offset matching into account.

Matching offsets that are not multiples of the audio frame format is probably not going to work. But most rips are going to have a few common offsets, matching the most distributed drive manufacturers. And then there's the fact that AccurateRip and the Drive Offset DB belong to spoon...

[googlebot]

Now, if you're saying that dedupe across accounts w/ client-side encryption is doable, then I'm curious how it'd be implemented.

Wuala implements this by using (symmetric) encryption keys derived from content hashes. If you don't know the exact content, you don't know the key. If you do know the content, you can recreate the key, but only to decrypt what you already know.

It is possible for a server to deduplicate encrypted files of unknown content, when identity information is being preserved across encrypted entities, like described. The only security feature, which is sacrificed, is plausible deniability (but no additional plain-text-attack vectors, ect.). You cannot deny to be in possession of a file, if a prosecutor is in possession of an identical, decrypted copy. For pirates this might be an issue.

In this specific case, an audio-only service, not much could be gained by a decrypt-by-content-hash-scheme. Since many audio files are identical across individual collections, the information which songs you own exactly, could be recovered by a fair share. And there isn't really much more to hide than exactly that information in a music collection, when you use an audio-only backup service. Wuala is general purpose, and thus a different case. Your diary entries, your family pictures are unique files, and their content hashes cannot be correlated with known content. Thus they are perfectly private. Other files, like Windows installation images are identical across thousands of users and can be stored as a single copy. To achieve plausible deniability in a case like that, it is sufficient to zip a popular file and include a random text file or directory entry. To achieve plausible deniability for your music collection, it is sufficient to have custom tags or individual codec (padding, ect.) settings. For Wuala it is impossible to deduplicate them in this case. A service like spoon's could deduplicate anyway, of course, when it generates an individual track identifier on the client machine, but I wouldn't see any benefit of an additional encryption scheme in that a case.

This post has been edited by googlebot: Jul 25 2011, 19:56

[Ardax]

Wuala implements this by using (symmetric) encryption keys derived from content hashes. If you don't know the exact content, you don't know the key. If you do know the content, you can recreate the key, but only to decrypt what you already know.

Let me make sure I understand this process correctly:

• Client #1 generates hash key for a file's content
• Client #1 encrypts that file with that hash key
• Client #1 then generates a hash id of the encrypted blob
• Client #1 uploads encrypted blob and hash id to storage

• Client #2 comes along, and generates the same hash key, block, & hash id for the same content file
• Client #2 tells Service it wants to store encrypted blob & hash id
• Service tells Client #2 that given blob already exists by hash id
• Client #2 only needs to upload unique metadata (e.g. file path, ACLs, whatever)

Roughly correct?

To achieve plausible deniability for your music collection, it is sufficient to have custom tags or individual codec (padding, ect.) settings. For Wuala it is impossible to deduplicate them in this case. A service like spoon's could deduplicate anyway, of course, when it generates an individual track identifier on the client machine. I wouldn't see any benefit of an additional encryption scheme in a case like this.

It's entirely possible to crack file formats and deal with each internal blob of data independently for the purposes of deduplication, making it resistant to tag changes (or at least ensuring that any further clients would only need to upload the modified tags). Wuala could do this if it wanted to, and products like Druva inSync already do. inSync isn't a cloud-based backup product, just an example of a content-aware dedupe implementation.

This post has been edited by Ardax: Jul 25 2011, 20:04

[saratoga]

US acts differently, companies have to hand over whatever data they have when government asks for them (it's called patriot act).

Lol.

Citation needed.

EDIT:

Let's be less glib and just say that the Patriot Act, for all its many flaws, does not work like that.

https://secure.wikimedia.org/wikipedia/en/w...tems_under_FISA

I suspect thats not the clause you intended to link, since allowing judges to issue warrants to seize property suspected of being involved in a crime is fairly common in most European countries as well.

[googlebot]

Roughly correct?

Yes!

It's entirely possible to crack file formats and deal with each internal blob of data independently for the purposes of deduplication, making it resistant to tag changes (or at least ensuring that any further clients would only need to upload the modified tags).

Yes, it is indeed possible. And I also think that spoon has programmed something like that. The point I was trying to make was: There is no greater secret about a music collection than what it lists (compare that to private videos where the actual content is the secret). A deduplicating audio backup service with intelligent track ID mechanisms, that survive encryption (while only scrambling the content) makes no sense. Track IDs and there correlation among users ARE the secret.

I don't think that Wuala would be interested in more fine grained deduplication, because privacy is one of their biggest unique selling points. Deduplication of anonymous blobs is just a welcome side effect of how their P2P protocol distributes content to storage nodes.

This post has been edited by googlebot: Jul 25 2011, 22:03

[indybrett]

Album art is not part of the 500 MB quota.

500MB? Unfortunately, that's not enough for a large FLAC collection. And there's no point in backing up MP3's, IMHO.

[Soap]

Dude, at least read the first page of the thread.

500MB of quota for non-audio data

This post has been edited by db1989: Jul 26 2011, 12:38

Reason for edit: no need to quote

[indybrett]

Actually, it wasn't in the thread, unless I missed it. It was, however, in the fine print on the web page. Thanks.
++ audio has no limits other than a fair use policy, non-audio files subject to 500MB total locker space

Edit: Unless you mean this "Very interesting, though 500 MB limit on non-audio data seems wrong", which is not an official statement from Spoon.

This post has been edited by db1989: Jul 26 2011, 12:38

Reason for edit: no need to quote

[hellokeith]

A popular recent saying is that if the product is free, then most likely YOU are the product.

So what I want to know is what is in it for the AudioSafe developers/employees/investors? There cannot be much expectation of daily restore revenue. Certainly not enough to offset storage costs in the short to mid term. What is the benefit of having petabytes of digital music? Testing of algorithms, processing, compression?

[Emon]

So what I want to know is what is in it for the AudioSafe developers/employees/investors? There cannot be much expectation of daily restore revenue. Certainly not enough to offset storage costs in the short to mid term. What is the benefit of having petabytes of digital music? Testing of algorithms, processing, compression?

I also want to know this. From what I've read, the business model depends on users' having data failures. Given how uncommon that really seems to be these days, what is the revenue stream?

This post has been edited by Emon: Jul 26 2011, 06:21

[Garf]

I also want to know this. From what I've read, the business model depends on users' having data failures. Given how uncommon that really seems to be these days,

Hard drive failures have been +-5% (depending on brand/model) per year for a long time, and SSD's get very similar numbers. So I'm not sure what "uncommon these days" is supposed to mean.

[spoon]

A popular recent saying is that if the product is free, then most likely YOU are the product.

If the restores were free then I might agree with you.

[Squeller]

My concept says: 1 HD current audio data, 2nd builtin HD with a copy, 3rd in bank safe, all changed regularly and I keep all old ones. Cannot upload tons of stuff (n*10^2 GBytes) to a www service, because of my providers upload bandwidth. Also, encryption.

This post has been edited by Squeller: Jul 26 2011, 14:07

[frozenspeed]

Let's be less glib and just say that the Patriot Act, for all its many flaws, does not work like that.

Citation needed

[DonP]

I also want to know this. From what I've read, the business model depends on users' having data failures. Given how uncommon that really seems to be these days,

Hard drive failures have been +-5% (depending on brand/model) per year for a long time, and SSD's get very similar numbers. So I'm not sure what "uncommon these days" is supposed to mean.

In the case of laptops you have to consider a higher frequency of both theft/loss and failure due to shock.

[xnor]

Maybe the business model includes re-using all the uploaded tracks/rips. Why rip music on your own if you can let others do all the work for you.

Is there a policy about what happens / Cloud Audio is allowed to do with the uploaded files?

This post has been edited by xnor: Jul 26 2011, 18:53

[_m²_]

@saratoga:
As far as I understand it, in EU your data can be investigated if there's reasonable suspicion that you committed some crime.
In US your data can be investigated if you're suspected of being related to somebody, for whom there is a reasonable suspicion that this person was planning to commit some crime.

Seems quite different.

[spoon]

Maybe the business model includes re-using all the uploaded tracks/rips. Why rip music on your own if you can let others do all the work for you.

Is there a policy about what happens / Cloud Audio is allowed to do with the uploaded files?

It would be the stupidest business model ever to 're-use' potentially copyrighted audio, and reuse for what exactly?

[xnor]

Well is there (going to be) a policy, or not? People probably wanna know what happens with their data.

[spoon]

Already stated the intentions, see:

http://www.hydrogenaudio.org/forums/index....st&p=763983