I might be misremembering things here but AFAICR, it went something like this:
MegaUpload existed as a file hosting service. It was widely used by pirates, and MegaUpload earned a lot of money off of hosting pirated files because users would buy subscriptions to MegaUpload specifically because of the pirated content that they could download, without the limitations that are placed on the users of the free tier.
With a paid subscription you got:
- Multiple parallel downloads
- Much faster speed
- No waiting time between downloads
A similar service was RapidShare, also popular with pirates.
Pirate sites would typically split downloads into multiple parts due to restrictions on upload size on MegaUpload, RapidShare and other file hosts like that. They would then upload these parts to MegaUpload and RapidShare and one or two other file hosts so that:
- If files were taken down from one host they might remain available for a bit more time from one of the other hosts
- Free users could speed up download times by simultaneously downloading the different part files from different hosts. So you’d start a download for part 1 from MegaUpload, part 2 from RapidShare and part 3 from some other host. Then you’d occasionally check on the slow progress and the countdowns from each sites before they allowed you to download another part, and continuing downloading parts from each as soon as they allowed you to again after you finished downloading a previous part from them.
The connection to Mega is that after MegaUpload was shut down, they started Mega and they made it so that all uploaded files were encrypted client side during upload and the URL contains a fragment with the encryption key so that it’s decrypted client side and the key is not shared with the server (unless of course the JS served by the server is modified to explicitly send the key to them either during upload or download).
This solved a problem for the pirates and it solved a problem for Mega.
Previously when a file was taken down, the host would usually make note of the hash of the file that was taken down and not allow that file to be uploaded and shared again.
Now, with encryption users could reupload the exact same parts without having to do anything on their end. And the users downloading did not have to do any extra steps either on their end either.
This benefits the pirates greatly. When you’ve spent 3 days downloading a bunch of part files and suddenly the remaining parts are all taken down and their hashes banned it sucked to be a pirate. But with this automatic encryption the same parts could be reuploaded and new links could be posted to pirate forums and the users could pick right up again where they were in the progress of downloading all the parts.
Less work for users uploading. Less work for users downloading. Happier users. More paying customers.
And in addition to more money, Mega also have less work to do as now when someone argues that they should police the uploads better they can point to the files all being encrypted and then not having the keys to decrypt the files there is no way that they actually can inspect the files they are storing for their users. (Again unless they modify the JS they serve to their users so that they intentionally send the key to the server.)
Of course, encryption benefits everyone. Not just pirates.
But at least to me it appeared strongly that the main motivation for building Mega and having it use this client side automatic encryption and decryption was very specifically because of the experience they had with takedown requests for intellectual property hosted on MegaUpload. It’s a neat way to cater to the pirates and encourages them to become paying customers of Mega.
Meanwhile Mega is actually a really good Dropbox alternative. Stable, fast transfers, desktop sync works very well, lots of sharing options, decent pricing. I've been a happy customer for years instead of Dropbox and iCloud.
> when a file was taken down, the host would usually make note of the hash of the file that was taken down and not allow that file to be uploaded and shared again
One of the complaints the US case had was that MegaUpload specifically did not do this. They de-duplicated uploads by hash internally, but when one download URL was DMCA'd, they only disabled that one URL and left other URLs with the same hash accessible.
How exactly are rights holders required to inform MegaUpload of content to remove? Every DMCA takedown request I've seen generally has a collection of links. I don't know the letter of the law of the actual process, but the ability of a rights holder to tell MegaUpload to take down all copies of X piece of media seems... Unfair. Not everybody has a hash based system, and even if they did, variance - such as raring, modification times, etc, would make everything mismatch. And, if that is actually the process, why do they bother to include the links at all?
Adding to this there were stories that came out that even beyond knowingly profiting from pirated content people working on the MegaUpload backend would search it directly for warez to share amongst each other.
Thanks, I had no idea that's how it worked. Embedding the key in a part of the URL that's not sent to the server is a stroke of genius.
I still find it surprising that so many people use Mega (at least enough that it can stay in business) when BitTorrent can easily saturate a downlink and is free.
Legally they can decrypt the content though, they have access to the key, they just need to change a piece of JavaScript so it sends back to the key to their server the next time a page visitor comes.
It's up to the courts and to them to decide.
Perhaps they are doing it already, but just keeping it low-profile, so the "real" dangerous people get attracted to the service and caught.
Hosting pirated content is a liability, and putting it on MEGA helps clear it. Many countries have issues with torrenting such data too, as it's an easy way to get a notice at home from your ISP if you're not on a VPN. I assume many kids in dorms and whatnot may have bittorrent traffic blocked as well.
I dunno if this is unreasonable, but I fear dling Torrents with high number of seeders in case one of them is malicious. With Mega you only had to trust one server.
Torrent files have hash check sums of the fragments. If someone sends you a bad fragment it will be discarded.
Magnet links are also hashes, so when you retrieve torrent metadata from your peers from a magnet link that data will also be verified for integrity.
However, if the original torrent itself was made from malicious data then it’s still gonna result in malicious code on your system.
Interestingly though, it is probably far more likely that a torrent with a very low number of seeders is malicious, than that a popular torrent contains malicious data in the files you download.
I suppose it could still be possible that the malicious code sent by a peer was targeting a weakness in your torrent client itself though. And that they could get remote code execution on your computer that way.
The main thing I would worry about with torrents is that your IP could be seen in the swarm by one of the companies that monitor torrent peers on behalf of rights holders and send you a nasty demand for money and threats of legal action.
Malice in this context could mean that they are concerned about someone tracking the activity.
If you are connected to a server, the server is the only connection(and only one with a log) but with a torrent, there are multiple connections so multiple parties could be keeping logs.
SHA-1 has been broken since 2017. It is considerably more expensive to produce a SHA-1 collision than an MD5 collision, but certainly not impossible. However, BitTorrent v2 also came out in 2017 and uses SHA-256, for which no known collisions exist even today.
MegaUpload existed as a file hosting service. It was widely used by pirates, and MegaUpload earned a lot of money off of hosting pirated files because users would buy subscriptions to MegaUpload specifically because of the pirated content that they could download, without the limitations that are placed on the users of the free tier.
With a paid subscription you got:
- Multiple parallel downloads
- Much faster speed
- No waiting time between downloads
A similar service was RapidShare, also popular with pirates.
Pirate sites would typically split downloads into multiple parts due to restrictions on upload size on MegaUpload, RapidShare and other file hosts like that. They would then upload these parts to MegaUpload and RapidShare and one or two other file hosts so that:
- If files were taken down from one host they might remain available for a bit more time from one of the other hosts
- Free users could speed up download times by simultaneously downloading the different part files from different hosts. So you’d start a download for part 1 from MegaUpload, part 2 from RapidShare and part 3 from some other host. Then you’d occasionally check on the slow progress and the countdowns from each sites before they allowed you to download another part, and continuing downloading parts from each as soon as they allowed you to again after you finished downloading a previous part from them.
The connection to Mega is that after MegaUpload was shut down, they started Mega and they made it so that all uploaded files were encrypted client side during upload and the URL contains a fragment with the encryption key so that it’s decrypted client side and the key is not shared with the server (unless of course the JS served by the server is modified to explicitly send the key to them either during upload or download).
This solved a problem for the pirates and it solved a problem for Mega.
Previously when a file was taken down, the host would usually make note of the hash of the file that was taken down and not allow that file to be uploaded and shared again.
Now, with encryption users could reupload the exact same parts without having to do anything on their end. And the users downloading did not have to do any extra steps either on their end either.
This benefits the pirates greatly. When you’ve spent 3 days downloading a bunch of part files and suddenly the remaining parts are all taken down and their hashes banned it sucked to be a pirate. But with this automatic encryption the same parts could be reuploaded and new links could be posted to pirate forums and the users could pick right up again where they were in the progress of downloading all the parts.
Less work for users uploading. Less work for users downloading. Happier users. More paying customers.
And in addition to more money, Mega also have less work to do as now when someone argues that they should police the uploads better they can point to the files all being encrypted and then not having the keys to decrypt the files there is no way that they actually can inspect the files they are storing for their users. (Again unless they modify the JS they serve to their users so that they intentionally send the key to the server.)
Of course, encryption benefits everyone. Not just pirates.
But at least to me it appeared strongly that the main motivation for building Mega and having it use this client side automatic encryption and decryption was very specifically because of the experience they had with takedown requests for intellectual property hosted on MegaUpload. It’s a neat way to cater to the pirates and encourages them to become paying customers of Mega.