Yes, I know this. However, this would not require them to compromise the NIST Random number test suite - No reasonalbe test suite would be able to detect this sort of scenario anyway.
So, back to the original question: Is the NIST Random number test suite compromised? What could they gain by doing this?

I've considered this as well (I will be using the NIST random number test suite in the near future). However, what can they accomplish with this? I see two approaches they could have taken: 1. Flag a non-random generator as "random". However, just because I use the NIST test suite does not mean that I don't use any other test suites, that would presumably catch this. This seems high-risk from the NSA's point of view - just one publicly available test that proves NIST is gamed shows their hand. 2. Flag something that is random as "non-random". This gets truly random generators disqualified. However, if my TRNG was disqualified, I would look into why, and that would likely reveal the NSA's hand as well. Are there scenarios that I am missing?

Svalbard is an island in the Arctic Circle, with no permanent population. Why does it have a 5TB cable terminating there?

Properly encrypted data is indistinguishable from random data. However, just the presence of random files on the system could be incriminating. Perhaps it's better to hide the data in another type of file? Perhaps using the lsb of a bitmap file?

If it were for entirely for environmental regulations, Intel would be fabbing offshore as well. Fabbing is far more toxic than packaging and testing.

Intel hasn't fabbed in Asia in the past for several reasons, one of which is intellectual property protection. If I'm not mistaken, Intel is constructing its first Asian fab now, somewhere in China.

Are you serious? Intel is one of the few companies that still fabs most of its chips in the United States (Arizona, New Mexico, and Oregon). There are also fabs in Israel and Ireland, but the bulk of the fabbing is done in the US. The packaging is done in Indonesia, China, etc, but that's not where the real money is.

I think one of the reasons wireless vendors in particular use blobs is because of the FCC compliance requirements. Can you really release an open-source programmable radio? Does the FCC even allow that? How can the FCC certify that it doesn't interfere with licensed spectrum, if the software can be changed, therefore changing the characteristics of the radio?

The general thought process is that as cars get better gas mileage, the revenues from the gas tax will decline.

I personally don't see a problem with continuing to use the gas tax, but increasing it: It encourages people to drive more fuel efficient cars. I don't see this monitoring technology as being useful.

The OpenCL spec already allowed for running code on a CPU or a GPU. It's just registered as a different type of device. So basically, they are enabling compiling the OpenCL programming language to the x86? I don't really see the story, here.