The question of how much CS curricula should focus on theory and fundamentals versus practical applications ends up being the broken record of Reddit and Twitter CS discourse every few months. Having taught a course that skews on the practical side of this spectrum, I strongly support efforts to incorporate practical skills into CS degrees.

But I also think that the discourse tends to treat the type of content that can be covered within a CS degree as a zero-sum game. Defining practical skills in opposition to the theoretical foundations of the subject is a false dichotomy; many courses, including those at Stanford, do successfully complement these fundamentals with their practical applications.

Rather, I think that there are a number of seamless avenues for CS programs to incorporate such practical skills into their existing, more fundamental courses. Moreover, with CS being a young and constantly changing field, we should also constantly reevaluate our understanding of what in the field we consider to be fundamental, and universities should update their curricula accordingly.

This is the third post in a three-part retrospective on teaching CS 40.

Teaching CS 40 was an incredible experience, and I’m proud of the impact we made in helping students learn how to implement their ideas on the cloud. It was my first time being the principal instructor of a course, and I learned a lot about teaching in the process – both in ways specific to CS 40, and more generally.

In this post, I share a number of reflections from the teaching process for CS 40. These are insights I would have loved to have known before the quarter started, and they inform some changes that I’d like to make before the course’s next offering.

This is the second post in a three-part retrospective on teaching CS 40.

With 50 students enrolled in CS 40 in Winter 2024 and only three members of the teaching staff, we knew that we would need to automate as much of the course management as possible. Given how novel our course material was, this necessitated building a lot of custom infrastructure, both for students to use, and for us to manage the course.

This is the first post in a three-part retrospective on teaching CS 40.

Last quarter (Winter 2024), Cody Ho and I taught CS 40 Cloud Infrastructure and Scalable Application Deployment at Stanford, a new course we’d been working on creating for nearly a year. CS 40 is Stanford’s first-ever hands-on intro cloud computing course, and with 50 students enrolled, achieving our instructional goals of leaving students with a robust understanding of the material was no easy feat.

Wrapping up the quarter, I’m thrilled with how the course turned out, even given how hectic it was at times. This post is a retrospective on the process of designing the course, getting it approved, and building out course content before the start of the quarter.

I acquired my personal domain saligrama.io in August 2018, and since then, I’ve used a number of different providers to manage its DNS records as well as the hosting infrastructure hanging off of it.

Recently, I decided to migrate as much of this infrastructure as I could to Cloudflare. This post describes the migration process that enabled me to move everything over smoothly without any downtime, all while using Terraform to systematize the resources with infrastructure-as-code.

Ever since I started exploring security more deeply, I’ve been asked countless times by people if I could hack into grading systems to change my (or, more often, their) grades. With Gradescope being the most ubiquitous platform for grading STEM classes at Stanford, my standard response was always that I couldn’t, imagining that a well-established EdTech company would secure their platform well enough.

As it turns out, Gradescope’s autograders have been vulnerable to various types of attack since 2016. Gradescope has known about the issues since at least 2020, yet has indicated it cannot distribute a general fix.

This post covers my exploration of Gradescope’s autograder vulnerabilities, an analysis of the potential impact on courses, and how I created Securescope, my attempt at a more secure autograder configuration.

In my last post, I covered the marvelous world of Firebase database spelunking: when app developers misconfigure their Firestore security rules, the resulting ability to perform unauthorized data accesses can lead to terrifying data breaches for those apps. Thanks to tools like Baserunner, testing apps for such misconfigurations is easier than ever.

By saving authorization state when logging into Firebase databases using email/password or phone/OTP sign-in methods, Baserunner lets you focus on actually querying the database for data. However, what happens when client apps only allow sign-in using a Google account?

This blog post covers how Glen Husman and I conducted security testing of such a Firebase client app, using a clever solution to grab the Google OAuth token to sign into the database with. I then used lessons learned from that engagement to contribute Google sign-in functionality back to Baserunner.

By shifting the data authorization and access restriction burden from robust programmatic systems running on a server to static security rules, backend-as-a-service platforms like Google Firebase put new app developers and their products at risk of catastrophic data breaches if utmost care is not paid to the efficacy of these rules.

This blog post details how to find such vulnerabilities in apps using Firebase as a backend. I also tell the story of one such vulnerability I found (along with Miles McCain and Cooper de Nicola) in Fizz, a popular anonymous posting platform at Stanford and other universities. Fizz’s improper handling of Firebase security rules allowed full deanonymization of all posts down to email and/or phone number and unauthorized granting of moderator permissions.

Lastly, I talk about legal threats we received in the course of disclosing these vulnerabilities.

This morning, an EternalBlue-vulnerable machine used for testing for Stanford’s Hack Lab course accidentally given a public IP address on Google Cloud was unsurprisingly pwned and used to launch further EternalBlue scanning against other public web hosts.

This blog post describes our course’s infrastructure setup (including why we had that testing box in the first place), how we discovered and remediated the incident, and how we used the incident as a way to teach students about incident response and public disclosure.

This is a continuation of my previous post about upgrading personal security. This post focuses on preventing evil maid attacks using disk encryption and secure boot.

With this post, I compiled and summarized all of the resources I used to do all of this configuration. The hope is that having a set of steps in one place reduces the need to go hunting across different Reddit posts, blog posts, and wiki articles as I did.

I’m someone who’s been reasonably technical for a long time, but was not really interested in security until about a year and a half ago. This means I had a lot of configuration set up for convenience, but without much in the way of security.

In the last few weeks, I started to change that and significantly upgraded my personal security. This post covers the first steps I took towards that end, starting with password generation and better two-factor authentication.

Test post for this blog.