Shomil Jain

Reverse Engineering BeReal

2022-03-31T00:00:00+00:00

Earlier this month, I was walking back from class with one of my friends when she recieved a notification on her phone: “Time to BeReal!” She quickly opened up the app that sent it, and subsequently took a front-facing photo of where we were and motioned to me to be part of a selfie of the two of us. Two seconds later, she clicked “post.”

I asked her what I had just taken part of, and she described to me how this new, viral social media app, BeReal, worked. Here’s an introduction to the app from Bloomberg:

At a varying time each day, BeReal users receive a single notification en masse prompting them to take two photos — simultaneous images, shot through the front- and back-facing lens on their phone cameras. Everyone is given two minutes to take the photographs, which are then shared with their followers on the app. People who miss the daily notification can post late, but such images are conspicuously marked for being tardy. To see everyone else’s contributions, a user must first upload their own daily shots.

There are no filters or “likes.” The underlying idea is that by giving users a short deadline, there’s little time for anyone to snap the perfect image. People can pose or quickly fix their hair, but more often than not users are compelled to share whatever is going on in their lives at that given moment, no matter how prosaic or unglamorous. On the app store, BeReal greets new users with a concise motto of sorts: “BeReal is life, Real life, and this life is without filters.”

I’m naturally suspicious of social media apps - so I told my friend this on the spot, and she responded with something along the lines of: “What do I have to lose? I’m already on Snapchat and Instagram and Facebook – why not be a part of this other platform too?”

And so I started to do some research. Here are some things that I found –

The app (and company behind it) seemed to be in its early stages. The features were barebones (but functional), and the website was minimal.
It closed a $30M (!!) funding round backed by Andreessen Horowitz (a16z) and Accel in June 2021. Back then, it had ~300K MAU, mostly in France.
The earliest mention of it in “the real world” I could find in my two minutes of scavenging was a reference to it in the Georgetown University’s student newspaper in November 2021 - interestingly enough, it was an anti-BeReal opinion article, which I found that I agreed with quite strongly.
It seemed to be going viral at Berkeley solely through word-of-mouth. I didn’t see or hear much about cross-posting (e.g. how Tiktok videos were quite often, and still are, cross-posted onto Instagram.)

So, naturally, I wanted to do a little bit of reverse engineering to see what exactly this $30M had backed! And so the rest of this article contains a walkthrough of my steps, thoughts, and takeaways from poking around BeReal using just an HTTP Request interceptor and a little bit of Python. Trivial reverse engineering, but quite revealing regardless.

I’ve translated all client-side requests into the Python Requests language for readability and mutability. I’ve trimmed out some of the standard headers as well. I’ve also fuzzed the request/response data PII - e.g. phone numbers, names, UUID’s, etc. - to make sure none of them map to actual user data.

And one final disclaimer: [1] I’m not a formal security engineer, so my poking around is from a software/architecture perspective, and [2] this is more of a privacy analysis than a security analysis. Some of these things may be secure by the application’s assumed threat model, but they may feel like a violation of the privacy that we expect from applications like these. I did not, at any point, “hack” BeReal, and do not intend to do so at any point in the future. My goal is purely pedalogical - to simply call out different privacy-oriented components of the design of a real-world application!

The /scanContacts Endpoint

BeReal offers the ability to scan your contacts. When asking for this permission, the app claims that your contacts are not uploaded + stored on their servers. That said, here’s an interesting request the app makes on the “Add Friends” page.

import requests

headers = {
    'Host': 'us-central1-alexisbarreyat-bereal.cloudfunctions.net',
    'Firebase-Instance-Id-Token': '...',
    'User-Agent': 'AlexisBarreyat.BeReal/0.20.0 iPhone/15.4 hw/iPhone12_3',
    'Authorization': 'Bearer ...',
}

json_data = {
    'data': {
        'phoneNumbers': [
            '+14087115196',
            '+91540222551',
            '+16103672510',
            '+12253535340',
            '+13588695809',
            ...
        ],
    },
}

response = requests.post('https://us-central1-alexisbarreyat-bereal.cloudfunctions.net/scanContacts', headers=headers, json=json_data, verify=False)

…and here’s what the response looks like:

