Google Drive users stung by macOS '.DS_Store' copyright infringement issue
appleinsider.com
appleinsider.com
Banks don’t have to check safe deposit boxes for stolen art.
Self storage don’t have to check containers for stolen goods.
Of course, I’m against illegal stuff, but I don’t want to waste a single second defending myself from false positives in these situations. Google has no way of knowing whether I own the IP so I could have paid for a license for the material on my drive or many other legitimate cases.
Is it because you might share the files with someone that they have to consider anything put on Google drive as being redistributed under copyright law, and thus subject to copyright restrictions?
Or is the very act of putting something in cloud storage considered redistribution under copyright law, even if the file is never shared and you are the only user?
A while ago, I backed up a bunch of my Mom's files from a failing computer of hers onto Google Drive. I didn't think anything of it at the time. If there are some copyrighted materials on there, is Google going to suddenly terminate my account after a retroactive scan?
I think very hard about copyright and ensure that I uphold copyright in all my public works — for example, there are licensing details at the end of all my slide presentations for all images. Having to apply such a level of care to every action I perform on Google services is bonkers.
>Is it because you might share the files with someone that they have to consider anything put on Google drive as being redistributed under copyright law, and thus subject to copyright restrictions?
Yes
There needs to be a sharp distinction between files for your own use and files that are shared with the world — as in a global setting for whole volumes to disable global sharing and thus avert the need for copyright scanning.
If by making files easy to share at any moment, the service creates a need to perform continuous copyright scanning of all drive content and then to take punitive action when it is detected, then the service is really nothing like a private hard drive. The potential for catastrophic loss, not only of the drive contents but of everything you access through Google services, is much more terrifying than the possibility of corrupting a local drive and much harder to plan for.
https://help.dropbox.com/accounts-billing/security/copyright...
> There needs to be a sharp distinction between files for your own use and files that are shared with the world
Even simpler: do not upload copyrighted materials to Dropbox, Google Drive, etc.
Use a local backup if needed, use sneakernet to transfer files.
it is absurd for copyright to prevent a legitimate user from storing media on a cloud filesystem.
As the article illustrates, it’s not actually that simple. Cloud services that terminate accounts (and probably instantly delete everything, to comply with GDPR, CCPA, etc.) for perceived copyright infringements will always and necessarily suffer from a false positive rate.
We’ll likely never truly learn what this false positive rate is, but that it will always exist is reason enough to give pause to the thought that services should “just terminate their account” if they think it’s infringing on intellectual property laws.
The only good answer here is an unqualified “Use a local backup”. The terms of use for non-business cloud storage absolve the providers of all responsibility for data loss, even when they have incorrectly taken punitive action against you.
This is more difficult than you are making it sound. Considering the way most people use their computers, the only way to avoid copyright infringement entirely in your use of cloud storage is not to use cloud storage the way you use your local drive but instead to assess every last file that you upload as if you were publishing it on a public website.
Sure, you can avoid uploading pirated movies (perhaps by never downloading any of them in the first place). But in fact, original works are typically copyrighted by default as soon as they are created, even if the copyright is not formally registered — and we depend on a patchwork quilt of implicit and explicit licenses for viewing and use of files on the internet. Have you ever saved a quote from somewhere? That was probably copyrighted; your use is probably legitimate, but a naive algorithm might not think so.
Situation 1. You buy a PDF ebook. You have legal rights the person use of this file, but you upload it to your cloud storage and it gets flagged. You cannot determine if the intent of uploading the PDF was to facilitate pirating, or because you have a pirates copy, or because you have the rights to it.
Situation 2. You hire a wedding photographer, and they supply you with photos that you do not own the right to distribute because they retain copyright. This is the same as the above situation, but personalised. Would you like your cloud provider to delete any file, including your wedding photo backups, because it with matches a hash in a database?
Situation 3. Copyright fair use. Much has been written on the subject, but this is where copyright falls over in a digital age. Fair use is complete indistinguishable from piracy from a flagging files by content perspective.
The robust solution is to treat files which are redistributed and therefore trigger copyright provisions completely differently from files which are not redistributed.
Furthermore, for the purposes of punitive action, sharing a copyrighted file with a limited whitelist of other users might reasonably be treated as a less of a screwup than making a file accessible to the entire internet. And therefore it should not be frictionless to share a file with the internet.
IMO, that's precisely what you should be doing.
Everything is copyrighted. The comment you just wrote is automatically copyrighted. "Do not upload copyrighted materials" means you can only upload things made over a century ago (which either were made before copyright existed, or were copyrighted but their copyright expired). Want to upload your vacation photos? Too bad, they were made this year, so they are copyrighted, and will be copyrighted for several decades after you're already dead.
> By uploading any User Content you hereby grant and will grant Y Combinator and its affiliated companies a nonexclusive, worldwide, royalty free, fully paid up, transferable, sublicensable, perpetual, irrevocable license to copy, display, upload, perform, distribute, store, modify and otherwise use your User Content for any Y Combinator-related purpose in any form, medium or technology now known or later developed.
Some 10x engineer at google write code that flags it, how is that my problem?
That used to be the thought, but Google v. Oracle ended with de mininimis defenses struck down, and imports still copyrightable, just Google was afforded a fair use defense to copying.
There is certainly creativity in API design, it's just that the right to interoperability and the utilitarian aspect should trump any copyright claim on the API itself. But there is no creativity in writing imports; you aren't making any material decisions, you're just doing something the compiler requires you to do.
But as someone who's a big fan of your work, I'd implore you to not trust myself or your knowledge on this and hit up a lawyer. You're close enough to the edge of legality with a lot of your work that I'd hate to see you stifled by a minor misunderstanding here that could have been avoided. Google v. Oracle ended better than it could have, but AFAICT still heavily complicated RE work and independent implementations. It made a lot of this murkier, and being at least internally consistent with a legal theory here could make a bad situation at least a little better by leaving you with more options.
I do not retain a lawyer personally, but I inform myself of legal opinions around this field. It's why I felt comfortable enough to write this:
https://asahilinux.org/copyright/
Ultimately though, once you stay clear of obviously problematic actions, the question of whether you're going to get in trouble boils down to whether the company you're up against is evil, for better or for worse. Given that Apple isn't going around suing jailbreakers and Hackintoshers, I'm not too worried that they'll go after us as long as we don't do anything stupid.
Conversely, I got frivolously sued by Sony for talking about a security vulnerability in the PS3... and yeah, I had to get a lawyer for that one.
In the end, once you get yourself deep enough into legal analysis around these subjects, you come to the conclusion that everyone violates copyright in little ways, all the time, and the world would grind to a halt if we stopped. The system is broken and relies on the goodwill of the people participating to not completely collapse. For example, I've previously mentioned how copying most example code you find online, e.g. in places like Stack Overflow, is a copyright violation unless you adhere strictly to the license (did you know SO content is licensed under CC-BY-SA?). Posting third party code snippets to most services, e.g. Twitter, is a copyright violation due to incompatibility between the license and the ToS requirements of the site. And so on.
Do not store a single "1" in a file, too: https://news.ycombinator.com/item?id=30060405
That's Google's doing and problem. It doesn't justify creeping around all users' files.
Should my HDD manufactures also scan for pirated movies?
Should samsonite suitcases check for pirated physical dvds?
Should my smarttv check for pirated movies?
Google isn’t even responsible legally, they are choosing to do this.
> That are shared massively
If the drive is shared, then google is shipping the bits to whoever it is shared with, same as YouTube.
Under 17 U.S.C. §§ 512 (also known as the Safe Harbor provision) Google is not liable for what users of the service upload and share as long as Google complies with take-down requests from rights holders. This behavior from Google goes way beyond what is legally required.
Under the laws, Google could also scan the content for "potentially libelous" material but this also would not be legally required. Google has no legal responsibility to scan your content for possibly infringing material.
But it's valid to question whether Google has to scan all files for known-infringing files in the first place. That's really where it gets tricky, legally. On the surface, they absolutely do NOT have to perform such scans under the DMCA.
But then there are provisions in 17 US § 512 (aka the DMCA law) that state for example:
"A service provider shall not be liable [...], if the service provider
(i) does not have actual knowledge that the material or an activity using the material on the system or network is infringing;
(ii) in the absence of such actual knowledge, is not aware of facts or circumstances from which infringing activity is apparent; or
(iii) upon obtaining such knowledge or awareness, acts expeditiously to remove, or disable access to, the material;"
This is very vague. It wouldn't be hard to imagine that some lawyers could show up claiming that because Google received a valid takedown notification for a specific file known to be a "pirate" release of some movie, that Google should have known or at least "been aware of facts or circumstances" that all copies of the same file in whatever user accounts are infringing (which might not be the case thanks to fair use, but lawyers and most juries would not care). If they could furthermore demonstrate that Google does already have knowledge required to locate each and every copy of a file in Google Drive accounts easily (e.g. find out through discovery that Google Drive "deduplicates" storage), then it would be game over with most juries and Google's safe harbor in the case gets denied and they are found liable.
And that's only the US (DMCA) aspect of it. The German Bundesgerichtshof (Federal Court of Justice, highest court of ordinary justice) for example has found in the past[0] that service providers can be liable if they have been previously informed about copyright infringement and did not take "reasonable" steps to prevent further infringement, and that these "reasonable" steps may specifically include checking new uploads and existing files against a list of known-infringing files (or hashes thereof).
Yeah, it sucks that Google and other service providers scan files that way, even if these files are never shared, and it sucks even more when somebody makes a mistake and puts a benign files on the known-infringing list (which is something Google should then correct, apologize for and reset any account flag/reinstate any banned accounts that got in the crossfire due to Google's mistake), but I can also appreciate that law makers and courts around the world have put Google into a situation where Google defacto (if not dejure) has to perform such scans to avoid liability.
[0] In a case involving where Atari sued then-filehoster rapidshare over "Alone in the Dark", in 2012.
In any case, it shouldn't be difficult for the product to make a distinction between files openly available and files being used privately within the drive on accounts that should look very legitimate to Google. The copyright filter would make a bit more sense on openly accessible files. Even then, why is Google going so far beyond what's legally required of them?
Assessing copyright implications is not "easy". It's a lot of difficult work that involves specialized expertise, judgment calls, and risk assessment. There are complex areas and shades of grey: derivative works, fair use, copyrighted but licensed materials, etc.
The main thing you are trying to avoid is causing harm at a level where an infringement claim is justified. There are a lot of uses which might look like infringement to an algorithm but which are completely legitimate.
> Check the files for copyright if you create a sharing link for them.
I just ran through everything on my Google Drive. Thank goodness I don't use it for much, though I do pay for extra storage. I don't have anything shared with the world, and only have a few files shared with a handful of family members.
But will this protect me? What is Google's policy with regards to scanning — do they scan only shared files, or do they scan the full drive because content might become shared?
>a man [was] arrested on child pornography charges, after Google tipped off authorities about illegal images found in the Houston suspect's Gmail account
https://techcrunch.com/2014/08/06/why-the-gmail-scan-that-le...
Google does automated scans, they don't care if something is properly attributed, falls under free use or you having bought an license.
They also are not really known to care about fixing false bans to individuals, sometimes they do, other times you are screwed.
They also might lock you out of all your google services, email, storage, domains, apps you bought, videos you bought on YT etc. Which tbh. is the most bonkers thing and should not be legal.
In my opinion, using this kind of filters to all the files you upload is pretty useless. The download traffic of a file or an account gives more information about some files used publicly than any other metric.
That is a civil matter that falls upon the copyright holder, not Google.
Google is no more guilty than the makers of VCRs were when you recorded something without permission.
If it allows that, people will misuse it for piracy, which will lead to this.
To my knowledge, my bank cannot access my safe deposit box without my key or without drilling and replacing the lock my key opens.
Am I mistaken about this?
Standard rental agreements explicitly state that the bank does not retain a key and is unable to open the box (without destroying the lock) in the event that you lose yours.
For example: https://www.bankofamerica.com/content/documents/deposits/saf...
"The bank does not retain duplicate keys for any rented box".
That may or may not be correct in the USA, but the world has many jurisdictions with varying laws on copyright infringement, and cloud storage providers may be liable for copyright infringement claims.
Even limiting this to the USA, we had
- Metallica vs Napster (https://en.wikipedia.org/wiki/Metallica_v._Napster,_Inc.)
- A&M Records vs Napster (https://en.wikipedia.org/wiki/A%26M_Records,_Inc._v._Napster....)
Napster lost both cases.
So, if you run a cloud provider who permits file sharing, it seems there’s a decent change you’re liable for copyright infringement by your customers.
Also, https://www.jdsupra.com/legalnews/cloud-computing-a-brief-ov... says:
Therefore, Canadian copyright law is currently unclear on whether cloud storage providers may be shielded from liability for copyright infringement
⇒ If I were to run a cloud provider who permits file sharing, I think my legal team would strongly advise to scan files _shared_with_others_ for copyright infringement.
(In the ‘.DS_Store’ case, Google’s system seems to have some embarrassing false positives, but that’s a different issue)
Cloud storage is not.
A more valid comparison would have to involve the Supreme Court's ruling on VCRs, which could possibly be used for copyright infringement, but had substantial uses that were perfectly legal.
>The Court's 5–4 ruling to reverse the Ninth Circuit in favor of Sony hinged on the possibility that the technology in question had significant non-infringing uses, and that the plaintiffs were unable to prove otherwise.
https://en.wikipedia.org/wiki/Sony_Corp._of_America_v._Unive...
I used to work in the music industry and had license to rip music and distribute it online from all the major labels. I don't want my cloud storage disappearing along with my Google account just because Google mistakenly thinks I'm a pirate.
As an end user I would be sure that my data is encrypted in-transit and at rest.
As a cloud provider I would take care of encryption and privacy promises and transparency and care about my bandwidth and storage costs.
Risks:
- bad cryptography/leaked keys. Mitigation: sound cryptography, open source model of development.
- all possible attacks from the public about potential usage of the service for CP, terrorism and other deadly crimes.
- the rest of the risks that apply to e2ee messaging as well.
// just off the top thoughts
I realize this was probably 'forced' on some engineers at Google, but I'd still be embarrassed to say I've had a hand in this. A bit like being a supporting character in the worst movie of the year.
At what point do you threaten to quit over being forced to ship crap like automatic scanning of people's private files? I am unable to empathize here at all.
What you see coming out of Google that may look cool (when it's not a new chat app they'll kill in two years) has thousands of drones behind.
Something like a source where if one file in a collection is actually copyrighted, the entire folder/files/collection is assumed to also be copyrighted. And then, each file then goes in a database with a hash, etc.
That would account for this issue, and the earlier one where files with just a one/two/three digit number in them triggered the copyright hammer.
The risk is data loss, irrespective if it is because of hardware failure or because of cloud failure connected to overzealous legal enforcement, algorithm decision making failure,or service deprecation.
Part of the risk equation is how big the chance is, and I would really love to see the numbers of hardware faulure vs cloud failure.
Another part is impact. Hardware loss might be recoverable via specific services. Cloud failure, basically you're on your own, and they might revoke access to your email a.k.a. digital identity certificate, or even sick the copyright cartel on you, worst case ending in a police visit taking out the other backups.
ZFS on Linux is stupidly easy to setup, something like URBackup for all your clients to backup onto the NAS and you've got a nice 1-2-3 (with 3 being offsite) backup scheme.
For a user familiar with Linux. Even many macOS and Windows based developers would need some time and research to set something like that up, let alone a non technical person.
Just buy a ready to use box from synology, qnap, western digital, etc… or just use a usb drive.
[1]: https://www.zdnet.com/article/decryptor-released-for-deadbol...
My team works with a lot of clients for backups and we've had so many silent corruption cases with lousy synology and qnap boxes that we just don't support them when using SMB or NFS anymore; the built-in stack is just too unreliable. iSCSI is a bit better, but iSCSI isn't how a lot of people want their NAS to work, so it's always a tough discussion. General purpose servers with proper endpoints have always been better, but it's a hard sell to clients.
Directly-attached USB is marginally better in that you don't deal with network protocols, but a lot of companies cheap out on USB controllers and it's a challenge sometimes to convince clients that the on-board controller is the issue when single (small) file writes work without issue.
But long story short, I'd propose a small general purpose server (even Raspberry Pi!) over a QNAP/Synology any day of the week. The latter does everything simply but with excess mediocrity. From my point of view, they hit MVP across a dozen + items, but competency in none.
I'm on my second Synology, the first was a cheapish 4-bay; now I'm using a much pricier 8-bay. This is for personal use, but the time and effort saved by using this over hand building has saved me factors more money. I do recommend NFS over SMB for the cheaper models as smbd is a lot more CPU heavy and transfers actually became CPU bound pretty quickly. I've never had data corruption issues in my 10ish years of use, but one subjective data point is pretty crap.
I don't imagine that there are many personal users who need/want ISCSI or other more raw block I/O protocols. As for businesses, off the shelf solutions in your requirements range are often available, and unless you're looking for very specific optimized workloads, there's probably a bit excessively expensive vendor solution that can meet those requirements.
But I have never heard of people saying they have lost data due to flaws in synology.
As an example, I have an online account and a synology nas. I test my backup every time I move to a new laptop, by doing the data migration trough the restore.
Synology, it turns out, had changed its backup solution, and finding the installer for the old tools needed to restore was non trivial. They also wanted me to click on every individual file, with 100+ K files to go. The alternative was to download a zip file, except this actually timed out before it could complete. All the data was there, except not in a decent restorable format.
Apart from that, this is not an offline backup. If your house has a fire or whatever, your backup is also gone. A NAS on its own is not enough.
I was hoping to use rsync.net as online provider, but they had no way to receive money from a SEPA IBAN. They also store data outside the EU, exposing me to a foreign legislature with markedly lower consumer protection. When looking to the EU, the storage landscape becomes fragmented quickly. There are options, but its not easy.
- data retrieval is not needed except for recovery case
- ideally, the backup process on the home server side should not be more difficult than a cron job running "rsync -avz --delete /mnt/raid user@server:/mnt/storage"
- integrity of everything should be assured - there's a couple of filesystem-level backups made with "rsync -av" on the data store which means UID/GID, chmod, symlinks, special files (e.g. device files) and whatever Samba uses to store Time Machine xattr metadata must be kept, and there should (but not must) be a way to verify if the file content in the backup is still intact.
- there must be absolutely no way for the cloud or server hosting provider or someone gaining access to the server e.g. via an RCE in the SSH or other sync daemon to access any data (both content and metadata like file name) both in transit and at rest
- it should be somewhat affordable (e.g. Amazon Glacier is ~33 $ a month, Backblaze ~40$ a month)
- ideally, there should be some form of asymmetric encryption be used so that decrypting the data requires the possession of one of three off-site YubiKeys with each having a distinct on-key-generated RSA4096 key and the corresponding password.
The easiest way to accomplish the first three targets would be to simply spin up a tiny AWS EC2 instance with an attached LUKS-encrypted EBS volume or rent a dedicated/colo server somewhere with the same setup and run "rsync -avAHX --delete" on the home server, but that's not affordable and there is a risk of the provider/a hacker accessing/manipulating the cloud server while it is running.
Duplicity plus any "dumb storage" seems to fulfill almost all constraints, but it seems to require either symmetric encryption or access to the private key on the home server - otherwise, how would it be able to decrypt and read the existing backup to find out what has already been backed up?
I personally just throw it all into a .7z file and then upload it to a cloud service (Mega, specifically). I chose 7z as it has the capability to encrypt file names, which would otherwise leak a lot of metadata to the cloud storage provider.
The main downside of this is that Mega deletes your stuff after 3 months of idle time, so I need to periodically check in on it to make it think I'm still using it.
I am really not sure how 8TB of data would fare with this setup though. For one, you'd definitely want to set up some sort of streaming thing instead of buffering the .7z file on the server and then uploading it.
Woah, each month? I was assuming you would be syncing deltas, i.e. only upload what's actually changed. An ideal system would be to keep a list of files and their respective hashes on each 7z archive task, then do a final checksum of the 7z file so you can ensure its integrity when you download it from the cloud.
A quick look at the manpage[0] shows there's an update option, although wouldn't you have to keep the whole archive locally?
This last one seems to drastically change the design into a place that hasn't really been developed. It would be quite neat, in addition to adding other properties like a compromise of the backed up server couldn't be used to destroy a backup. But assuming your goal is to pragmatically get it done, I would forgo this and accept that your backed up server is going to have full control over the backups.
FWIW I view online/cloud backups as having the strength of being synced often, and therefore up to date in case physical damage happens to the server. For longer term storage I use offsite drives in a safe deposit box, that take care of things like infrastructure being compromised and deliberately deleted along with online backups. For long term data integrity I use ZFS, borg verify, and ad-hoc sha512sums (for things that don't change much, like music collection).
In general keep in mind that your 8TB to backup likely has a power law distribution where your really important filesets are much smaller and can therefore be inexpensively backed up with more copies.
The best pricing I've seen for block devices is Kimsufi (10 USD / 2TB-mo) and buyvm.net (5 USD / 1TB-mo) although I haven't used the latter.
In my personal experience a simple ignore list can reduce size by an order of magnitude. Things that doesn't make sense to backup like thumbnails, cache files, development dependencies. And smaller is more robust, not only can it be inexpensively backed up with more copies but it can also be synced more frequently with a lower risk of partition and also is quicker to download and restore.
Gocryptfs.
> - ideally, the backup process on the home server side should not be more difficult than a cron job running "rsync -avz --delete /mnt/raid user@server:/mnt/storage"
A mirror is not the same thing as a backup.
Not officially supported on a headless server, but there are docker containers that work.
I know of a Netgear consumer NAS I installed in 2011 is still running a business, untouched. It uses two enterprise drives in a mirror config.
With cloud providers, storing stuff in different datacenters doesn't help you, if you get banned from google, because someone didn't like your youtube comment. Multiple cloud providers might be using the same amazon/azure/... datacenter in the backend. Then there are different L0-L8 problems, from political, where your country gets embargoed due to some ongoing political struggle, or you can move to another location, where the internet is slow. And now, it seems that you can lose data due to stupidity as in the original post.
> and you can then keep one at home, one at work, one at your parents place, and replace them every now and then to 'refresh' the backups
Yes, many of us do this. But I wouldn't consider it "easy", esp for the average user.
What % of home computer users own 2+ external drives? Or even 1? I bet it's under 20%.
This complete lack of accountability, of acting with total impunity is what really rankles me about big tech.
[1] https://twitter.com/emilyldolson/status/1485434187968614411
People who have 10 years worth of data and life linked to their Google Account should be pretty scared.
We often sync workstation backups including similar files to OP.
Wow.
I am actively moving email and data on to my own servers before even more things go down catastrophically.
Gmail -> Fastmail
Browser -> Firefox / Safari
Phone -> iPhone
Google -> DDG
Google Calendar -> Fastmail calendar
Google maps -> Apple Maps
The list goes on and on.
No, Google maps -> Wikimapia/OSM.
Like mac introducing files that are hidden to a mac but littering the place in other systems.
Or like Google nor caring about false positives as long as its customers (i.e. record labels) are happy.
In any case, I don't lose much sleep when one bad design hits another. My advice is the same as in the general case: avoid such systems.
I believe the expression you're looking for is "negative externality".
What I have in mind is things like, e.g. youtube amping their ad ratio by 100% when they started offering paid subscriptions. Or Apple intentionally not fixing features that cripple using windows on their new Intel processor. Or IOS shaming android users in their messaging app instead of providing appropriate support. Or MS Word detecting files written in libreoffice as 'corrupt' and offering to fix them. Or matlab introducing syntactical changes that break octave. Or Android making you go through hoops to use software outside of the play store. etc.
In other words, if you're a company engaging in such a tactic, it's probably not that you haven't necessarily considered how a 'feature' might affect users of competing products; it's probably that you have considered it, and it's just that extra bit of friction to make them feel your own product is more streamlined and superior (for all the wrong reasons).
While I understand it's an annoyance to deal with an OS specific feature, at the same time, .DS_Store is so predictable that I just can't see how it's a challenge to deal with. Everything you need to know as a non-Mac user is basically "you don't need to consider this except by special request", and at worst, the end-result of not considering .DS_Store is your user(s) have to reset a few window settings.
I truly don't get the vitriol expressed towards .DS_Store; it's a hidden system file like any other and I struggle to understand the use cases where having .DS_Store in a directory is an issue. I have read countless articles complaining on it, but I've not heard a reason beyond "it junks up file systems", which can be said about _any_ system file.
https://wiki.archlinux.org/title/XDG_Base_Directory
PS. I don't know about Mac but Windows also have similar directories although more of a mess.
There's no reason to save artifacts or local user config along with data.
I wouldn't call it a bad solution.
Processing the DMCA notices has a cost. Nothing requires the DMCA notice to be in a machine readable format (although AI is getting better at this type of task), so it often requires a human in the loop. And they were getting sued by the copyright holders regardless of protections under DMCA. So they struck a deal with the copyright holders, that instead of them sending Google a DMCA, Google would provide an interface and automation to handle this, in return for the rights holders dropping their lawsuits.
Unless this changed very recently, notices are still being sent to google and just like google AI they fail horribly in that regard. So if that's the case i feel like the cost didn't disappear and probably not even lower and this is just an additional tool to make lives of google users hell. Plus the fact that google does have non existent support this makes their services really hard to recommend to anyone.
Disclaimer: I also don’t store copyrighted material.
Nothing to do with this example but today I decided to watch a documentary on my iPhone on Netflix app, which I rarely use on mobile. I liked a scene, took a screenshot to send to someone who might be genuinely interested in watching the documentary (which would even mean potential new customers for Netflix). The screenshot was blank. Then googled it to find it's on DRM grounds.
It takes one person to pirate and distribute a movie online to anywhere on Earth, yet these attempts block normal users from perfectly fair use.
Anyone who is going to pirate things will find a way anyway. Just like the Google example: the whole piracy detection system harms all the perfectly legal, fair use users while pirates have tons of other ways of distributing files anyway.
I wonder when this will end and copyright holders will understand that they're approaching this the wrong way.
I could pay for more storage for Google, but I don’t want it to have all my data with all the problems that I see here, and I honestly don’t know what to do now to sync with my mobile, as Google Drive was great for me in the past.
I see some people suggesting E2E solutions, but I’m not sure how great is the mobile experience for those, and how well they integrate with Google docs, which I love to use.