It is a civil case, so there is no 'conviction'. Second, it is exactly how the law works, and has nothing to do with the DOJ.

Federal Rules of Civil Procedure
  TITLE V. DISCLOSURES AND DISCOVERY
    Rule 37. Failure to Make Disclosures or to Cooperate in Discovery; Sanctions ...

(e) Failure to Preserve Electronically Stored Information. If electronically stored information that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery, the court:

(1) upon finding prejudice to another party from loss of the information, may order measures no greater than necessary to cure the prejudice; or

(2) only upon finding that the party acted with the intent to deprive another party of the information’s use in the litigation may:

(A) presume that the lost information was unfavorable to the party;

(B) instruct the jury that it may or must presume the information was unfavorable to the party; or

(C) dismiss the action or enter a default judgment.

They are indeed free to say "no thanks". However, as it is a civil procedure, the judge is free to instruct the jury 'you know all those chats that defendant failed to protect? You can assume every one of them was against their case'.

Viral 'challenges' say otherwise.

They aren't saying you can't have tools that monitor a phone. They're saying you can't have tools that monitor a phone and hide that fact from the user of the phone. I don't see a reason why parents of young children would need to do that.

The interoperability exemption (which only applies to reverse engineering of computer programs) is for situations like this. Say you have a program which creates a spreadsheet. You do not document the format of the spreadsheet file. Per the interoperability exemption, it is not a copyright violation for me to reverse engineer your program in order to figure out the file format (a file format can not be copyrighted). Then, I am allowed to create an independent program, not using any of your code, which produces the same spreadsheet files. That way, files someone creates using your program can be processed by someone using my program, and vice versa. That is interoperability. That is mutual exchange of information. The PROGRAMS are using information created by their counterpart. That is the requirement for the exemption. A video signal is in no way a mutual exchange of information between two programs.

The reason I am confused is because YOU keep trying to shoehorn an exemption for a specific purpose, solely involving software and the exchange of information between two programs, into a ridiculous claim that alternate hardware somehow fits that definition. It does not.

The reason I brought up the emulator is because you could reverse engineer the console code to figure out how the games work, what is the format of the ROM, what are the APIs, etc, then use the information you have learned to create an emulator. But there is nothing in the interoperability exemption that says once you have figured that out is is OK to use a copyrighted ROM other than as licensed. In fact, it specifically says that you can not do that.

I still don't see what information you are claiming is being mutually exchanged.

What are you claiming are the two programs here, and how are they mutually exchanging information? Is the first program the console, and the second program the emulator, and the 'information' is the ROM? That doesn't make sense, because neither the console nor the emulator is creating information to be exchanged with the other.

'Interoperate' means to work in conjunction with each other. An emulator is not 'interoperating' with what it is emulating, it is replacing it.

OK, I'll bite. How does porting a game to alternate hardware allow 'mutual exchange and use of information between programs' (which is what the interoperability exception requires)?

The 'interoperability exception' applies to reverse engineering, that is all. You can reverse engineer a program (if the info is not readily available any other way) to figure out how to interoperate with it. Such reverse engineering, even for interoperability, does not permit you to otherwise violate copyright.

So I put the last part back on you - the stuff in the ROM was licensed to be used with a console. What part of copyright law allows you to make a bytewise copy of the ROM on your hard drive for anything but archival purposes?

It may be the only language that is SUPPOSED to be used, but it sure as hell isn't the only language that IS used. There are many examples of ATC and pilots speaking in their native language.

Interoperability is well defined in the copyright law, and it doesn't involve 'alternate hardware'. The exact wording is "the term “interoperability” means the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged."

So basically, if a program is using something like a file format or network protocol, which you have no other way of figuring out, you are allowed to reverse engineer the program so that you can figure out the format. Furthermore, it specifically says that reverse engineering may NOT be used to commit copyright infringement. So, maybe you can reverse engineer the game to figure out the save file format, so that you can create another, independent, program that can create or use save files, but you can't reverse engineer the game to figure out how to get copyrighted data out of the ROMs.

Simple. You make a rule that mobile devices may not be used in the courtroom. Many courts already have such a rule.

So you live in some fantasy world where the only way a machine can be compromised is by physical access. Must be nice. In the real world, there are occasional vulnerabilities that allow privilege escalation and modification/replacement of files. One such file could be the kernel.

Even mainframes have secure boot, and I can guarantee you nobody is watching blu-rays on those. Of course, people running mainframes are generally actually concerned about security.

It doesn't say that it reports it was securely booted to the OS, so I don't see how that would help.

There are remedies other than the companies being broken up. Not all that long ago there was an evil company that tried to fix the prices of ebooks. Lets see, what company was that? I think it begins with an 'A' and has something to do with fruit. Anyway, said company was fined and that stupid scheme was disallowed.

Why the fuck would you not want secure boot to work if you have enabled it?

More FUD. What "average user" is going to install something other than Windows or a Linux distribution that has a shim already signed by Microsoft? And if you do need to use custom keys for some reason, it is easy to do. 1) Enter UEFI mode and select 'clear secure boot variables'. 2) Boot install CD. Install CD sets all the required keys. 3) Reboot into UEFI and select 'Enable secure boot'. Gee, that was tough, and obviously way beyond the abilities of the 'average user'.

The reason they won't sign GPLv3 things is because the GPLv3 requires that you be able to modify the code and still run the program, and so any required 'authorization keys' must be provided. And it doesn't matter in the slightest anyway, because GRUB is not directly booted, the shim is, and Microsoft will sign those.