Dotcom: "We've hit the jackpot"(nzherald.co.nz)
nzherald.co.nz
Dotcom: "We've hit the jackpot"
http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1&objectid=10849627
9 comments
> Why is the DHS tracking down copyright infringers
When DHS was established, a bunch of existing government agencies were rolled into it. One of them was Immigration and Customs Enforcement (ICE), which is the federal agency with the most staff handling international IP law enforcement (traditionally, mostly counterfeiting). Copyright also falls under that category, so now DHS ends up being the one that investigates copyright infringement at the federal level.
When DHS was established, a bunch of existing government agencies were rolled into it. One of them was Immigration and Customs Enforcement (ICE), which is the federal agency with the most staff handling international IP law enforcement (traditionally, mostly counterfeiting). Copyright also falls under that category, so now DHS ends up being the one that investigates copyright infringement at the federal level.
I'd guess the GP's point was why are the DHS getting involved in what is primarily a civil action (tort) between a rights holder and an alleged infringer.
The FBI shuts down a site with hundred of thousands of user because of 36(!) infringing files
This I've never understood. I thought the US upheld the principal of due process. Is it really possible to shut down a person's business without a civil or criminal conviction?
What I find odd is that I'm not familiar with any cases outside of the Internet space where a business was shutdown during the process of an investigation. I'm sure there are examples somewhere, but it still seems wrong that the executive branch has the power to shut down a business without judicial review.
This I've never understood. I thought the US upheld the principal of due process. Is it really possible to shut down a person's business without a civil or criminal conviction?
What I find odd is that I'm not familiar with any cases outside of the Internet space where a business was shutdown during the process of an investigation. I'm sure there are examples somewhere, but it still seems wrong that the executive branch has the power to shut down a business without judicial review.
The US does not in any way uphold the principal of due process. I don't have time to write about it right now, but read up about civil forfeiture laws:
http://www.forbes.com/2011/06/08/property-civil-forfeiture.h...
http://www.forbes.com/2011/06/08/property-civil-forfeiture.h...
> When the FBI applied to seize the Megaupload site in 2012, it said the company had failed to delete pirated content and cited the earlier search warrant against the continued existence of 36 of the same 39 files.
1. It's been 3 years, I'm sure the warrant in reference did not impel MU to keep those files after the case against NinjaVideo was done and over with. This probably goes all the way back to "how" MU stored files... 1 copy for 1000s of uploads (as long as the hash/finger-print matches). And each of those videos was uploaded over and over, and MU kept them around / did not block transfers. And are now trying to make it seem like they had no choice but to keep sharing those videos FOREVER, letting everyone and anyone upload them, and letting everyone and anyone download them. I'm sure MU/KimDotCom has the original order to preserve the evidence in the NinjaVideo case, why not share it with us and let the media see the details of what was asked of them?
2. Are those the ONLY files referenced in the indictment against MU? Probably not... All the FBI has to do is prove at least one of the files listed in the warrant is valid and was brought in good faith, and then show the judge/jury the other 97% of MU traffic revolved around sharing pirated content.
That article and KimDotCom's story seems to leave a lot out.
1. It's been 3 years, I'm sure the warrant in reference did not impel MU to keep those files after the case against NinjaVideo was done and over with. This probably goes all the way back to "how" MU stored files... 1 copy for 1000s of uploads (as long as the hash/finger-print matches). And each of those videos was uploaded over and over, and MU kept them around / did not block transfers. And are now trying to make it seem like they had no choice but to keep sharing those videos FOREVER, letting everyone and anyone upload them, and letting everyone and anyone download them. I'm sure MU/KimDotCom has the original order to preserve the evidence in the NinjaVideo case, why not share it with us and let the media see the details of what was asked of them?
2. Are those the ONLY files referenced in the indictment against MU? Probably not... All the FBI has to do is prove at least one of the files listed in the warrant is valid and was brought in good faith, and then show the judge/jury the other 97% of MU traffic revolved around sharing pirated content.
That article and KimDotCom's story seems to leave a lot out.
> All the FBI has to do is prove at least one of the files listed in the warrant is valid and was brought in good faith...
Maybe, maybe not. If this is allowed to stand, it encourages a strategy of "throw everything against the wall and see what sticks." I'm pretty sure there have been cases where a warrant was thrown out because of bad-faith information, even if some of the reasons for the warrant were good.
This is certainly, at the least, a nice PR moment for Mega.
Maybe, maybe not. If this is allowed to stand, it encourages a strategy of "throw everything against the wall and see what sticks." I'm pretty sure there have been cases where a warrant was thrown out because of bad-faith information, even if some of the reasons for the warrant were good.
This is certainly, at the least, a nice PR moment for Mega.
"Throw everything against the wall and see what sticks," has been Standard Operating Procedure for the FBI since its inception. Hence, Al Capone being prosecuted for income tax evasion.
Al Capone did fail to pay income tax. How is that similar?
It's the one charge they could manage to stick him with. It feels a little ironic, considering all the other crimes he's known for.
If those three files are going to be enough to extradite him and assassinate his company, YouTube better be calling in some favors posthaste.
https://www.google.com/search?q=complete+movie&tbm=vid
https://www.google.com/search?q=complete+movie&tbm=vid
I'm curious about all of this too. I submitted the article because I want to see what others think about the new information. The 1 copy for 1000s of uploads may have some interesting implications.
My guess is that they could succsefully argue that the 1 for 1000s is simply a technical optimization.
But there is no such thing as "infringing files", only persons can infringe the law. And you cannot know who has rights over a file and who doesn't. One file link gets reported, you check it, its uploader is clearly infringing the copyright, so you remove the link. But if you remove the file, you might be doing so even for the copyrights holder(s) and everyone with a license.
1) According to previous news of this, the FBI did not explicitly tell MU to preserve the files, they simply told MU not to interfere. After the NinjaVideo case was closed, MU emailed the FBI about what to do with the evidence, but received no reply.
I've seen many people bring up the fact that MegaUpload had the same file for multiple links and that they only took down links reported as infringing. Many people seem to come to the conclusion that this is automatically somehow representative of bad behavior, but I strongly disagree. Just because something is covered by copyright and is on MegaUpload, does not automatically make it infringing, even if some of the links to it might be.
Consider that someone legally backs up his own files to MU and never shares links to them with anyone. Then someone else uploads the same content in an infringing manner. Should the first guy with his completely legal backups have his stuff deleted just because someone else did something infringing with the same files? He most certainly should not. Assuming that all links of the same file that was uploaded are automatically infringing is basically "guilty until proven innocent", and is very much not the way they should be treated. Hell, I have music and other copyrighted content perfectly legally backed up in the cloud myself, and I sure as hell wouldn't want to see it deleted just because someone else might have used the same service for infringing sharing of the same files. (and what cloud provider wouldn't want to optimize their service to only have one copy of each file in their back-end instead of wasting space with duplicates?)
And, of course, this is very different to something like child porn, which is always illegal under US laws (where the stuff was hosted in case of MU). There can be no "non-infringing" use there, so it makes sense to delete all and every link to it. Not so much with just copyrighted content. And as we also know, deducing whether something is infringing or not isn't very clear cut either, like with Viacom issuing takedowns for Youtube videos its own employees had legitimately uploaded for marketing purposes.[1]
[1] http://techcrunch.com/2010/03/18/youtube-viacom-secretly-upl...
Viacom’s efforts to disguise its promotional use of YouTube worked so well that even its own employees could not keep track of everything it was posting or leaving up on the site. As a result, on countless occasions Viacom demanded the removal of clips that it had uploaded to YouTube, only to return later to sheepishly ask for their reinstatement. In fact, some of the very clips that Viacom is suing us over were actually uploaded by Viacom itself.
Consider that someone legally backs up his own files to MU and never shares links to them with anyone. Then someone else uploads the same content in an infringing manner. Should the first guy with his completely legal backups have his stuff deleted just because someone else did something infringing with the same files? He most certainly should not. Assuming that all links of the same file that was uploaded are automatically infringing is basically "guilty until proven innocent", and is very much not the way they should be treated. Hell, I have music and other copyrighted content perfectly legally backed up in the cloud myself, and I sure as hell wouldn't want to see it deleted just because someone else might have used the same service for infringing sharing of the same files. (and what cloud provider wouldn't want to optimize their service to only have one copy of each file in their back-end instead of wasting space with duplicates?)
And, of course, this is very different to something like child porn, which is always illegal under US laws (where the stuff was hosted in case of MU). There can be no "non-infringing" use there, so it makes sense to delete all and every link to it. Not so much with just copyrighted content. And as we also know, deducing whether something is infringing or not isn't very clear cut either, like with Viacom issuing takedowns for Youtube videos its own employees had legitimately uploaded for marketing purposes.[1]
[1] http://techcrunch.com/2010/03/18/youtube-viacom-secretly-upl...
Viacom’s efforts to disguise its promotional use of YouTube worked so well that even its own employees could not keep track of everything it was posting or leaving up on the site. As a result, on countless occasions Viacom demanded the removal of clips that it had uploaded to YouTube, only to return later to sheepishly ask for their reinstatement. In fact, some of the very clips that Viacom is suing us over were actually uploaded by Viacom itself.
> Consider that someone legally backs up his own files to MU and never shares links to them with anyone. Then someone else uploads the same content in an infringing manner. Should the first guy with his completely legal backups have his stuff deleted just because someone else did something infringing with the same files?
How likely is that though? I have no idea what hashing they used to compare files. But if I rip a CD track to MP3 and you rip a CD track to MP3 are we going to get files that have matching hashes? (Even if we use the same settings, and the same meta information.)
How likely is that though? I have no idea what hashing they used to compare files. But if I rip a CD track to MP3 and you rip a CD track to MP3 are we going to get files that have matching hashes? (Even if we use the same settings, and the same meta information.)
> But if I rip a CD track to MP3 and you rip a CD track to MP3 are we going to get files that have matching hashes? (Even if we use the same settings, and the same meta information.)
Not unless you are both using a very complex ripping process, very good CD drives (for a strange and rare definition of "very good"), have configured the ripping program 100% correctly, and are using the exact same version of the same MP3 encoder.
That said, if you have both bought the MP3 from the same online store, it would of course be identical. And if you rip it in iTunes but pay for iTunes Match, if you upload your rip to their cloud it will analyse it, realise it's a song it has in its library (if it does), and then remember you have that song and throw away your data. Of course, it may not be the case that it's legal for all cloud storage providers to de-duplicate their data this aggressively - Apple only does this for files they already have agreements in place to legally distribute.
-- more details for the curious --
Ripping audio from CDs is a depressingly inexact process compared to copying data off them. To guarantee you rip the data as accurately as possible (which is the only simple way to guarantee your copies match) you need to be doing what is commonly called a "secure rip". Normally when you rip a CD it rips in burst mode, which is very fast as it reads the data linearly, once, and makes good use of the cache on the drive. However, if a read error occurs, what you want to happen is for the program to go back and try reading that sector again. This is made very complicated by the read cache! You can buy drives that don't have them, though, or have an option to turn them off (note: doesn't actually work on many drives that "support" it). Even if your drive does have a cache, decent ripping programs can defeat it by instructing the drive to read enough data from another location to evict the sector that needs re-reading. (Side note: your ripping now takes 40x longer in many cases)
So that's the complex ripping process. Asides from caching, the drive specs have another role to play: read offset. When instructed to read a given audio sector, drives miss by a constant amount (such as +17 sectors). You need to find your drive's offset and put that setting in the ripping program to compensate for this. This introduces an extra problem though, which is that with a non-zero offset you are going to need to ask your drive to read either before 0:00:00.00 or after the end of the last track in order to get all of the data - but not all drives support reading into the lead-in or lead-out.
Assuming that we have correctly defeated our cache, have managed to read the CD with no read errors occurring, no uncaught errors have occurred either (rare, but possible with some drive/CD combinations, particularly CDs with DRM), and that we have adjusted for the offset and managed to read 100% of the data...
Well, you still have the pre-track gaps to worry about. On a CD, let's say track 1 starts at 0:00 and finishes at 3:20. Track 2 could start at 3:25! On some CD players, you will see the time go from -0:05 to 0:00 while you are in that "pre-track gap". (It's actually a cool feature - it means you can have a bridge between tracks so the CD plays as a continuous mix from start to finish, but can skip around tracks and not hear a few seconds of one song going into another)
When converting them to separate audio files though (which not everyone does, once you descend into the audiophile underworld) you then have to decide what to do with the data in that gap - discard it, append it to the end of the previous track, or prepend it to the next one? So even though this setting is somewhat subjective, it would need to be the same for the data to be identical!
Luckily there is a convention there (append to previous track) so maybe you both chose that. Great! At this point it is actually very likely that you have the exact same raw PCM data, bit-for-bit!* But now you're going to screw it all up by compressing it.
Not all MP3 encoders are alike, which many people know - but the consequence of that is, that by making better compression decisions, two programs can produce MP3s from the same raw data which are both completely specification compliant, but where one is more efficiently compressed than the other (i.e. smaller file size for the same quality, or better quality for the same size). Of course, this means the files that they produce are very different - so both people would need to be using the same encoder.
Of course, the same logic applies to different versions of a single encoder! And, perhaps you would even need to be using the exact same binaries? I don't know quite enough at the low level to be sure about this, but I would not be surprised if using different compilers or different optimization methods when compiling a particular version to binary could affect the MP3 files it produces.
Oh, and of course you would need to be passing the exact same options to the MP3 encoder.
And then even if you entered the same tag data, depending which tagging program you used, the files might be different again! There are several different specs for tagging files to begin with, and there's a little too much room for interpretation in them. Some taggers will use the TPE2 "Band/orchestra/accompaniment" tag to represent the "album artist", some use a custom TXXX tag with the key "ALBUMARTIST", and some do the same but with "ALBUM ARTIST". Just to make it even more fun, the majority of tagging programs are definitively incorrect with regards to the specification, and the cherry on top is that most of them add an extra tag, hidden from you in the GUI, recording for posterity which program you tagged the file with!
But, assuming you both entered the exact same tag data into the exact same version of the exact same tagging program, you would have the same files. With the exceptions of the tagging programs that have non-deterministic behaviour (hello, Windows Media Player!)
You might be reading all this and thinking that the odds sound like zero. In practice there is a group of people (digital age audiophiles) ripping CDs using the same versions of the same software, because they all always use the latest stable versions of their entire toolchain. They're all using the exact same binary to encode MP3s, too, because LAME is the favourite and there are very few good binaries of it around (most sites are passing around the same file for any given version). They even get the same metadata, because the software they use gets it automatically from an online database. It's definitely conceivable that some of them have independently produced identical files!
P.S. I only remembered right at the end that most audio CDs have many different pressings which often differ at the 1s and 0s level, even if there is no observable difference between them ;)
* Of course, CDs do have correction codes, but sadly the vast majority of drives have C2 support so bad that it is of no use at all.
You can even check: There's an online database of checksums to ensure your rip is correct - the caveat being it doesn't check the very beginning or end of the file, due to the lead-in / lead-out problem I mentioned already
Not unless you are both using a very complex ripping process, very good CD drives (for a strange and rare definition of "very good"), have configured the ripping program 100% correctly, and are using the exact same version of the same MP3 encoder.
That said, if you have both bought the MP3 from the same online store, it would of course be identical. And if you rip it in iTunes but pay for iTunes Match, if you upload your rip to their cloud it will analyse it, realise it's a song it has in its library (if it does), and then remember you have that song and throw away your data. Of course, it may not be the case that it's legal for all cloud storage providers to de-duplicate their data this aggressively - Apple only does this for files they already have agreements in place to legally distribute.
-- more details for the curious --
Ripping audio from CDs is a depressingly inexact process compared to copying data off them. To guarantee you rip the data as accurately as possible (which is the only simple way to guarantee your copies match) you need to be doing what is commonly called a "secure rip". Normally when you rip a CD it rips in burst mode, which is very fast as it reads the data linearly, once, and makes good use of the cache on the drive. However, if a read error occurs, what you want to happen is for the program to go back and try reading that sector again. This is made very complicated by the read cache! You can buy drives that don't have them, though, or have an option to turn them off (note: doesn't actually work on many drives that "support" it). Even if your drive does have a cache, decent ripping programs can defeat it by instructing the drive to read enough data from another location to evict the sector that needs re-reading. (Side note: your ripping now takes 40x longer in many cases)
So that's the complex ripping process. Asides from caching, the drive specs have another role to play: read offset. When instructed to read a given audio sector, drives miss by a constant amount (such as +17 sectors). You need to find your drive's offset and put that setting in the ripping program to compensate for this. This introduces an extra problem though, which is that with a non-zero offset you are going to need to ask your drive to read either before 0:00:00.00 or after the end of the last track in order to get all of the data - but not all drives support reading into the lead-in or lead-out.
Assuming that we have correctly defeated our cache, have managed to read the CD with no read errors occurring, no uncaught errors have occurred either (rare, but possible with some drive/CD combinations, particularly CDs with DRM), and that we have adjusted for the offset and managed to read 100% of the data...
Well, you still have the pre-track gaps to worry about. On a CD, let's say track 1 starts at 0:00 and finishes at 3:20. Track 2 could start at 3:25! On some CD players, you will see the time go from -0:05 to 0:00 while you are in that "pre-track gap". (It's actually a cool feature - it means you can have a bridge between tracks so the CD plays as a continuous mix from start to finish, but can skip around tracks and not hear a few seconds of one song going into another)
When converting them to separate audio files though (which not everyone does, once you descend into the audiophile underworld) you then have to decide what to do with the data in that gap - discard it, append it to the end of the previous track, or prepend it to the next one? So even though this setting is somewhat subjective, it would need to be the same for the data to be identical!
Luckily there is a convention there (append to previous track) so maybe you both chose that. Great! At this point it is actually very likely that you have the exact same raw PCM data, bit-for-bit!* But now you're going to screw it all up by compressing it.
Not all MP3 encoders are alike, which many people know - but the consequence of that is, that by making better compression decisions, two programs can produce MP3s from the same raw data which are both completely specification compliant, but where one is more efficiently compressed than the other (i.e. smaller file size for the same quality, or better quality for the same size). Of course, this means the files that they produce are very different - so both people would need to be using the same encoder.
Of course, the same logic applies to different versions of a single encoder! And, perhaps you would even need to be using the exact same binaries? I don't know quite enough at the low level to be sure about this, but I would not be surprised if using different compilers or different optimization methods when compiling a particular version to binary could affect the MP3 files it produces.
Oh, and of course you would need to be passing the exact same options to the MP3 encoder.
And then even if you entered the same tag data, depending which tagging program you used, the files might be different again! There are several different specs for tagging files to begin with, and there's a little too much room for interpretation in them. Some taggers will use the TPE2 "Band/orchestra/accompaniment" tag to represent the "album artist", some use a custom TXXX tag with the key "ALBUMARTIST", and some do the same but with "ALBUM ARTIST". Just to make it even more fun, the majority of tagging programs are definitively incorrect with regards to the specification, and the cherry on top is that most of them add an extra tag, hidden from you in the GUI, recording for posterity which program you tagged the file with!
But, assuming you both entered the exact same tag data into the exact same version of the exact same tagging program, you would have the same files. With the exceptions of the tagging programs that have non-deterministic behaviour (hello, Windows Media Player!)
You might be reading all this and thinking that the odds sound like zero. In practice there is a group of people (digital age audiophiles) ripping CDs using the same versions of the same software, because they all always use the latest stable versions of their entire toolchain. They're all using the exact same binary to encode MP3s, too, because LAME is the favourite and there are very few good binaries of it around (most sites are passing around the same file for any given version). They even get the same metadata, because the software they use gets it automatically from an online database. It's definitely conceivable that some of them have independently produced identical files!
P.S. I only remembered right at the end that most audio CDs have many different pressings which often differ at the 1s and 0s level, even if there is no observable difference between them ;)
* Of course, CDs do have correction codes, but sadly the vast majority of drives have C2 support so bad that it is of no use at all.
You can even check: There's an online database of checksums to ensure your rip is correct - the caveat being it doesn't check the very beginning or end of the file, due to the lead-in / lead-out problem I mentioned already
If you used the same encoder, sure. CDs contain digital audio; each copy is identical.
The FBI does whatever it wants. The US government bends the law how it wants. I'm sure they will fabricate some sort of evidence to ensure this set back is not a set back.
Yeah? Well the FBI owns the casino. Good luck with that.
It seems that the US government is illegally using the infringed copy of justice. I strongly believe that such organisation must delete itself and its illegal copies from the wetware of all abused customers.
If this is all the FBI had as part of it's indictment, I wish Dotcom luck in getting damages...
We are all Kim Dotcom now.
..because he ate us.
I don't trust this guy and I never will. That is not the first time he becomes Super Kimble before he rips everybody off.
I don't trust this guy and I never will. That is not the first time he becomes Super Kimble before he rips everybody off.
Nobody's asking you to trust him. Heck, I don't trust you.
* Why is the DHS tracking down copyright infringers?!
* The FBI shuts down a site with hundred of thousands of user because of 36(!) infringing files
* These files were ordered by the DHS not to be deleted
* (From other articles) megaupload's users still do not have access to their data
* (From other articles) the ISP running megaupload's servers is not allowed to shut them down (or repurpose them) and has to foot the bill.
There's probably some other stuff going on that we do not know about, but this looks like a big clusterf*ck.