Mount Existing Files

[stephenm00]

Fixed

[Christopher (Drashna)]

Unfortunately, no, there isn't a way to do this.

 

Specifically, StableBit CloudDrive stores raw blocks of data on the providers, and not actual files.  This means that it's raw file system data, with no way to easily move it over.  Especially, if you've encrypted the drive.  You'd need to download the files and copy them over to the CloudDrive drive.

[Alex]

The reason why I chose this architecture for StableBit CloudDrive is because I think the primary #1 feature of StableBit CloudDrive is the full drive encryption. You set up your own encryption key, no one else knows it. We don't know it. Your cloud providers don't know it. This gives you absolute control over your data's security.

 

Note that even if your cloud provider says that they're encrypting your drive, the point of control over that encryption is not under your supervision. So essentially you really don't know what's going on with that encryption. Perhaps some rogue employee may have access to those keys, etc...

 

Given that type of approach, it made sense to store your data in opaque chunks.

 

Letting you access your existing files in the cloud through a drive letter would require a totally different architecture of StableBit CloudDrive (and frankly, other application have already done this). I think we are relatively unique in our approach (at least I don't know of any other products in our price range that do what we do).

 

I guess the way that I see StableBit CloudDrive is really TrueCrypt for the cloud (although, admittedly, we're not open source). The idea is that you create an opaque container, store it in the cloud, and have confidence that it's secure. Or you can do the same locally, but the architecture is optimized for the cloud.

[denton]

Letting you access your existing files in the cloud through a drive letter would require a totally different architecture of StableBit CloudDrive (and frankly, other application have already done this). I think we are relatively unique in our approach (at least I don't know of any other products in our price range that do what we do).

 

Relatively unique? Doesn't CloudXender allow you to store encrypted files in the cloud? (rhetorical question... it does). It uses the same folder structure as the local drive and when not encrypted, you can access files using any other means, web interface, some other third party app. Not to mention you can sync existing cloud files back to your machine. So they seem to have been able to do it, why can't CloudDrive?

[Alex]

Relatively unique? Doesn't CloudXender allow you to store encrypted files in the cloud? (rhetorical question... it does). It uses the same folder structure as the local drive and when not encrypted, you can access files using any other means, web interface, some other third party app. Not to mention you can sync existing cloud files back to your machine. So they seem to have been able to do it, why can't CloudDrive?

 

When I said unique, I didn't mean that we're unique at offering encryption for the cloud, or mounting your cloud data as a drive. Surely that's been done by other products.

 

And by the way, I'm not trying to convince you to use StableBit CloudDrive, in fact, I'm saying the exact opposite. If you want to share your files using the tools that your cloud provider offers (such as web access), StableBit CloudDrive simply can't do what you're asking.

 

I'm simply trying to explain the motivation behind the design.

 

Think about TrueCrypt. When you create a TrueCrypt container and mount that as a drive, and then copy some files into that encrypted drive, do those files get stored on some file system somewhere in an encrypted form? Does the encrypted data retain its folder structure? No, the files get stored in an encrypted container, which is a large random blob of data.

 

You can think of StableBit CloudDrive as TrueCrypt for the cloud, in the sense that the files that you copy into a cloud drive get stored in random blobs in the cloud. They don't retain any structure.

 

(I know, we're not open source, but that's the best analogy that I can come up with)

 

Now you may ask, why do this? Why not simply encrypt the files and upload them to the cloud as is?

 

Because the question that StableBit CloudDrive is trying to answer is, how can we build the best full drive encryption product for the cloud? And once you're encrypting your data, any services offered by your cloud provider, such as web access, become impossible, regardless of whether you're uploading files or unstructured blobs of data.

 

So really, once you're encrypting, it doesn't matter which approach you use. Either way, encrypted data is opaque.

 

The reasons that I chose the opaque block approach for StableBit CloudDrive are:

• You get full random data access, regardless of whether the provider supports "range" (partial file) requests or not.

   

  Say for example that you upload a 4GB file to the cloud (or maybe even a 50GB file or larger). This file perhaps may be a database file, or a movie file. Now say that you now try to open this file from your cloud drive, with something like a movie player. And the movie player need to read some bytes from the end of the file before it can start playback.

   

  If this file is an actual file in the cloud, uploaded to the cloud as one single contiguous chunk (not like what StableBit CloudDrive does), how long do you have to wait until the playback starts? Your cloud drive would need to download most of the file before that read request can be satisfied. In other words, you may have to wait a long while.

   

  With the block based approach (which StableBit CloudDrive does use), we calculate the block that we need to download, download it, read that part of the block that the movie player is requesting, and we're done. Very quick.

• For StableBit CloudDrive, the cloud provider doesn't need to support any kind of structured file system. All we need is key/value pair storage. In that sense, StableBit CloudDrive is definitely geared more towards enterprise-grade providers such as Amazon S3, Google Cloud Storage, Microsoft Azure, and other similar providers.
• Partial file caching becomes a lot simpler. Say for example that you've got a huge database file, and a few tables of that file are accessed frequently. StableBit CloudDrive can easily recognize that some parts of that file need to be stored locally. It's not aware of file access, it's simply looking at the entire drive and caching locally the most frequently accessed areas. So those frequently accessed tables will be cached locally, even if they're not stored contiguously.
• And lastly, because the file based approach has already been done over and over again. Why make a me too product?

   

  With StableBit CloudDrive, it is my hope to offer a different approach to encrypted cloud storage.

   

  I don't know if we've nailed it, but there it is, let the market decide. It'll succeed if it should.

[Christopher (Drashna)]

Relatively unique? Doesn't CloudXender allow you to store encrypted files in the cloud? (rhetorical question... it does). It uses the same folder structure as the local drive and when not encrypted, you can access files using any other means, web interface, some other third party app. Not to mention you can sync existing cloud files back to your machine. So they seem to have been able to do it, why can't CloudDrive?

Since I'm assuming you mean Division-M's Cloud Xtender.

If that's the case, I don't think you've heard the news yet, then. Sadly, Anthony is closing up shop.

http://blog.division-m.com/2015/11/19/all-good-things-must-come-to-an-end/

[denton]

 

When I said unique, I didn't mean that we're unique at offering encryption for the cloud, or mounting your cloud data as a drive. Surely that's been done by other products.

 

And by the way, I'm not trying to convince you to use StableBit CloudDrive, in fact, I'm saying the exact opposite. If you want to share your files using the tools that your cloud provider offers (such as web access), StableBit CloudDrive simply can't do what you're asking.

 

I'm simply trying to explain the motivation behind the design.

 

Think about TrueCrypt. When you create a TrueCrypt container and mount that as a drive, and then copy some files into that encrypted drive, do those files get stored on some file system somewhere in an encrypted form? Does the encrypted data retain its folder structure? No, the files get stored in an encrypted container, which is a large random blob of data.

 

You can think of StableBit CloudDrive as TrueCrypt for the cloud, in the sense that the files that you copy into a cloud drive get stored in random blobs in the cloud. They don't retain any structure.

 

(I know, we're not open source, but that's the best analogy that I can come up with)

 

Now you may ask, why do this? Why not simply encrypt the files and upload them to the cloud as is?

 

Because the question that StableBit CloudDrive is trying to answer is, how can we build the best full drive encryption product for the cloud? And once you're encrypting your data, any services offered by your cloud provider, such as web access, become impossible, regardless of whether you're uploading files or unstructured blobs of data.

 

So really, once you're encrypting, it doesn't matter which approach you use. Either way, encrypted data is opaque.

 

The reasons that I chose the opaque block approach for StableBit CloudDrive are:

• You get full random data access, regardless of whether the provider supports "range" (partial file) requests or not.

   

  Say for example that you upload a 4GB file to the cloud (or maybe even a 50GB file or larger). This file perhaps may be a database file, or a movie file. Now say that you now try to open this file from your cloud drive, with something like a movie player. And the movie player need to read some bytes from the end of the file before it can start playback.

   

  If this file is an actual file in the cloud, uploaded to the cloud as one single contiguous chunk (not like what StableBit CloudDrive does), how long do you have to wait until the playback starts? Your cloud drive would need to download most of the file before that read request can be satisfied. In other words, you may have to wait a long while.

   

  With the block based approach (which StableBit CloudDrive does use), we calculate the block that we need to download, download it, read that part of the block that the movie player is requesting, and we're done. Very quick.

• For StableBit CloudDrive, the cloud provider doesn't need to support any kind of structured file system. All we need is key/value pair storage. In that sense, StableBit CloudDrive is definitely geared more towards enterprise-grade providers such as Amazon S3, Google Cloud Storage, Microsoft Azure, and other similar providers.
• Partial file caching becomes a lot simpler. Say for example that you've got a huge database file, and a few tables of that file are accessed frequently. StableBit CloudDrive can easily recognize that some parts of that file need to be stored locally. It's not aware of file access, it's simply looking at the entire drive and caching locally the most frequently accessed areas. So those frequently accessed tables will be cached locally, even if they're not stored contiguously.
• And lastly, because the file based approach has already been done over and over again. Why make a me too product?

   

  With StableBit CloudDrive, it is my hope to offer a different approach to encrypted cloud storage.

   

  I don't know if we've nailed it, but there it is, let the market decide. It'll succeed if it should.

 

 

Thanks for the detailed explanation. While I do understand your what you are trying to achieve, in my mind this black box approach makes me a little nervous. But that is not to say it is wrong, just one users opinion.