{"result": [{"name": "Albert Ghar",
             "phoneNumber": "+14087115196",
             "photoURL": "Photos/L9Mk98Ftr3bskYPFEttXje9wPlH2/profile/L9Mm98Ftg3bskYPFEttXje9wPlH2-1646543857-profile-picture.jpg",
             "uid": "L9Mm98Ftr3bgkYPFEttXje9wPlH2",
             "userName": "albertghar"},
            {"name": "Steve Smith",
             "phoneNumber": "+16103672510",
             "photoURL": "Photos/VLECGzDHUhThPmnv0LubFHDGEKR2/profile/VLVCGzDHUhThPmnv0LubFHDGEKR2-1643954998-profile-picture.jpg",
             "uid": "VLVCGzDHUhAhPmnv0LubFHDGEKR2",
             "userName": "stevesmith"}
}

Discussion

I’m a little wary of this architecture. My contacts list has ~250 contacts, and the client made a request with ~250 raw phone numbers and, in a fraction of a second, spit out full name to phone number mappings for everyone who was on the platform, along with profile picture URL’s and user identifiers. It seems like this could be open to abuse: could one just pass in an arbitrary-length list of phone numbers (perhaps brute-forced), and, as long as the length of the list didn’t overflow the memory of whatever server is handling this endpoint, derive a list of all of the phone number <> username (and full name) mappings on this platform? That’s inherently bad architecture.

I also don’t like the fact that the app claims that contacts are not stored on the server. If a request is being made with a bunch of phone numbers, that request is probably getting logged somewhere, along with the authentication token of the user that made the request. Using this information, a BeReal engineer could presumably put together a dataset of users’ address books relatively easily.

The core engineering problem being tackled here has a name: “contact discovery.” It’s pretty common among social media apps. Different apps handle this differently - e.g. Snapchat and Facebook upload and store entire address books to their servers, so this is certainly one step better than that. But it’s far from what I’d consider “good” design.

The folks at Signal have an excellent blog post describing their approach to privacy preserving contact discovery - which is a method to allow Signal clients to efficiently and scalably determine whether the contacts in their address book are Signal users without revealing the contacts in their address book to the Signal service.

I don’t think BeReal needs to match Signal’s privacy standards - I think that’s an unreasonable demand. A “privacy preserving social media network” is a bit of an oxymoron - by signing up for this platform, you’re inherently volunteering some of your data away. But there certainly must be smaller, more incremental improvements (e.g. better rate limiting, more granular opt-in/opt-out around contact disccovery) that could be made to limit abuse here.

The /api/feeds/discovery Endpoint

Here’s another interesting endpoint. The homepage of this app has a Discovery tab, which allows you to discover the daily BeReal posts of users who choose to make their posts public. The endpoint used to query this information is the /api/feeds/discovery endpoint:

import requests

headers = {
    'Host': 'mobile.bereal.com',
    'User-Agent': 'BeReal/5063 CFNetwork/1331.0.7 Darwin/21.4.0',
    'Authorization': '...',
}

params = {
    'limit': '20',
}

response = requests.get('https://mobile.bereal.com/api/feeds/discovery', headers=headers, params=params, verify=False)

…and here’s the response:

{"lastIndex": "1648747266091-0",
 "posts": [{"bucket": "storage.bere.al",
            "creationDate": {"_nanoseconds": 846000000, "_seconds": 1648747267},
            "id": "NtLZ9OgIS0b2jdvy42Ob",
            "imageHeight": 2000,
            "imageWidth": 1500,
            "isPublic": True,
            "lateInSeconds": 1903,
            "location": {"_latitude": 44.913278, "_longitude": -0.644326},
            "mediaType": "late",
            "notificationID": "7k67KQCTgKD1Jiq_y6MDa",
            "ownerID": "AbfqcmwUmAWiM1j4vI7NONAwCHs2",
            "photoURL": "https://storage.bere.al/Photos/AbfqcmwUmAWiM1j4vI7NONAwCHs2/bereal/17750a05-d675-41fe-a505-5378dfdb34fb-1648747262.jpg",
            "realMojis": [{"date": {"_nanoseconds": 244000000,
                                    "_seconds": 1648747279},
                           "emoji": "😐",
                           "type": "neutral",
                           "uid": "gMRPfgbganNKJu12RGOK1SKwCiD3",
                           "uri": "https://storage.bere.al/Photos/gMRPfgbganNKJu12RGOK1SKwCiD3/realmoji/b85c9a9e-20c7-478c-8f94-7a874197aa58-vYU2ZFY3uiSDXCQB-neutral-1642222484.jpg",
                           "userName": "smallp"}],
            "region": "us-central",
            "secondaryImageHeight": 2000,
            "secondaryImageWidth": 1500,
            "secondaryPhotoURL": "https://storage.bere.al/Photos/AbfqcmwUmAWiM1j4vI7NONAwCHs2/bereal/17750a05-d675-41fe-a505-5378dfdb34fb-1648747262-secondary.jpg",
            "takenAt": {"_nanoseconds": 0, "_seconds": 1648747262},
            "updatedAt": 1648747279304,
            "userName": "gabipet"},
...}

Discussion

Let’s break this down. In the response, the app serves a random list of ~20 BeReal posts (e.g. from 20 users who’ve chosen to make their posts public). The metadata for each of these posts contain –

The post creation timestamp (and image capture timestamp), to high precision (nanoseconds)
The owner ID, which can be mapped into a full name using the /getUserNames endpoint
A list of realMojis, which contain reactions to the post made by the user’s friends (and the friend UID’s, along with the nanoseconds at which those reactions occurred)
The photo URL as a direct storage bucket URL
The latitude and longitude at which the post was taken, with precision to one meter.

Another interesting thing: if I replicate this query in Python, and re-run the cell containing the request over and over again, I get a new, random set of user posts each time.

So I wrote a little bit of code to hit this API over and over again. Nothing excessive: just 10 times, to simulate swiping down and refreshing the page 10 times (which is totally, in my opinion, within reason).

dataset = []
for i in range(10):
    for post in query_discovery().get('posts'):
        if 'location' in post:
            dataset.append([post.get('userName'), post.get('location')])
print(dataset)

…and here’s a sample of the dataset I collected in ~5 seconds. Again, I’ve randomly modified the usernames here (and locations) to protect user privacy. It took just 5 seconds to collect the precise latitude, longitude, and timestamp of ~150 BeReal users’ posts.

[['kaydne', {'_latitude': 40.017117, '_longitude': -105.28362}],
 ['cf14vc', {'_latitude': 43.70298, '_longitude': -72.290956}],
 ['raffh3', {'_latitude': 39.958509, '_longitude': -75.189487}],
 ['fatafa', {'_latitude': 43.138835, '_longitude': -80.266258}],
 ['maaiee', {'_latitude': 43.300878, '_longitude': -2.015236}],
 ['mefef5', {'_latitude': 48.106997, '_longitude': -1.689937}],
 ['ercten', {'_latitude': 48.147432, '_longitude': -0.391368}],
 ['cdan57', {'_latitude': 41.157043, '_longitude': -73.240702}],
 ['anaiff', {'_latitude': -32.371675, '_longitude': -54.164698}],
 ['holnss', {'_latitude': 50.772838, '_longitude': 0.264811}],
 ['nafhan', {'_latitude': 35.104979, '_longitude': -92.333383}],
 ['jaghss', {'_latitude': 42.733908, '_longitude': -84.483092}],
 ['loatli', {'_latitude': -34.434153, '_longitude': -58.594687}]
 ...]

Now one might argue that it’s OK that all of this data is public, since these users opted into making it public. So from a security perspective, this isn’t really all that interesting. But from a privacy perspective, providing this level of location/timestamp precision through an open API is worrying: this is sensitive user data! Why is it possible to extract so much user data with such ease? What if these locations map to people’s homes? Workplaces?

To take this one step further, while I didn’t include the post photos themselves in my toy dataset above, I’d imagine one could glean some information from the photos themselves. Each post contains a direct photoURL (back camera) and secondaryPhotoURL (front camera/selfie) – so it’d potentially be possible to extract even more information from the content contained within these photos (e.g. gender, ethnicity, socioeconomic status, etc.).

So considering that there’s hundreds of thousands (millions?) of BeReal users with public profiles, there’s an incredible amount of “scrapable” data here. That’s honestly kind of terrifying. It doesn’t really make sense as to why this much metadata is made available through this endpoint.

I also tried bumping up the limit parameter to ~40 instead of 20, and the response only returned 20. That’s good on BeReal’s part. Enforcing the limit per query on the backend is important.

The /friendSuggestions Endpoint

Ok, so this is the scariest section of all. Be warned.

This app contains an “Add friends” page. On this page, the client makes a request to the /friendSuggestions endpoint that looks like the following:

import requests

headers = {
    'Host': 'us-central1-alexisbarreyat-bereal.cloudfunctions.net',
    'Firebase-Instance-Id-Token': '......',
    'User-Agent': 'AlexisBarreyat.BeReal/0.20.0 iPhone/15.4 hw/iPhone12_3',
    'Authorization': 'Bearer .....',
}

json_data = {
    'data': {
        'friends': [
            'OaomHuKxYYMJimflUNbkm1rPXsy1',
        ],
        'toExclude': [],
    },
}

response = requests.post('https://us-central1-alexisbarreyat-bereal.cloudfunctions.net/friendSuggestion', headers=headers, json=json_data, verify=False)

…and the response looks like the following:

{"result": [{"uid": "6xqLArEVbkM6WEwPpltM2k8ddJx2",
   "userName": "stevesmith",
   "countCommon": 1,
   "commonFriends": [{"uid": "OaomHuKxYEMJimflUNbkm1rPXsy1",
     "userName": "shomiljain"}],
   "name": "steve smith",
   "photoURL": "Photos/6xqLArQVbkMEWEwPpltM2k8ddJE2/profile/6xqLArQVbkM6WEwPpltM2k8ddJx2-1647191E36-profile-picture.jpg"},
  {"uid": "tD3qMoEfFHdMJVJqHIhT8moaMBl1",
   "userName": "ironman",
   "countCommon": 1,
   "commonFriends": [{"uid": "OaomHuKxYYMJGvflUNbkm1rPXsy1",
     "userName": "shomiljain"}],
   "name": "Tony Stark",
   "photoURL": "Photos/tD3qMoXfFPdMJVJqHIhT8moEMBl1/profile/tD3qMoXfFPdMJVJqHIhT8moaMBl1-16486F2975-profile-picture.jpg"}
 ...
}

Discussion

Intuivitely, how would a friendSuggestions endpoint work? Well, given a list of your friends, it would tell you who your friends are friends with, sorted by the number of mutual friends you have with each of your friends’ friends. (That’s a bit of a toungue twister.)

But here’s where things get interesting: if we only pass one friend into the friends parameter of this request, then this basically reduces to just finding all of the friends of the given friend that we pass in. (I confirmed this behavior by running this endpoint on a few of my friends - with permission, of course - and asking them to confirm the endpoint’s output was correct.)

So what are the implications of this? Consider these ~10 lines of code I wrote.

from collections import defaultdict

tree = defaultdict(set)
visited = set()

fringe = [('2czmn8Ce1jA6ZHt0GUHWS25iWug1', 'joshhug')]

while fringe:
    neighbor = fringe.pop(0)
    print('exploring neighbor:', neighbor[1])
    for friend in get_friend_suggestions([neighbor[0]]).get('result'):
        friend = (friend.get('uid'), friend.get('userName'))
        tree[neighbor].add(friend)
        if friend not in visited:
            fringe.append(friend)
            visited.add(friend)

If you’ve taken an introductory CS class, these lines of code should look familiar - this is BFS! We start by exploring a single user (joshug, here, who’s a hypothetical user) - and we work our way outwards in a breadth-first manner. Using this, we can pretty much..leak the entire BeReal network, assuming we run this code for long enough.

As a proof of concept, I ran this code for ~1 minute, starting at my friend’s user ID (who goes to UC Berkeley). Here’s what the results look like –

On this graph, each node is a user. Each edge is a “friend” relationship between two users.

Now if each user had ~500-1000 friends (e.g. on a platform like Facebook), the results of this endpoint wouldn’t be all that exciting. There’d be a lot of noise; you’d be able to create some sort of social web, but it would be incredibly dense.

But on BeReal, the app, by nature, is meant for just you and your close friends. So inherently, you’re telling BeReal (and now, let’s say, everyone) who your closest friends are. This is really important: it’s a bias built into the platform itself that amplifies the effect of this discovery.

Which means that it’s possible to discover the closest friends of pretty much every single user on this platform, including those that think they’re protecting their privacy by choosing to keep their posts private.

If I wanted to get super Black-Mirror-Esque, I could replace the little blue dots on these pictures with these user’s profile pictures and full names. And for those who opted into attaching their location to their posts (which, as I noted above, seems to be a non-trivial number of users), I could throw in a location dimension as well.

Takeaways

For people who’re going to be building systems that are used by many people at scale –

Designing privacy-preserving software is hard. There’s a lot of focus on very specific parts of software security: preventing unauthorized users from accessing application data, or defending against code injection/cross-site scripting/path traverrsal attacks/memory safety attacks (where appropriate, of course). But sometimes the most obvious attacks aren’t related to these at all: they’re nuances in your software architecture that have significant privacy implications, even though your application may still be “secure” by technical standards.

And more generally –

It’s one thing if you’re giving your data to a company whose products and services you pay for (e.g. Apple). It’s another if you’re voluntarily trading your data in exchange for a free service (e.g. Facebook). But it’s an entirely different thing if you’re unknowingly making your data available to anyone who’s passed CS 61B @ UC Berkeley.

An automated extensions pipeline for large CS classes

2022-01-29T00:00:00+00:00

This post is cross-posted from the README of this project’s GitHub repository. It’s a work in progress, so I’d refer to the README for the latest documentation on how this works!

The CS 161 Extensions Pipeline is a lightweight framework designed for tracking, approving, and managing extension requests in medium and large classes (e.g. N > 50). It’s optimized for courses in the EECS department at UC Berkeley, but is extensible to other departments and universities.

At a high level, this pipeline consists of:

A Google Form that students submit extension requests to.
A Google Sheet that collects student extension requests and tracks all extension requests in a master roster.
A Google Cloud Function that contains core business logic that:
- Receives form data through a simple Google Apps Script trigger.
- Process form data in combination with a student’s “record” (which includes DSP status and prior extension requests) to enter either an auto-approval or manual-approval flow.
- Sends updates to staff through a Slack Webhook, enabling simple internal discussion of student cases through Slack threads.
- Sends updates to students through the CS 162 Mailserver via CS 61A’s RPC Interface.

Background

Traditional Flow

Traditionally, courses deal with two types of extensions –

DSP Extensions, for students with accommodations for assignment extensions
Non-DSP Extensions, for students facing extenuating or otherwise unforeseen circumstances

Courses traditionally collect extension requests through Google Forms (e.g. ones provided by course managers, like this one) or via email. In order to approve these extensions, however, courses (or course managers) need to:

Read the student’s request and categorize it into a DSP or Non-DSP extension.
Look up whether the student has previously requested assignment extensions.
Either (a) update the student’s requested extensions in a central spreadsheet, or (b) update the student’s requested extension on Gradescope/OKPY/PrairieLearn.
Send an email to the student containing an “Approved” message, with a new due date.

Challenges

The traditional flow results in several challenges, including:

High potential for human error. In every manual step, there’s a chance for data entry errors that are capable of propagating downstream; in CS 161/CS 61C, we saw a large number of these that arose at the end of the semester when generating final grade reports.
Communication difficulties. For classes that outsource work to course managers, there are three parties with different views on extension data: what course managers see, what course staff see, and what students see. All communication, by default, needs to be inclusive of all three parties; if even one email is two-way instead of three-way, then information is “lost”.
Delayed processing times. Because of the number of manual steps required here, it can take several days for students to hear back on whether or not their requests were granted, leaving them in a state of stress and uncertainty.
High barriers to requesting extensions. Because there are so many steps in approving each extension, there’s a tendency to write strongly-worded policies discouraging most student extension requests.

The CS 161 Extension Pipeline addresses all of these challenges, significantly reducing course staff workload while simultaneously improving quality-of-life for students.

Our Pipeline: Student Workflow

Students request an extension through a Google Form (see an example here).

If a student knows which assignments they want to request an extension on, then they’re prompted to select from a list of assignments, and provide a number of days for each extension. They can either enter a single number (which will apply to all assignments that they select), or enter comma-separated numbers (to allow them to request a different number of days for different assignments).

If a student’s working with a partner, then they’re asked to enter their partner’s email and SID. Their partner will be included in extensions for any assignments that they select which are marked as partner projects.

If a student doesn’t know what assignment they need an extension on, they can request a meeting with a TA. We’ve seen this happen for students who’re in extenuating circumstances, and just need to talk through their situation before deciding upon a specific request.

If a student’s a DSP student with an accommodation for assignment extensions, they can declare that on the form. (We recommend that all students who fall under this category receive auto-approvals for extension requests fewer than 7 days.)

When a student’s request has been approved (either manually or automatically), students receive a templated email with their updated assignment deadlines.

…and that’s it for students!

Our Pipeline: Staff Workflow

Staff view all extensions on a master spreadsheet, with two main tabs: a Form Responses tab, which contains all form responses from students, and a Roster tab, which contains a list of all students in the course, with a column for each assignment. The Roster looks like this:

When an extension request comes in, staff first receive a Slack message in a private Slack channel.

If an extension request falls into an auto-approval category, the message contains a summary of the student’s request, as well as a list all of their granted extensions.

When an extension is automatically approved, staff don’t need to do anything!

If an extension request requires manual approval, the message contains a reason why the request couldn’t be auto-approved.

When an extension requires manual approval, staff should read the reason for the extension, and discuss the request (if needed) in the Slack thread, escalating the case to other staff (e.g. instructors) if necessary.

If the extension warrants an approval, staff should:

Set the approval_status column on the Roster to “Manually Approved”.
Set the email_status column on the Roster to “In Queue”.
Use the Actions => Dispatch Emails menu item to send emails to all students in the queue. This will send emails out to the students in the queue, removing them from the queue as emails are sent, and send an update to Slack when all emails have been sent.

If the extension does not warrant an approval (or staff need more information), staff should:

Follow up with the student over email.
Clear the approval_status column on the Roster.
Set the email_status column on the Roster to Manually Sent.

If an extension request contains malformed data or any other error occurred, the message contains a description of the error, along with the entire form response.

When an error occurs, staff should:

Correct the error on the Form Responses sheet (or, if it was an internal error due to other data misconfiguration - e.g. missing assignments - correct the configuration).
Select the Reprocess checkbox next to any form responses that weren’t fully processed.
Use the Actions => Reprocess Form Submissions menu item to reprocess the failed submissions.

If a student requests a student meeting, the message contains a description of the student’s request.

If, during a student meeting (or through some other channel, like a Piazza post), staff would like to grant a student an extension on an assignment, staff should enter the number of days to extend the assignment by directly onto the student record on the Roster, and throw the student record in the queue for outbound emails. This is a natural “form bypass” case, where a form submission isn’t required to grant a student an extension, but these specially-granted extensions are still tracked alongside the rest of the student’s extension requests.

Configuration

All configuration values (e.g. API keys, email options) are stored on the spreadsheet itself, in the “Environment Variable” tab.

Assignments may be dynamically configured as well, through the “Assignments” tab.

Edge Cases & FAQ’s

In what cases are extensions flagged for human approval? These cases are flagged for human approval:

The student requests a large number of extension days for any single assignment. This threshold is AUTO_APPROVE_THRESHOLD and AUTO_APPROVE_THRESHOLD_DSP for students with DSP accommodations for assignment extensions.
The student requests extensions for a large number of assignments. This threshold is AUTO_APPROVE_ASSIGNMENT_THRESHOLD.
The student record has “work-in-progress” (e.g. the row on the roster is red or yellow - the student either has an existing pending request or ongoing student meeting).

All other cases are auto-approved! See here for the logic that handles these cases.

How do I make it so that all extensions (regardless of status) require manual approval? If you want tighter control over what’s approved, set AUTO_APPROVE_THRESHOLD to 0 and AUTO_APPROVE_THRESHOLD_DSP to 0. It doesn’t matter what you set AUTO_APPROVE_ASSIGNMENT_THRESHOLD to.

What if a student submits an extension request with a partner? Any requested extensions for assignments that are “partner” assignments will apply to the designated partner as well as the student. Both student records will be updated on the Roster, and the logic for approval will apply to both partners (e.g. if Partner A submits the form and Partner B has a “work-in-progress” record, then the extension as a whole will be flagged for manual approval).

What happens if this thing internally combusts in the middle of the semester? While unlikely, this is a very simple failover case: just process form submissions into the Roster spreadsheet manually, and send templated emails through something like YAMM.

Wait, I still have to update the student's due date in OKPY/Gradescope/PL so that they'll be able to turn in their assignments late, right? You could do this (manually) after each extension request, if you’d like. Alternatively, you could set the “late” due date on these assignments to the end of the semester, and use the extension data on the Roster during grade compilation (this is what CS 161 & CS 61C do). Students will see their assignments marked as “late”, but they’ll be able to use the email they received as proof of their granted extension, just in case they notice inconsistencies in their grade reports.

What about long-term maintenance? Due to the simplicity of this project’s architecture (no frontend, configuration is entirely dynamic, etc.), we don’t anticipate this project needing a lot of long-term maintenance! And feature requests are simple to add, since the code is well-documented with Python class abstractions.

What if I want to change an assignment deadline after extension requests have already come in? You can handle this in any way that you’d like! Two common approaches –

Clear out previously-assigned extension requests, and email all students who had requested an extension to re-submit an extension if they need more days past the extended deadline. To clear out existing requests, just clear the assignment column on the Roster.
Apply all current extension requests to the new deadline. For this, update the deadline in the Assignments tab, filter the Roster to all students with an extension request for the assignment, and add all rows to the email queue; then, dispatch emails. All students who requested an extension will receive a new email with an extended deadline that’s adjusted to the new deadline.

How the Internet Works

2021-12-30T12:00:00+00:00

View externally.

Creating an Inclusive Course Environment

2021-12-25T00:00:00+00:00

This post contains tips on how to create an inclusive course environment. Much of this perspective on pedagogy has been sourced from conversations with some of CS 161’s veteran TAs - Peyrin Kao, Vron Vance, Nicholas Ngai, Fuzail Shakir, and others - as well as from the professors who’ve taught CS 161 over the past few semesters: Nicholas Weaver, David Wagner, and Raluca Ada Popa.

This is a work-in-progress. If you have comments, shoot me an email at shomil@berkeley.edu or ping me via Slack.

Feedback

Ask for feedback, and ask for feedback often. I’m starting with, arguably, the most important tip - even if you ignore everything else in this post, please, please do this. Many of the tips I’ve noted here are based on thousands of data points collected through feedback that we’ve sourced directly from students.

In CS 161, we ask for feedback in two critical places: at the end of each homework assignment in a free-form text box, and immediately after an exam takes place. Asking for this free-form feedback allows us to interface directly with students & resolve concerns as they arise.

Here’s the question we use to ask for feedback, and an example feedback submission we received from one of our students:

We have a script that scrapes this feedback from Gradescope and dumps it into a Google Doc, which we then review at our weekly staff meetings.

Occasionally, concerns raised through feedback may be significant enough to warrant a standalone “response” post. Here’s one that David Wagner posted in the Spring 2020 iteration of CS 161, back when I was a student:

These feedback channels are also a critical component to making students feel heard & building a community in which people feel included, aren’t afraid to ask questions, and share their frustrations constructively (as opposed to destructively). Here’s an example of feedback (and response) from one of our “How did the midterm go?” posts earlier this semester.

Aside: for the particular issue above, we course-corrected for the final by dedicating more time/care towards exam pre-testing and having more TA’s in the clarifications room.

Content

Deliver content through multiple forms, if possible. Over the past few semesters, we released a course textbook to supplement and enhance lecture. We did this to support students who better understand content through text (as opposed to verbal/graphical content delivered through lecture & lecture slides). This semester, I also put together a Networking 101 slide deck that covers the foundations of networking in more depth than our traditional lecture slides - this was also well received by students.

Not everyone learns the same way – so if you’re able to provide several different methods of digesting course content, then do so.

CS 170 does this really, really well (they offer lecture, reading, section/section walkthrough, mini-lecture/conceptual walkthroughs, and assignments/assignment walkthroughs).

Also, collect data on what works for students - and put TA hours toward building out the things that work. We polled students on how helpful they found the textbook in SU21 and FA21 (while we were actively developing it), and we saw an increase of nearly 20% of students who rated the helpfulness of the textbook a 4/4.

People generally like video walkthroughs of things. Our video walkthrough for Project 1 (1300 views) and Project 2 (900 views) were among our most-viewed videos for the entire semester. We have a hunch that these were particularly helpful to students who were conceptually behind and/or felt lost – considering we had only 600 enrolled students, it seems many students referenced these videos several times.

Logistics

Be lenient with extensions. Life as a student (especially at UC Berkeley) is often fatiguing, chaotic, and incredibly stressful. As instructors, many of the things we do directly and indirectly affect our students’ mental health. If we’re given opportunities to reduce student stress (e.g. through a one or two-day extension, a few added slip days due to power outages, etc.) – we should do everything in our power to make it happen.

One strategy: when planning your course schedule at the beginning of the semester, throw in a scattering of buffer days – and as the semester progresses, sprinkle a few random (intentional) extensions in as your “surprise” stress-relievers. And on that note, here’s an example of what not to do.

Be wary of what and when you’re email-blasting. Be cognizant of what times you’re email-blasting information – especially sensitive/important information. Blasting exam grades at 9:30 PM on a Friday might not be a move…perhaps wait until Saturday morning for an email blast. Here are a few other tips related to email blasts:

Ask for ACKs from at least one other TA before email-blasting something.
Send out a consistent weekly announcement that contains assignments & due dates for the week.
Try to keep email blasts to 1-2 a week.
On that note, use targeted emails instead of email-blasting when possible (e.g. if a discussion attended by 30/1000 is canceled, it’s probably not worth pinging all 1000 students).

Kind words are important. In 161, we ask our proctors to run down a list of announcements at the start of an exam – and the very last announcement is always a set of kind words (e.g. “You’ll all do great!”). Similarly, we try to begin and end our email blasts with a few kind words as well, rather than going straight to business.

Try to build in support for one-on-one meetings with students. We have a few TA’s who dedicate a few of their hours towards these meetings each week - and they say every one of these meetings ends with the student saying something like “this has been so helpful, I was really stressed out before the meeting and now I am in such a good place and ready for…”. The difference between a private Piazza post or email and directly speaking to a struggling student is astounding. Discussions with & observations of these meetings in larger courses (e.g 61B, 61C) suggest that the effectiveness of these meetings require complementary extension-related course policy to scale as well (related: see these tips).

Piazza

Give people updates on what’s happening on Piazza, instead of leaving posts unresolved for a long period of time. Try to make sure every single post & followup has a response. One thing that we use that I’d personally love to see in other classes: if you’re blocked on immediately resolving a post or don’t know what the answer is, then respond with a quick “Investigating” or “I’ve pinged XYZ to look into this” so students don’t think you’re ignoring posts. I think this might be especially relevant for megathreads & debugging-related posts that may go unresolved for a longer amount of time.

Instead of flat-out rejecting student demands, compromise wherever possible. Here’s an example: we release grade reports three times throughout the semester - after the midterm, before the final, and after the final. In our first round of grade reports, we received feedback (through our HW feedback channel) that percentiles were causing a stressful, competitive environment, where people were forced to compare themselves to their peers when looking at their grade reports. As such, we took these percentiles out in the second round. This immediately received pushback on Piazza – to which, we re-discussed and released this:

Be transparent. Earlier this semester, we released a buggy autograder, with some students receiving lower-than-intended scores. When we re-released grades a few days later, we posted this note along with our update.

Website

Have a centralized course website as a source of truth. Try to avoid scattering information across Piazza, Google Docs, emails, and a website - just put everything onto the website, and attach links to the websites from other sources. A clean web frontend is much, much better than a Piazza post or a Google Doc - and it’s certainly easier to find.

Put all important course links on your site’s homepage. This includes things like a standardized form to request extensions (here’s an example) and the office hours queue.

Please don’t conflate cheating with collaboration in your course syllabus. An earlier iteration of the CS 61C syllabus contained this note: We don’t want you sharing approaches, ideas, code or whiteboarding with other students.

At the time, it blew my mind that an introductory-level CS class at a top-tier university had an outright ban on whiteboarding with other students. Of course, this was in the context of academic integrity around course projects - but the specific wording that this particular policy used seemed (from my perspective as a student) cut-throat, competitive, and anti-collaborative.

I thought CS 184’s “Learning Cooperatively” section from the Spring 2021 syllabus was worded quite nicely: With the obvious exception of exams, we encourage you to discuss course activities with your friends and classmates as you are working on them. You will definitely learn more in this class if you work with others than if you do not. Ask questions, answer questions, and share ideas liberally.

And…again, the context here is a little different (e.g. upper-division vs. lower-division course), but my point here stands: emphasize collaboration in your syllabus, rather than denouncing it under the guise of “academic integrity”.

Exams

Always, always, always simplify student-facing logistics. When designing policies, procedures, and other student-facing documents, keep things simple - as simple as possible. The most critical example of this: exam logistics should never exceed one page. Here’s an example of what to do, and what not to do. Both of these examples are from Fall 2021.

During the early days of Zoom proctoring, proctoring policies sometimes exceeded ~12-17 pages (yes, this really happened). Creating excessive hoops for students to jump through distracts from actual course content – not to mention that we can achieve the same degree of effectiveness through a one-page policy.

Make the exam-taking experience as smooth as possible. Here are a few easy-to-catch things that we look for in our exams to make the experience better for our students:

If you’re offering hybrid exams, pay close attention to equity across formats (e.g. limit short-answer questions to one sentence, so you’re not giving fast typers a significant advantage).
When pre-testing, print out the exam. Sometimes, how pages line up influence the exam taking process (e.g. question on the front of a page, with the answer box on the back).
Try to stay away from using big, convoluted blocks of text. Keep sentences short & concise to ensure the focus remains on course material.

Exams shouldn’t leave students feeling depressed. Follow Dan Garcia’s tips on writing good exam questions. A few major recommendations –

Strive to make questions have a balance of A-level, B-level, and C-level questions.
Every student should get some credit on each problem.
Most problems should have a “fun” part that makes students think.
Try very, very hard to keep exam means around 50-70%. Opening Gradescope to see a 30/100 is something that does impact a student’s mental health. I’ve been there - it really sucks to be in a position where you’re being told that you only “understood” 30% of a course, even if the overall class mean is low.

Allow students to discuss/ask questions about exam rubrics on Piazza, instead of taking a stance of “course staff knows best”. Here’s the message we post on Piazza: As always, it’s certainly possible that we may have made mistakes in grading. Please submit a regrade request if you spot an issue with how we applied the rubric to your submission, and feel free to leave questions (and any other exam-related feedback) in the follow-ups to this thread.

When discussing regrades, student-facing tone matters - a lot. Use neutral/positive phrases like “definitely open to hearing second opinions about this”, or “I don’t think we can give points for [X] here”, instead of negative/combative phrases. Regrade requests shouldn’t be an “us-vs-them” battle to the death; listen to students, try to hear their perspective, and share your own perspective until you’re able to reach a satisfactory conclusion.

Add a course bot! A few of our TA’s have been developing EvanBot (along with a pretty integrated course storyline) over the course of the past few semesters. Here are a few of Bot’s capabilities: making sensitive remarks about grading, responding to logistics requests in humorous ways, and sliding in a sly comment or two.

Internal

If you’re a head TA, these are a few things that have worked well on 161 staff.

Emphasize transparency. We’ve seen significant value from discussing admin-level logistics with our entire staff (e.g. much of our proctoring policy was crafted in a staff meeting a few semesters ago, and our 8-hour TA’s frequently contribute to decisions regarding course policy/workload and exam design). Creating barriers & hierarchy among staff degrades staff cohesion, reduces operational efficiency, and just doesn’t work well. We’re not Apple - we’re a bunch of (under)graduate student instructors just trying to teach our peers.

Keep roles flexible. If someone turns out to be really good at something, then let them work on that - even if it isn’t their official role. And, of course, reallocate other staff hours towards reducing their pre-assigned burden, if they’ve found something that they’re able to do really really well.

Keep hours flexible for office-hours “on-call” requests. This is super important during project weeks - if the queue is long, whoever’s assigned to a particular slot should ping Slack with a @here requesting assistance. Set an expectation for TA’s to dedicate a few staff hours towards being “on-call” during crunch weeks, and doubling up or stacking busy office hour times.

A Few Additional Resources

Reverse Engineering 101 - How to Hack Snackpass

2021-11-02T00:00:00+00:00

Here’s a pretty neat presentation I gave on reverse engineering!

CS 161 (Computer Security) Fall 2021 - All Resources

2021-08-30T12:00:00+00:00

Hey! I’ll be using this page to post resources from my 161 Discussion Section for Fall 2021.

I’d appreciate your feedback! If you have any thoughts on my section, please fill out this anonymous form - or, shoot me an email (shomil@).

If I haven’t posted slides for the most recent discussion yet, feel free to view my slides from previous semesters. For the most part, they should be similar!

Discussion Resources

Discussion	Resources
Discussion 1	Slides (x86, GDB, Security Principles)
Discussion 2/3	Slides (Memory Safety)
Discussion 4	Slides (Intro to Cryptography)
Discussion 5	Slides (Crypto II)
Midterm Review	Slides (Memory Safety)
Discussion 7	Slides (SOP, Cookies)
Discussion 8	Slides (SOP, Cookies, CSRF, XSS)

Out of scope, but still highly recommend: Reverse Engineering 101

Also, here’s my Final Review Sheet from Spring 2020. Disclaimer: I made this when I took this class and haven’t really looked at it since, so there might be a typo or two! It also might not fully encapsulate the scope of this semester’s final.

My CS 184 Course Notes

2021-05-14T17:00:00+00:00

I took CS 184 (Computer Graphics) in Spring 2021, and I wrote up my notes from the course here!

EECS 101 - a Repository of Crowdsourced Course Advice

2020-11-25T05:00:00+00:00

As course advising at UC Berkeley has shifted to a predominantly online format, the popularity of the EECS 101 Piazza for course & advising-related inquiries has increased rapidly. Over 4,000 students actively browse the forum, in search of everything from waitlist-related questions to workload discussions and extracurricular opportunities.

One of the biggest bottlenecks on this forum - something that applies to Piazza in general - is the lack of functional search. Searching for even simple queries yields widely inaccurate results. Piazza seems to use some combination of exact word matching and time-based sorting - and it’s incredibly frustrating for anyone trying to search for answers in a repository of over 13,500 Q&A posts.

This past week, I decided to do something about it - I launched https://eecs101.org/, a site that indexes content from EECS 101 and serves it in a clean format with robust search & filter capabilities. Below, I walk through the process of approaching this.

View this project’s source code here.

Evaluating Search Functionality

Search Query: “188 vs 189”

Search Query: “170 Workload”

Search Query: “CS 161 Waitlist”

Extra: How I Built It

1. Acquiring the Dataset: Scraping Piazza

To scrape Piazza, I used this open-source unofficial Piazza API. I let it run for about an hour and a half with a one-second delay after each API call to avoid rate limits. I saved posts to a local TinyDB JSON database as a form of temporary storage.

See the source code here.

2. Tokenizing the Dataset

To assist with rapid search functionality, I decided to extract key tokens from each post ahead of time. For the time being, this includes professors and courses - but more metadata tokens could be extracted at this step.

The logic for this token extraction is simple - it simply uses an extract_tags function, which looks to find and replace keywords (without replacement) in order from longest length to shortest length.

Example: if {CS 189, CS189, 189} are keywords that correspond to token CS189, then we search for CS 189 first, then CS189, then 189 - and if any of those match, we remove them from the search content temporarily and update the post’s tags while scanning for other keywords.

See the source code here.

3. Building a React Frontend

To build a quick frontend, I took inspiration from Berkeleytime’s format & style. For formatting, I used four main react components:

TabBar, to hold the navigation bar.
FilterView, to hold the search bar and any filters.
ListView, to hold a list of cells with search results.
DetailView, to display the post content.

Nothing too complex here.

4. Building a NodeJS/Express Backend & Implementing Search

To build a quick backend, I created two endpoints using NodeJS/Express – a /query endpoint, which queries the my cached Piazza database for a list of posts given search content/filters, and a /content endpoint, which queries the database for actual post content.

This is where the majority of the search logic was implemented - I added support for a handful of different search types, and optimized particular types (e.g. auto) to support entity extraction on the search query itself.

5. Connecting the Frontend/Backend with Redux

I used React-Redux to connect my data stream & API calls to React components.

6. Deploying the Site to Heroku

I deployed the site to a Heroku dyno!

SWE Portfolio - Mobile Apps

2020-10-01T00:00:00+00:00

Projects

Orbit Apps (Bear Central, LGHS, etc.)

Links: Bear Central (UC Berkeley), LG CATS (Los Gatos High), Orbit (Generic)
Context: I started this project in high school and continued working on it through college!
Description: This is a multi-year project that I worked on! It started as an app for my high school (LG CATS) – but over time, it evolved into a platform used to create apps for schools and organizations in general, with the core component being a no-code engine that transformed data from Google Sheets into native iOS apps.
Tech Stack: Swift/Xcode, using Firebase as a backend and Google Sheets as a content manager.

Bend the Curve

Links: Blog Post
Context: I created this over quarantine in May 2020.
Description: This is a simple, UI-focused app focused on tracking COVID cases across the world.
Tech Stack: Swift/Xcode.

AI-Generated Resumes

Links: Blog Post
Context: I created this for Cal Hacks 2019.
Description: This is a simple game! Check out the demo video in the post.
Tech Stack: Swift/Xcode.

Companies

Paz, by Pineal Labs

Links: Blog Post, iOS App Store
Role: I was the first iOS engineer for Pineal Labs, and built this app for the Berkeley-based meditative music startup.
Description: This app is a music-focused meditation app.
Tech Stack: Swift/Xcode, using Firebase as a backend database and Airtable as a content manager.

Equilibrium by Vayu Technology

Links: iOS App Store
Role: I was the first iOS engineer for Vayu Technology, and built this app for the LA-based wearable technology startup.
Description: This app is used to distribute OTA firmware upgrades to Equilibrium devices.
Tech Stack: Swift/Xcode, using iOS’s Core Bluetooth framework to implement communication with the startup’s wearable sensors.

Messenger Terabit Networks

Links: Not Released (Internal App)
Role: I was the first iOS engineer for MTN, and built this app for the Los Gatos-based wearable technology startup.
Description: This app serves as the primary interface to the proprietary MTN electronic logging device for trucks.
Tech Stack: Swift/Xcode, using iOS’s Core Bluetooth framework to communicate with the logging device.

Voiceroom - spatially-aware voice chat

2020-09-01T00:00:00+00:00

This project is in progress, so this post may be updated with more information & updates over the coming months!

Earlier this summer, a friend and I built Voiceroom (https://voiceroom.us/) – a spatially-aware voice chat application, built using WebRTC and React. We launched on Product Hunt - and made it to the front page! We were also featured in the Product Hunt Newsletter, which goes out to thousands of readers daily. Voiceroom was also mentioned in the Wall Street Journal, in an article focusing on the rise in audio-first experiences.

A little more about Voiceroom (quoted from our Product Hunt post) –

Hey Product Hunt!

We’re excited to launch Voiceroom, a service designed to make virtual interactions more realistic. As students, we’ve spent hours on Zoom and Google Hangouts where only one person can speak at a time. We miss the real-life environment of open collaboration – and the ability to launch into a side conversation with the person next to you.

To solve that problem, we built Voiceroom. With Voiceroom, multiple simultaneous conversations can happen in one room, and you’ll be able to hear both the immediate conversation around you as well as other conversations in the background. It’s like a real room. If you’re presenting, you can screen share and broadcast your voice so that the whole room can hear you.

Voiceroom currently supports all major browsers (Chrome, Safari, and Firefox) and rooms up to 15 people. We’re working hard on bringing support to mobile – as well as expanding the number of participants in each room. We’re continuously improving the experience, and would love to hear your feedback!

Thanks!

Anmol & Shomil

Update: try the demo at https://www.voiceroom.us/demo to see this in action without making an actual room!