Instead of 32 bits they could use the entire cache line. It is loaded from RAM to CPU anyway. It is 64 bytes / 512 bits.

Another link: https://github.com/vitaut/zmij/releases/tag/v1.0

Yes, that is correct. We were using C++ and COM and didn't protect ourselves against accidental exception being thrown across the COM boundary. But it never happened. Except the one case CString::Load (or whatever the function name was) failed because of Office visual style had bug in it.

You can always take a look how for example Windows 3.11 and earlier did it for their *.rtf file format and their "write.exe" editor / viewer / renderer (if you want to call it that way).

Yes, I know this. It took me long time to figure this out. My entire life I focused on technical skills / programming / math / logic. As I deemed them most important for the job. I was like: "Hey, if you cannot program, why do you work as programmer (you stupido)?" Only few years ago I realized that even as programmer (as opposed to sales man) you really need those "meh" soft skills. And that they are really important and I should not call them "meh". I'm very good at solving problems, improving product's performance, memory consumption, discovering and fixings bugs, security vulnerabilities. But I'm very very bad at communicating my skills and communicating with people in general. I'm not able to politely tell people that theirs idea is bad, I just say "that's stupid". And I'm mostly/sometimes right (if I'm not 100% sure, I don't say anything), but the damage caused by the way I say it is often inreversible. That post of mine about the job interview and CV was half joke and half reality. I just freeze/stutter when I'm asked something that is obvious because it is written I my CV. I'm immediately thinking "Did he not received the CV?" or "Did he not read it?" "Why the fuck is he not prepared for the call? Why are we wasting time asking me what should be obvious because I sent it in advance?" I'm more robot than human. Put me in front of problem and forget to tell me that it is impossible to solve ... and I will solve it. But easy small talk ... disaster. Communicating what the problem really was ... disaster. Communicating how I solved it ... disaster. "It was not working before and now it works fine, what the hell do you want from me now?" Yes, I'm very bad in team, in collective. I didn't know the reason why, but since few years ago I know the root of the problem. It's not that everybody around me is stupid and don't know basic stuff (what I consider basic), but me unable to communicate with other humans.

Yes, but (there is always a but) it does not apply if you implement off-line encryption. Meaning no on-line service encrypting / decrypting attacker provided data (such as SSL / TLS / HTTPS). Meaning if you are running the cipher on your own computer with your own keys / plaintexts / ciphertexts. There is nobody to snoop time differences or power usage differences when using different key / different ciphertext. Then I would suggest this is fine. The only one who can attack you is yourself. In fact, I implemented AES from scratch in C89 language, this source code is at the same time compatible with C++14 constexpr evaluation mode. I also implemented the Serpent cipher, Serpent was an AES candidate back then when there were no AES and Rijndael was not AES yet. The code is on my GitHub page.

This is true in real world also, not only in computer world or programming world. Think of steam engine, it enabled sooo much progress in other fields. Also invention of lathe and precision measuring and engineering. Before that, invention of "simple machines" such as pulley, bolt/screw, windlass, lever. The same in math, physics, chemistry and so on.

It is trade-off between convenience and security. With my approach stolen cookies are not usable from different computer / IP, the attacker needs additional work, he needs the victim computer to do the harm, his computer cannot do any harm. The downside is the user needs another log-in in case of his external IP changes. How often is it? Switch between mobile/WiFi. Otherwise ... almost never ... maybe 1x per day? I'm not proposing to log-out the user after IP change, I'm proposing to keep multiple sessions (on server) / auth cookies (on client) for each IPv4 or IPv6 prefix (let's say /56).

And that JavaScript has access to cookies, that’s just a basic part of how web browsers work. Lemmy can’t do anything to prevent that.

Yes and No. Cookies could be accessed by JS on the client. BUT. When the cookie is sent by the server with additional HttpOnly header, then the cookie cannot be accessed from JS. Look at Lemmy GitHub issue, they discuss exactly this. Lemmy server absolutely has power to prevent this.

Again, Lemmy can’t do anything about that. Once there’s a vulnerability that allows an attacker to inject arbitrary JS into the site, Lemmy can’t do anything to prevent that JS from making requests.

I believe they can. But I'm not sure about this one. The server could send a response preventing the web browser to request content from other domains. Banks are using this. There was an attack years ago when attacker created a web page with i-frame in it. The i-frame was full screen to confuse the victim it is actually using the Banks site and not the attacker site. The bank web site was inside the inner i-frame, the code in the outer frame then had access to sensitive data in the inner frame. I believe there are HTTP response headers that instruct the web browser to not allow this. But I'm not sure I remember how exactly this works.

completely independent backend

Yes, it would be more costly, but more secure. It is trade-off, which one is more important to you? In case of chat/blog/forum app such as Lemmy I prefer cheap, in case of my Bank website I prefer secure.