A keyboard is scanned by pulsing each row individually and checking which columns become active because a pressed key connects them. (Or vice versa.)
In (2), when the green row is pulsed, only the green column becomes active, because it's connected to the green row by the pressed key (upper left red dot).
In (4), when the upper of the two green rows is pulsed, both the green columns become active — the first because the upper-left red dot is pressed, and the second because there is a path through all three of the red dots (pressed keys). So the keyboard senses a key press at the dotless intersection, even though that key is not pressed.
Better keyboards solve this problem with a diode on each key, so that the roundabout path can't happen. Cheap keyboards rearrange the rows and columns into squiggly paths so that the three-key pattern doesn't happen very often, being especially careful with the modifier keys.
As I have mentioned somewhere else, I can't explain this by anything else than lazy design. Surface mount diodes are extremely cheap and their cost pales in comparison with the cost of accompanying switch or even LED.
You can't put diodes on a membrane keyboard. (Well, maybe you could, but the side with the traces is right up against the other membrane. Hmm, could you dope the membrane? brb, patenting) And if you did, the cost would still be greater than zero, so it wouldn't fly.
Ghosting on a discrete contact-switch keyboard is inexcusable, of course.
On most rubber dome keyboards there is enough space between rubbers to have diode there. You could also put diodes on the other side of PCB.
I am not sure about costs, though, I did not consider membrane keyboards for my research. Membranes are extremely cheap. Not just because of the membranes being cheap but also because there is no assembly (PCB is contacts, no assembly required for switches) and because there might not be need for double-sided PCB. In this case diodes could force double-sided PCB, vias, and maybe even double sided assembly.
Presumably the different colors paired with "so long as the keys in question fall into mutually discrete columns and rows." means they keyboard is actually "several keyboards" at the hardware level, and different keys activate different logic boards for processing.
Yes, actually, you can still determine the keys. The usual method is to scan the rows and/or columns one by one and then you always only have one row and column active at a time, so you can determine individual keys. However, if you strobe too slow you can miss keystrokes.
I also highly recommend "Reflections on Trusting Trust" by Ken Thompson. But if you read it, please also consider reading my dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)" at https://dwheeler.com/trusting-trust/ . My DDC paper discusses how to counter the attack.
Bookmarked! Thanks for writing such an interesting and relevant dissertation. I just finished reading the linked homepage, and will take a jab at your paper when I get some distraction-free time. But it really seems impressive.
"ProtonMail maintains and owns its server hardware and network in order to avoid trusting a third party. It maintains two data centres in Lausanne and Attinghausen (in the former K7 military bunker under 1,000 meters of granite rock) for redundancy. Since the data centres are located in Switzerland, they are legally outside of US and EU jurisdiction. Under Swiss law, all surveillance requests from foreign countries must go through a Swiss court and are subject to international treaties. Prospective surveillance targets are notified and can appeal the request in court."
"As of December 2018, FastMail and all other Australian companies are subject to the Assistance and Access Bill, which compells them to provide backdoors for accessing encrypted communications if warranted by law enforcement. The company stated that concerns over the bill has affected their business."
I request you don’t judge too quickly, Fastmail have responded that it doesn’t affect them directly and at the same time they are fighting for users on this on every front.
“As we have stated in the past, FastMail’s business is not directly affected by this legislation and we won’t be making changes to our technology or policies in response to this act.”
I don't know of one central resource that covers all of these topics. There are good articles on jemalloc and tcmalloc that discuss modern allocation strategies for general purpose allocators. There are articles from games development that discuss object pooling both in the context of C++ and in the context of optimizing GC languages like C# and Java as well as other specialized strategies like bump allocators, frame allocators, etc.
Resources on learning modern C++ cover RAII and resources on learning Rust cover its approach. There are good talks on the fairly new polymorphic allocator model for C++ that cover the motivations for it and use cases. Experience with modern C++ is valuable for understanding how much you can do with mostly stack allocation and how you can write non library code without ever writing a raw new or delete.
clang-format kinda does what it says - parses your code, then indents and spaces it according to the rules. It doesn't try to understand code intent, it just looks at syntax.
clang-tidy does some deeper inspection and can be used to flag things that are "bad practice", not just "bad formatting". There's a big list of checks here:
