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.
Initially it was a combination of just for the fun of it (it's a small script, as OP described). Secondarily there was the feeling of "everyone is going to go work at [major competitor]" and I was curious whether I could collect the data to show it. (I never ended up looking into this, but maybe HR did.)
As a dumb script it was not designed to be especially flexible. One thing I remember needing to fix was that by its nature it was archiving old data and preserving it, which meant that it was accidentally deadnaming trans people. My recollection is this was a small code fix, but an interesting lesson in social consequences of oblivious software.
It's partly a cost saving exercise, but also: running "chroot /var/empty /some/shitty/code" or putting "chroot /var/empty /some/shitty/code" in inetd.conf is useful. (On today's super-fast machines,) Firecracker starts fast enough to support such interactive uses, while giving you the extra security of a VM (i.e. greatly restricts what parts of the kernel and/or localhost the shitty code can talk to).
Yes! After a bit of playing around, I can follow Rust reasonably well... but only with an IDE, which I've never used for C or even really for the bits of Java I wrote. I understand that many more experienced Rust developers are similarly IDE-reliant.
I do think it's a deliberate tradeoff, having e.g. .push() do something useful for quite a few similar (Vec-like) data structures means you can often refactor Rust code to a similar data structure by changing one line... but it certainly doesn't make things as grep-friendly as C.
