Live data from Hacker News

Google Drive could soon start locking your files

techradar.com

181–190 of 193 posts

Re: Google Drive could soon start locking your files

#181
post #52

Aside from legitimate DMCAs what I'm worried about is losing backupped files of any sort because some rogue individual files a complaint on stuff they don't own or because of an ML error and an inexistent customer service by Google. Also I don't really like the service to sneak onto any files I upload. What alternatives do we have for cloud file backup? I already do full backups, need something to sync files between…

I use an S3-comptaible hoster with the rclone client which supports encryption/decryption on the fly. That is, I don't even need to trust my S3 provider. For syncing between devices, I guess `rclone sync` should do the trick.

You're leaking quite a lot of information to the provider if the encryption is per-object. Not saying this necessarily matters in your use case, but good to be aware of the limitat a lot can be deduced from file sizes, timeline of accesses, and access pattens of files. And most importantly of course you're still trusting the provider for availability.

For example if you saved a folder of mp3 files using the rclone crypt functionality that you downloaded from a known BitTorrent, it would be easy for an adversary to match that set of known sized objects with high confidence at the storage provider end, or from observing encrypted network traffic (which in the S3 case leaks object size through traffic patterns) and deducing object sizes from there.

Re: Google Drive could soon start locking your files

#182
Adjacent to the article in the op:

What __is__ your recommendation for setting up remote backup for private use? I am thinking of something that can be used to sync and / or backup different devices for people of differing tech affinity.

I think this question deserves re-examination now, since recommendations likely change due to the facts in the op.

As far as I know, it used to be that one should either "roll one's own cloud" (whatever that means for a non-technical user), or simply use the best-integrated tool like Google Drive, DropBox, Apple for the devices at hand and live with the fact that the company will train whatever AI model du jour on your private data.

The reason for this binary recommendation was as follows: while services like SpikerOak exist, who say they encrypt your data, the believability of that was never exactly high. Most likely, your data might still get mined. Most likely, the NSA still scans all your docs. However, now you pay extra for "security theater".

Instead of paying for such questionable offerings, the decision was rather binary: decide to either go full-hog (if able) and do your own, or just upload it to Google Drive and stop caring about who reads your private documents.

But now, if Google starts actively reading, policing and deleting your data without even pretending to give you privacy, I think encrypted services start to have a use case again.

Re: Google Drive could soon start locking your files

#183
post #85

Earlier quoted context omitted.

It would have been interesting if any of those users who got their video file deleted would have been directly attached to the shooter (like an accomplice, let's say), afaik that would have meant that Google Driver and Dropbox had tampered evidence.

Google don’t delete. They make unavailable. If a judge said that owning that video was probable cause or whatever, they could produce every user who used to have that file.

Apologies for directly contradicting you, but it's false that Google don't delete. Google do delete in a timely fashion (which is required by law in many places!), it's just that for technical reasons, it becomes unavailable or possibly also crypto erased* first.

On an aside, such a setup is also a layer of defense-in-depth protection against a certain, uncommon class of bugs.

I do work for Google, but don't, in any way, speak for the company. All of the above information can be found on the internet, eg. https://www.quora.com/Does-Google-really-delete-the-account-... about Google accounts themselves.

* https://en.m.wikipedia.org/wiki/Crypto-shredding

Re: Google Drive could soon start locking your files

#184

I have, uh, mp3 backups of all the music I have owned from my, um, ludicrously massive CD collection. Is it worth the risk that google might one day decide I am a pirate and block my account?

For reference, I use FLAC instead of MP3. Your collection may be larger, but my ~12,000 FLAC files take less than 500GB. So I'd say it's a question of value: You could have redundant copies of your music for ~$300 CAD with a pair of Samsung T5 SSDs, or you could someday lose every email, contact, photo, document, Youtube playlist, and MP3 you use Google for. I'm not saying it's likely, but it only has to be a one-in-…

[deleted]

Re: Google Drive could soon start locking your files

#185
post #134
post #123

Earlier quoted context omitted.

Sure, but just compress and encrypt. It won't play in place, but otherwise it's nondetectable (other than by out of band timing/metadata or very rough size estimates).

...which is what floors me when Google made this statement. I thought the whole benefit of their Google drive system was deduplication of common files to minimize storage space costs. If they start tinkering with private files then people have no choice but to encrypt everything. This will cause their storage requirement to explode. However, if the goal is only to prevent public sharing of content in contravention of…

How many people have the wherewithal to encrypt their content? Even if some have the technical capability, how many are willing to take the reduced quality of life required for what is probably a low probability risk?

Re: Google Drive could soon start locking your files

#186
post #52

Earlier quoted context omitted.

I use an S3-comptaible hoster with the rclone client which supports encryption/decryption on the fly. That is, I don't even need to trust my S3 provider. For syncing between devices, I guess `rclone sync` should do the trick.

You're leaking quite a lot of information to the provider if the encryption is per-object. Not saying this necessarily matters in your use case, but good to be aware of the limitat a lot can be deduced from file sizes, timeline of accesses, and access pattens of files. And most importantly of course you're still trusting the provider for availability. For example if you saved a folder of mp3 files using the rclone cr…

Thanks for the advice. I didn't know that. In my case, it does not matter much (my data is mostly produced by myself). But, sure, it is good to be aware of that fact!

Re: Google Drive could soon start locking your files

#187
post #52

Earlier quoted context omitted.

I use an S3-comptaible hoster with the rclone client which supports encryption/decryption on the fly. That is, I don't even need to trust my S3 provider. For syncing between devices, I guess `rclone sync` should do the trick.

Is there a guide to set this up? Thanks in advance

Yup: basically you need to set up a regular S3 backend (guide here: https://rclone.org/s3/), and then you can set up a "crypt" over it (guide here: https://rclone.org/crypt/).

Re: Google Drive could soon start locking your files

#188

Earlier quoted context omitted.

EncFS is more elegant solution than zipping your files.

Does it work with Google drive?

It works with anything that you can mount as a folder - Dropbox, Mega.nz, Box, GDrive, Backblaze, etc.

It creates an encrypted file/folder for each decrypted file/folder you create. So when you change a file, only one encrypted file is uploaded into the cloud.

Re: Google Drive could soon start locking your files

#190
post #52

Earlier quoted context omitted.

I use an S3-comptaible hoster with the rclone client which supports encryption/decryption on the fly. That is, I don't even need to trust my S3 provider. For syncing between devices, I guess `rclone sync` should do the trick.

You're leaking quite a lot of information to the provider if the encryption is per-object. Not saying this necessarily matters in your use case, but good to be aware of the limitat a lot can be deduced from file sizes, timeline of accesses, and access pattens of files. And most importantly of course you're still trusting the provider for availability. For example if you saved a folder of mp3 files using the rclone cr…

There's methods to use S3-like platforms without leaking data. Restic does this by packing blocks of data together and encrypting them instead of doing it on a per-file basis. This allows for deduplication at a block level and functionally making the contents ambiguous noise.
Post reply on HN