- Add public keys to major services
Public Key doesn't really get you much. Theoretically it means you're using a Certificate Authority (CA) to validate both sides; however, a centralized CA is still vulnerable and problematic. A Web-of-Trust system is harder to manage but can be more secure. In both cases everyone has to implement best practices and keep good key sets, which is often not the case.
With PGP/GPG people tend to keep relatively short life-spans on their keys, even then that can be between 1 and 5 years. Still, this is better than CA systems where people tend to make 5-10 year keys, often long enough now that the algorithms are being broken before the keys are replaced, and most don't use Certificate Revocation Lists (CRLs) as well because they're too painful to maintain, and essentially reduces a CA system back to a Web-of-Trust system in that respect.
- Build better random number generators
There are already world-class random number generators (RNGs)...but they're costly. So we have pseudo-random number generators (PRNGs) to try to keep the costs down. Of course, RNGs are primarily expensive due to patents and companies trying to keep it to themselves instead of fully sharing the tech. But you've got to get companies to share the data more and at cheaper prices if you want to improve RNGs and PRNGs.
- Expand trusted hardware
Now this is just false. Trusted Hardware - e.g systems booted with SecureBoot/Palladium/TrustedComputing/etc - don't really buy you anything other than locking down everything to the few "trusted" vendors that get to decide what software runs and which doesn't. As the leading push for this tech is Microsoft, which has one of the worst security records, I wouldn't count on it being used for anything other than vendor lock-in.
- Add Merkle trees to the file system
So TFA's assertion here is that Operating Systems, and more specifically their File Systems, don't do enough to keep data on disk from being pieced together by a bad actor. Sorry, but that's not a very good solution since they already have access to the system, either physically or on-line. If they have on-line access then it doesn't matter - the OS will help them get the data; if they have it physically, well, disk encryption is a better solution (though painful and costly in performance).
- Build more block chains and extend them for others
- Add chaining to Internet interactions
TFA's argument - everyone should be like BitCoin.
Well, this could help communications some...but that's kind of already happening with encrypted communications, just not the way BitCoin does it. Still, that could make an interesting prospect, but that doesn't mean it's necessarily more secure. For instance, a MITM attack could still fool you since it would be able to talk to the other parties and make them both think the chain was intact properly; the attack surface would be reduced since the MITM attack would have to happen at the start of the connection; but then, any good MITM attack does that.
So all this really tells you is that the information send between two parties is a continuous flow of information; however, it has the issue that is completely serializes all communications (in order to create and preserve the chain) and that doesn't work for every protocol.
- Build out cross-linked certified websites
This is the basic idea behind key-sharing systems. Whether web-of-trust (PGP/GPG) or CA systems. In both cases you have to exchange information with a third (trusted) party to verify the information. It can help some, but it's no silver bullet by any long shot. See above for details.
- Add homomorphic encryption
More encryption. Yes, encryption can help, but it doesn't solve MITM attacks that use the encryption to their advantage - e.g by joining into the encryption stream. Yes, it makes MITM harder, but it doesn't prevent it.
That said, encryption is good; but it also means you need more powerful systems to meet the same performance requirements because encryption - and especially good encryption - is costly in terms of performance.
All that said, there is a better solution to any of the above - better programming practices that are designed around security. However, this requires retraining pretty much every software developer, the majority of which will complain that it takes away their ability to be artistic and thereby refuse to follow said practices. It also requires software producers (individuals and companies alike) to put security first in all software; but that too is unlikely to happen.
In programming, Security doesn't start with interfacing to other systems - it starts with making each individual function as secure as it can be; preferably not trusting anything more than it absolutely has to, validating all input and generating an error when the input is not within the specifications.