It depends. You can get anyone to read a script on a recorded television show, but that's usually not the point. You can't really do an interesting interview with someone who is a good communicator but isn't familiar with the subject matter.

It depends. All of those are supported by theory. They're only "speculative" in that they are permitted by theory but have not been observed and, as a result, it's an interesting question as to whether or not they exist. (If they don't or can't exist, can that information be used to improve our theory?) So, depending on the context and what you say about them, they are potentially interesting lines of discussion, because they offer insight into what (some) physicists are still looking in to.

Demonstrating that people should be using wireless keyboard protocols that don't suck.

Well, a droud utilizes a wire that actually goes into the brain. The tasp, on the other hand, works externally and remotely. So this is somewhere in between the two.

1. That's pretty common simply because getting anything approved for encryption above the SBU level is difficult and expensive. (It also requires, in essence, review by and the approval of NSA.) So tons of encryption products are made only up to the SBU level.

2. Even with end-to-end encryption, it's unlikely that they would approve classified data transiting the Internet.

The "A" stands for "Advanced". I think they were more interested in a research network than a tactical (battlefield) network. I think it's still true that "one organization controls all the infrastructure between two points on the Internet" was *not* the model of the Internet they were envisioning at the time.

The issuer generally doesn't have a copy of your private key. You make a public-private keypair, put the public key into a certificate request, send the request to a CA, and the CA generates a signed certificate from it that includes the public key. The private key is not seen by the CA at any point.

You of course *could* have the CA generate both parts and then send you both the public and private key, but that's not nearly as good a solution and is much less common. Most of the CAs I've seen that provide "easy to use" interfaces generate the keypair in the Web browser so that the private key doesn't have to be transmitted.

"It is not within the technical capabilities of [Company X] to fulfill this request."

They do say which commercially-available strains they use.

That's only true if you propagate yeast (internally) for many generations. You can also buy yeast, which a lot of brewers do because it saves them the trouble of doing careful quality control on a microbial culture.

It's also possible to acquire other brewers' yeasts unless they filter or sterilize their beer. Yeast labs do this on a regular basis and then sell it to other breweries (and to homebrewers). The yeast from The Alchemist, for example, is available from a couple of different companies now.

Only a handful of yeast strains are so interesting that their being "proprietary" is economically valuable. A lot of those have been cloned and are commercially available. Some are mixed microbial cultures (like with lambics), which are very challenging to copy because they're sensitive to their particular environment.

Really, the answer is that brewers don't worry about others stealing their secrets too much, because the market is big, it's pretty easy to make interesting beer recipes, and there are so many process variables that's it's very hard to make exact clones even if you have another person's secrets.

Many crafter brewers will simply give you their recipes -- or at least, the important details -- if you e-mail them and ask.

PtY is not difficult to reverse-engineer. It's expensive to make, though, and the ratio of beer nerds to homebrewers is high enough that making it yourself doesn't really put a dent in their market.

No. You're completely imaging--synthesizing--that Windows is "my platform" because Secure Boot was mentioned. The whole argument of signing kernels, root compromising the kernel with modifying the disk, etc. is just as true in Windows as in Linux. You just change the jargon. It's absolutely the same system.

Incidentally, by the nature of my work, I have all kinds of different operating systems. Most serious work gets done on Linux, or, occasionally, OS X, because I can't stand MinGW / Cygwin and command-line is faster. I also don't have a Windows system that actually supports UEFI Secure Boot.

Your simple solution is simple but unusable.
Signing binaries is not complex.
The UEFI Secure Boot implementation used by Microsoft is not the only way to implement Secure Boot.

When attacks can hop airgaps through things like USB devices, the solution "airgap more" sounds a little desparate.

So, most of that post was illegible anti-MS "I imagine everyone who disagrees with me is a fanboy" twisted worldview shit and is largely unreadable. I don't particularly agree with MS's Secure Boot approach, and you manage to point out why in the one coherent sentence at the beginning:

Preshipping kernel-signing keys in TPMs and making it tricky to modify the trusted-signing-key list is a dangerous approach they've taken, for this reason. The benefit is that they can get people to actually use it. You can't get many people to use any feature that requires actual configuration. But key revocation is nearly impossible to get right in userland, so there's no way it'll work in a TPM -- a compromised signing key has carte blanche.

Incidentally, as far as I know, the TPM Secure Boot implementation doesn't use web-of-trust, it uses a typical PKI hierarchy.

Secure Boot doesn't do anything to address user-space exploitation. It's not supposed to. That's a more serious problem for most users, yes, but different solutions are for different problems.

Incidentally, with a non-compromised kernel, an antivirus can, if it wants to, block anything before it executes. They hook system calls. They strictly get to operate before any change to the system occurs. In practice, this is often not done (which is why they're not very good), because characterizing "evil behavior" is hard, hooking all system calls is expensive, and people uninstall things that slow down their machine.

You can even, if you want, enforce that every executable memory page on your entire system have a SHA-2 hash that matches the hash for a page from the corresponding signed binary, so that you have no tampered executable memory pages on your whole system. The kernel will gladly do that if you implement it. You can even whitelist individual binaries (by hash+signature, no less), so that untrusted-but-signed binaries can't run either. It's been implemented on a Linux system, years ago. This approach does ruin Javascript, since it's JIT-compiled, but that's probably for the best.