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.

I'm not cheering MS. UEFI Secure Boot is just MS strongarming people into actually adopting something that's been widely researched for a while now. People have had research-grade implementations of secure-boot for Linux for some time now. Hell, it was probably five years ago that there was a proof-of-concept implementation of a signed full stack on Linux that did remote attestation (so that a server could prove to a user that its software stack was untampered).

Otherwise, you're being deliberately obtuse in order to argue on the Internet.

The "reading comprehension" comment was in response to this:

I said exactly what had to be done. It's simple. It does take writing to disk. I assume the anon is you, by the way, turning on the anonymous box in order to be a dick. Good job.

Read-only media plus turning off module loading is a solution to preventing adversaries from modifying the kernel, yes (provided you turn off some other kernel features also, and that your kernel has no exploitable bugs). Just "no module loading" is not a replacement for secure boot. It's a different thing. Read-only media is arguably a replacement for secure boot. You'll notice that not many people actually use booting from read-only media, and the reason for that is that it's terribly inconvenient. (It's particularly inconvenient to securely update the kernel without throwing away the read-only security benefit.) Signed kernels is a lot like that, except hey, you get to store your kernel on a normal disk, like most Linux distros expect you to do.

Christ, use a little reading comprehension.

1. Be root.
2. Use disk writes to modify the kernel binary.
3. Reboot

There are fancy ways to accomplish (2), but a suitable proof-of-concept is to completely overwrite the existing kernel binary (on disk) with a new one compiled by the attacker. That should make it obvious that the attacker gets to completely control what is in the kernel.

That sure worked against Stuxnet.

Those solve different problems. Turning off the ability to load modules is an alternative to signing kernel modules. Secure boot is about, at boot time, validating that the kernel has not been modified before loading it.

Consider that in Linux, root is able to modify the kernel binary. So privilege escalation from root to kernel requires only a reboot and writes to disk.

Our friendly local gaming store is running game demos (and unstructured try-before-you-buy) and giving out coffee Friday morning. The owner encouraged us to come by.

What am I mistaken about?

Because loading kernel extensions is one of the easiest ways of turning a user-mode code-execution exploit into a kernel-mode code-execution exploit. Those are serious business.

People like to treat exploits in a vacuum and handwave around the other components of a full-stack exploit. Vulnerability in Safari that enables an attacker to make you silently download and run a native executable? No problem, it's only running in user mode. Vulnerability in system configuration that enables loading of unsigned kexts? No problem, just don't download anything that's obviously bad. Wait...

No and no. There are other problems with end-to-end encryption, but you have not identified any of them.