Picking anything but PlantUML's default theme will make PlantUML look less 90's-Java. As a minimalistic solution, I already like "skinparam monochrome true" https://plantuml.com/skinparam#:~:text=Black%20and%20White. (You can go further with CSS and themes and...)
I really like this article. I do think it's useful to consider that the unit of isolation ("process") of the cloud era is a VM or container, and that the major clouds do have some sort of permissions model.
The error rate is given per bit, not per second, i.e. every few bars represents a distinct DRAM chip. That makes some sense, and the article explains quite well why DRAM would behave like that... but I agree that I had to read the article at least twice to figure out that the x-axis on the graph represents the lower bit of the address line!
It's not ideal, but it's not a cryptographic risk.
Using an encoding that (like Protobuf) has multiple representations for a message may cause you problems if you switch implementations - sha256(encode(msg)) might yield different hashes on different implementations of encode().
But the main risk is an encoding that has multiple interpretations of a single encoding (e.g. sha256(encode("admin", "true")) == sha256(encode("admint", "rue"))), and Protobuf (can be unserialized, and thus) doesn't have that problem.
I was also thinking of promise pipelining, but note that the article proposes communicating A -> {B, C} -> D, never directly communicating from A to D. Cap 'n Proto "level 3" nodes could send promises from B and C to D, but that still needs A to talk to D, i.e. A -> {B, C, D}; {B, C} -> D. Same latency / depth of dependency chain, but still more messages - right?
(In return, note that Cap 'n Proto's A -> D message makes it more obvious how A figures out whether the operation succeeded; I'm not quite sure how that works in the proposed diagram. I suppose the proposed system actually puts all messages in a system-wide database, which does solve the problem.)
That should not be the case with promise pipelining. The "Mobile Almost-Code" section of the E page explains this. You mentioned "continuation passing style", which is effectively what promise pipelining does: For the constrained class of continuations that can be serialized as a dataflow graph, pass those along with the message.
Importantly, the system wide constraint is willing participation from each actor, not a shared database. Instead of each actor needing to know how to interact with the shared database, each actor needs to be willing and able to execute these passed continuations.
One pitfall to consider: software development is often its own culture, and nourishing and valuing (or merging!) multiple distinct cultures in a company requires real effort from leadership/management/team leads/senior ICs/...
I'm sure that e.g. truck drivers and software developers can be made into a strong team, but don't just assume that cross-culture collaboration will work "by accident"/"automatically".
Concur. In house can work wonderfully, but you have to get the dev team integrated into the soul of the business… and you have to be willing to bend when they tell you the current system is insane.
The GCM (or XSalsa, or...) nonce is not secret - in almost all protocols the nonce goes over the wire in plaintext! - but must be a number-used-once. Those are quite distinct requirements.
this is also notably true for pretty much all uses of IV/nonces/salts. They are intended to provide randomization to an otherwise deterministic process (similar to specific types of RSA/DSA padding) to avoid being able to brute force/easily determine the contents from known examples. For ex: known plaintext attacks being one common example.
It’s the same reason salts are used in passwords - there will be people using the equivalent of ‘password’, and without a salt it would be trivial to find them with just a lookup table (often in nearly O(1) time). With a salt it at least requires per-entry hashing of possible values per user, with no re-usability between users. So O(n^p) time (worst case) where n == number of users, p == number of possible values to test. A pretty huge difference.
Without the person on the other end having the value of the IV/nonce/salt, you might as well just stuff random bytes into the cyphertext field instead of the actual cyphertext, as if the algorithms are designed correctly they would be indistinguishable anyway.
All other things aside, if a bunch of articles get written about the phone, a lot of people think of Heineken ;-). I'm far from a marketing expert, but I have definitely seen less effective marketing campaigns.
