Suetonius, a Roman historian in the first century, wrote “The Lives of the Twelve Caesars” in the first century. In The Life of Julius Caesar he writes about one of the techniques Julius Caesar used for encrypting messages in approximately 50 B.C.
“There are also letters of his to Cicero, as well as to his intimates on private affairs, and in the latter, if he had anything confidential to say, he wrote it in cipher, that is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these, and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A, and so with the others.”
- Passage 56 of Julius Caesar , “The Lives of the Caesars”, Suetonius
Warning about editing Char Mapping table once in use
The encryption process involves summing the index of characters in the original Plaintext with the corresponding index of characters in the Key. The summed value is then used as an index to determine which character to use for the Ciphertext.
During encryption, characters towards the bottom of
often generate summed indexes that are “out of range” so have no character to map to. To fix this, we adjust the summed value “into range” by looping back to the start of the table to find a character for the Ciphertext.
table, decryption of these characters will become corrupted. The cipher relies on the indexes of characters remaining consistent for the encryption and decryption of rows, and also on the total number of rows being unchanged.
There are two options here:
Don’t add/remove characters once the system is in use. During initial setup, really consider what will be required, and stick to your decision after launch.
Or otherwise you will need to decrypt all secrets first before updating
You may have noticed that the Latin-1 Supplement Uppercase & Lowercase block is included by default, and may have wondered why (these characters are rarely used in English). I primarily included this block to help minimizing the corruption we’ve discussed.
During encryption, some characters end up “out of range” because the sum of their index and the corresponding character in the key’s index exceeds the available characters in the table. To map them to a character (in order to generate the ciphertext), we loop back to the beginning of the table. When the Count() of the available characters changes, these out of range characters end up decrypting to the wrong characters and we get corrupted text. This Latin-1 Supplement block therefore serves as a kind of “buffer” to help reduce the likelihood of this happening often when changes are made to the character mapping table.
Row Hammer relies on the increasing density and decreasing quality of DRAM chips, which are found in every smartphone, computer, IOT device, etc. Because the individual memory cells in modern RAM chips are so small, they’re prone to electrical coupling (basically, leaking their charge to other nearby cells). Manufacturers know this, and work around this phenomenon in normal use.
, works by carefully performing choreographed, patterned read-write operations to memory cells and “flipping bits” of the neighboring cells. This is a huge deal, because at a very low, hardware-level, exploits are able to circumvent hugely important OS restrictions like privilege separation and break out of their sandboxes. Suddenly a siloed task can affect the memory assigned to other tasks or even the operating system itself.
We really need to find a way to let the user add multi-line content to their item, and really the only way that’s anywhere decent is to direct the user to “big cell” mode.
A particularly nice way to do this is via an Enlarge button, which takes the user directly to the correct column’s “big cell” mode when clicked. I think the solution is from Paul D. Basically you take the row’s URL and append &columnId=xxxxxx&view=modal to the end of it. Then pass that url to an OpenWindow() formula within a button’s action.
The button solution makes the UI for getting to “big cell” mode far more intuitive.
The downside is:
If you pass the user to “big cell” from within a popup window, then when they click Done or Cancel Changes, they are not returned to the popup window they were previously on :(
This means that you can only really use the “Big Cell” mode button click solution from a button directly on the page (ie in a table, or from a canvas control). You can’t use the button click from a “popup window”
Unfortunately the popup window solution is the only way we can realistically show the user content from the card list view. Clicking a card ALWAYS results in a popup modal unless you build in a button. The caveat of using the button solution is that the user must know to click it, and never click elsewhere on the card.
So we are left with the final solution, which is the one implemented in this doc...
User clicks on a CARD and it launches a popup modal with a custom layout
Here we display the text content as a read-only column
To do this you just create a new text column, right-click on it and select “Add Formula”, then in the formula window just type thisRow.[Text Column] where [Text Column] is the name of the original text column.
By making this read-only, they never have to encounter the “pressing enter doesn’t add a line, it moves me to the next input” issue
Alongside the text is an Edit/View button. Because the text content is read-only, the user knows they must click that Edit/View button.
page where a “details” view is displayed on-page which is a DIRECT COPY of the popup window they were just working in.
Within a moment, the text column’s “Big Cell” mode is automatically launched.
Now, when the user closes “Big Cell”, instead of returning to a CARD LIST and getting lost, instead they see the DETAILS view of the row they were editing, and don’t lose their context.
I think this is a really seamless and intuitive way to enable multi-line text input. It’s a pity it’s SUCH a workaround, but nonetheless it’s really nice for the user so it’s worth it.
Some notes about this DETAILS page:
Advantages: we can include on-page warnings for when the user’s left their password in the row or left the item decrypted. Because this is a whole new page, we have space for additional UI if we ever need it
Disadvantages: we need to find a way to get the user back to the CARD view. This is relatively simple, but worth testing on real users to confirm it’s intuitive.