A little while ago I was working on a Wiki for my team at Supersynchronous. It’s designed such that multiple users can contribute to a communal knowledgebase in the spirit of sharing information and techniques that could be helpful for our diverse client needs. There’s some info that I wanted to keep handy that I wouldn’t be happy sharing publicly, and it felt like a shame that my sparkling new doc couldn’t be used for private info alongside the shared knowledge contributed to the team. I would have to keep my own info in a separate doc.
It was at that point that I wondered whether it’d be possible to encrypt information within a Coda doc in such a way that only I could decrypt it. Coming from a Web Development background, this is something I happen to have some experience in, but building a solution in Coda brought along… Some unique challenges…
Well it suffices to say I went completely down a rabbit hole, but making this Doc has been a ton of fun. If you’d like to discover how to implement encryption in Coda, or even just have a general interest in infosec, digital security, encryption or hacking, then I’d like to present…
this is a wonderful body of work on so many levels…
the ENCRYPTION functionality is brilliant and i cant wait to implement this myself
the long and DETAILED explanation of the process, its history, methods, caveats and warnings is EXEMPLARY. i am challenged to aim for such a high standards myself going forward!
the USER INTERFACE you have implemented is a full length TECHNICAL COURSE in itself! having struggled to build similar UX setups myself, i am VERY IMPRESSED with this work and will STUDY it in more detail anon.
the VERY HIGH STANDARD of document design, layout, clarity, explanation, and communication is one of the BEST i have seen in a Coda document.
and finally, the GENEROSITY with which you are sharing all this with the Coda Maker Community is in the very best traditions of the Open Source and Open Knowledge movements.
so on ALL those aspects, you have done an amazing job.
I’m wondering though. If I understood correctly, the purpose of the vault is that:
you can type in plain text
encode it
and then decode it back to view / edit etc.
Isn’t there at any moment a state when plain text is stored to the doc’s snapshot (e.g. in a temporary table) and one can find it through history or row activity?
@Jono_Bouwmeester
just wow! sooo many things I have not seen in a doc before and so many cool details. Love the different ways of how to use cards and espcially how to use colours. I use colours a lot but saw many new ways in your doc. Also love the info popups - so simple yet so effective!
@Xyzor_Max, holy cow. Thank you for taking the time to write such an amazing message. I’m deeply, deeply moved by your words. I’m publishing a template for encryption today, to make implementation far easier. I’ll keep you posted so you can have a look and hopefully use it for your future docs.
Thanks for the love, gents So stoked you’re finding the little nuggets I left in the doc. I’m launching a template for encryption today, then have a couple more docs and templates I’d like to push up over the next couple of days.
Ah @Paul_Danyliuk , you have hit the nail on the head. Version control is an issue I haven’t been able to work around fully yet. The vulnerability exists here:
While a user is typing their “secret” text into the table, version control could save a snapshot of the row. Now a malicious user would be able to “roll back” to that version of the doc, and retrieve partial unencrypted information.
That issue is something I’m working on, however I haven’t been able to find much documentation about how VH works in detail, so I’m just working off anecdotal info (and from what I see in Chrome’s dev tools )
After the point I mentioned above, I think the solution is safe. For example, when a user decrypts their secret, a notice is displayed telling them that the easiest way for them to re-encrypt the item is to use “undo” via the keyboard shortcut [Ctrl]+[Z]. In my testing, this effectively prevented version control from ever saving the item in its decrypted state.
That feedback is amazing. If you have any more info about VH, I’d love to pick your brain. Otherwise I’ll let you know if I figure out a workaround.
This one doc unveils so many secrets about you - your insane Coda skill level, your generosity for sharing with the community, your passion for design, your desire to push the boundaries - it’s all right there, for us to learn from. Thanks so much for publishing this, you’re just a star!
And, oh my, I have NEVER seen an interactive user-guide this beautiful in any Coda doc. Did I mention that you are a star?
Wow, this is stunning! I will be trawling this doc for weeks - no, months - to pick up every tip and trick I can. I love how much attention you have paid to the UI/UX - not only pleasing on the eye but well-organised and easy to follow. Among many other highlights, I am super-impressed with the user-specific ‘control panel’ row on your Wiki Vault page. I have been using the same concept in my docs for a while, but you have executed it here with so much more style and thoughtfulness than I realised was possible. A lot of inspiration for everyone here!
This is absolutely mind blowing!
Other than actually reading it and taking all the knowledge it brings (which is a TON of amazing things), all this community members will take a few weeks just trying to figure out this doc’s amazing interface!
Thank you not only for sharing all this knowledge with the community, but for do it in such a keen and elegant way.
One thing that comes to mind is volatile columns — they don’t get stored to the doc snapshot. However, inputs can’t be volatile — if you type e.g. a password into a cell or a control, it does get stored.
In a way, it is possible to e.g. make an “input” out of 10+ individual cells and prompt the user to type in the password letter by letter or whatnot. Then, the order of those cells would be governed by a volatile formula. This way if an attacker can see the individual letters, they won’t know the order in which those letters appeared. Not very hard to brute-force all the permutations though, so might not be worth it. But theoretically that is one way.
There’s also play mode… and there’s also the backend-frontend approach with two separate docs, like Viva Pizza. You could have the database in one doc but have an interface to access it in a play-mode doc.
Hey all. Eek, getting things right took wayyyyy longer than I anticipated, but I finally “cracked it” and have posted a template doc for incorporating per-row encryption easily into your own docs. If anyone’s still interested, here’s a link to my new community post:
@Paul_Danyliuk thanks for your feedback about Row Activity and your suggestion of looking into volatility as a possible path around it. In the end, I used Forms as a sandbox for the user’s sensitive information, and although it ended up being a fairly complex solution with a number of workarounds, I think a user would experience the workflow as simple and straight-forward. Would love to hear your thoughts if you have a few moments.
Once again, thanks for all the love and I hope this little contribution ends up being something you’ll each find helpful in the future.
and accept my APPLAUSE 
.
)