It's not clear, but "as the hosted OSes run natively on Intel" is almost certainly referring to the fact that your VMs must be x86(-64) and not some other architecture.

Considering a major concern is that the non-sensitive system becomes compromised, running the sensitive system as a VM within the non-sensitive system isn't a very good plan. A compromised host can trivially compromise a guest.

Running the sensitive system as the host works, but it means that the sensitive system is always running. Running both systems as VMs under a host OS that's not used for anything else is a better solution, but is more resource-hungry. This lets you turn off the sensitive system when you're not using it, which is particularly useful if you're using encrypted storage for it (as you should).

Depending on the virtualization software, setting up the networking as OP requested could be a bit of a pain.

Use afl.

As someone who has done exactly that: there's very little reverse engineering involved. The main points of the filesystem are well-documented in Tech Note 1150. For the newer features and some details, you need to look at the publicly-available kernel source. A few features, like file compression, are not well-documented and require reverse engineering, though you can get pretty far with existing third-party documentation (like the Singh book).

I mean there are a lot of open-source software projects relevant to their interests that are conspicuously lacking in attribution. REDHAWK, for example.

Probably, but that's a completely different organization.

FYI, they've had things on Github for a while. Just maybe not under the NSA name.

Encryption implemented in hardware is fast. Note that there are plenty of embedded devices that do encryption and decryption at high bit rates (Blu-ray player, HDCP endpoint, encrypted hard disk, link-layer network encryption).

A fast flash storage card for a camera has a write speed of about 100 MB/s. It's pretty easy to get hardware AES implementations that are around a gigabit/sec.

Cameras already use processors that have nearly the feature set of a general-purpose CPU. (Canon's DIGIC is x86, and DIGIC II is ARM.) They run actual firmware. In fact, they often run an embedded operating system (e.g., VxWorks). That firmware can implement arbitrary features. Take as an example. You can see in the source code that it is not, in fact, simply enabling and disabling existing functions.

CPUs are slow to perform encryption because it's a lot of bit-level modification. CPUs don't have the instructions necessary to do those operations efficiently. That's why they added AES-specific instructions to x86. You can implement encryption in hardware, though, in which case it is very fast. High performance in hardware implementations is a major design feature -- it was required in DES, and it was required in AES.

It's not just overkill, it's ineffective. Encryption is to create confidentiality: making an unauthorized party unable to obtain the information contained in the message. Encrypting a public database is worthless. If you're making it publicly accessible, there are no unauthorized parties. (This is different from encrypting the data transmissions of users, which is done to prevent third parties from learning what data is being accessed by a particular user.)

What you'd want to prevent unauthorized tampering is authenticity and integrity controls, like digital signatures.

A company, BitTorrent, created a piece of software, BitTorrent, which used the protocol, BitTorrent, for P2P filesharing.

The BitTorrent company at least was created by the guy who created the BitTorrent protocol. I think their early "BitTorrent" software was not, however, the original implementation of that protocol. (Don't quote me on those facts, I'm going off of memory here.)

Later, BitTorrent the company bought/licensed the uTorrent software and distributed it under the name "BitTorrent". (They mercifully incremented the major version number and stopped distributing their earlier software.)

It's not the best naming system.

The margin of error is that little sideways H in the middle of the bar on the chart.

You know the study itself is a pretty short read, right?

Anyway, yes. Everyone, both male and female, who have "gender-neutral" GitHub profiles had pull requests accepted at a higher rate than everyone who had "gendered" profiles. The difference between gendered vs. gender-neutral profile was larger than the difference between genders. Note that all that is for "outsiders" -- insiders have a higher acceptance rate overall with seemingly little difference between (male, female) x (gendered, gender-neutral).

It doesn't appear that the study considered "pointing out their gender" at all.

Rather, they tried to determine whether the gender of a GitHub profile was readily apparent.

Per the description of their methodology, if you use a profile image (rather than an identicon), you are automatically considered "gender is readily apparent". If that test fails, they look at the confidence level output by a gender-guessing bot of some kind. If that fails, they have a method for estimating the confidence level of a panel of three humans.

Chart on page 10 is completely acceptable. It contains a lot of data, all of which is constrained to the 60-90% range, the range is clear, and the chart isn't really deceiving.

Page 13 similarly has a lot of data and doesn't really deceive. All extending the bars down to 0% and up to 100% would do is make it harder to read. However, it would work better as a table.

Chart on page 15 is a standard example of data that doesn't need a bar chart. Even with the narrowed range, most differences are difficult to see. Here, the major visual message is that insiders get pull requests accepted much more than outsiders, but it's not as big a difference as it seems. Unfortunately, that's not what's interesting about the data -- it's that outsider females whose gender is apparent have a lower acceptance rate than males, but outsider females whose gender isn't apparent have a higher acceptance rate, while insiders seem to be nearly gender-agnostic in both cases. (One wonders why the acceptance rate for non-gender-apparent outsiders of either gender is significantly higher than for gender-apparent outsiders of either gender.) This would all be much better displayed in a table.