The course projects are one of the key learning components of this class. They are worth a significant portion of your grade, and the course is structured so that you can devote a significant amount of time to the project. This document provides some information about the structure of the projects, and some points to remember along the way.

You should be spending about 5-7 hours a week on your project for most weeks of the course. That amount might vary if, e.g., you have a paper reading to do in a given week). The amount of time you spend each week on the project should increase as the semester goes on, and you stop spending time on homeworks. So you should have the scope to accomplish quite a bit in your research project.

Projects will be evaluated on the quality of your research process. It's fine to try out a creative idea and find it doesn't pan out, so long as you can explain why. It is also fine if the project turns out to not be highly novel (i.e., you discover later there exists similar work); indeed replicating a result may be a completely suitable project.

Course staff will have a collection of suggested research directions; you can consider other research directions but they must be approved by course staff. You will work in teams of 1-3. Here are some key project milestones for the semester.

From Tue Feb 3: start finding project topic and project group
Tue Feb 17: project groups formed
Thu Feb 26: Checkpoint 1: A brief description of your intended project direction and preliminary literature search. You will give a short in-class presentation.
Tue Mar 31: Checkpoint 2: A brief update that includes a formal problem specification and preliminary results. You will give a short in-class presentation.
Tue Apr 14: Checkpoint 3: You will submit an update that refines the problem specification and includes additional results. This update should be well on the way to the final report.
Tue Apr 28: Final presentations
Wed May 6: Final reports due

You will be given feedback from the course staff at each stage.

Finding a Project and Project Group

Lecture 3 is an overview of the topics that will be covered in the course. It is intended to give you a preview so that you can choose a topic to focus on, even though it may not be covered later in the course. After Lecture 3, you should be thinking about possible project topics, and looking for classmates also interested in that topic to form a project group.

Your project topic must include elements of formal methods and must be relevant to security.

The deadline for letting Prof Chong know your project group and tentative topic is Tue Feb 17. Please reach out to course staff if you are having trouble finding a topic and/or a group.

Research Mentoring

Each group will be assigned a project mentor from one of the course staff. At a minimum, you should meet with your mentor at least every 2 weeks, for about 15-30 minutes. Please work with them to schedule your meetings. At each meeting, at least 2 (but ideally all) of your group members should be present. The role of the mentor is to help make sure that you are making suitable progress, or to help you get unstuck if you are not making progress.

To help track research meetings, someone from your group should fill in this google form [link coming] every time you meet with your mentor.

You should always feel free to reach out to any of the course staff at any time, regardless of when you are next scheduled to meet, particularly if you have a research challenge that you're not sure how to overcome.

Checkpoint 1

Checkpoint 1 is to help you figure out what your project is actually about! It is due on Thursday Feb 26. For this checkpoint, you will submit a brief written summary of your project, and present briefly in class. Successful completion of this checkpoint is worth about 5% of your final grade. It has both a written component and an in-class presentation.

Written Component

Submit a document that contains:

a brief description of your intended project direction; and
a preliminary literature review; and
what you plan to achieve by Checkpoint 2.

You should submit this before class on Thursday Feb 26. You can not use late minutes for this submission, it must be on time.

There is no particular page limit, but this will likely be 2-4 pages.

In your checkpoint, be clear about: (a) the question you are asking; (b) how do you think you will address it; and (c) how you plan to measure success. At this stage, it is absolutely okay if your proposed approach has flaws. However, you must make a clear attempt at addressing (a)-(c) above. It is not sufficient to simply provide a literature review.

Note that you must provide a preliminary literature review. You should search for work that addresses the same or similar problem to yours, and you should describe that work in your document. If you are planning on replicating or extending existing work, you should describe that work and what you intend to do in relation to it. Your literature review is more than just a list of papers: it should be a structured, meaningful presentation and discussion. While you do not need to have performed an exhaustive literature search at this stage, nor to discuss the related work in significant detail, your preliminary literature review should identify

Your literature review should use appropriate citation styles. You must write your document in LaTeX, using either BibTeX, BibLaTeX, or similar to track the related work.

See below for some pointers/information about good technical writing.

In-Class Presentation

You will give a brief presentation in class (exact amount of time to be determined) on Thu Feb 26.

You are welcome, but not required to use slides. If you do want to use slides, you must email them to Prof Chong by 10am that day, as a single PDF that has the name of your group.

We'll announce the order of presentations at the beginning of the class. It will be random.

Ideally, all members of your group should participate in the presentation.

You will receive feedback from your classmates and course staff. Please read the feedback carefully and consider it thoughtfully. For example, a question that misses the point of your project is feedback that you did not clearly communicate the point of your project.

See below for some pointers to resources for giving good presentations.

Checkpoint 2

Checkpoint 2 is due on Tuesday March 31. This includes another in-class presentation, and another written component.

Written component: Please submit an update which includes a formal problem specification and preliminary results. It is okay if your problem specification has changed from Checkpoint 1. You will be penalized for not having any initial results (which can be a preliminary exploration; it is also okay to have a set of results that convinced you to reformulate your problem specification).

Note that as with Checkpoint 1, your writeup should address the following:

(a) the question you are asking;
(b) how do you think you will address it; and
(c) how you plan to measure success.

Your writeup should include a more thorough related work section. That is, you should have done a literature search to find relevant and related work. You might need to search forward and backwards on the citation chains (i.e., if you find a relevant piece of work, check what works it cites, and what work cites it). You should briefly describe the related work and the relevance to your project. Make sure to present your references appropriately (i.e., have a properly formatted references section; just having hyperlinks is insufficient.)

Again, there is no particular page limit, but this should likely be 2-6 pages. Do not make this writeup too long: you should still strive to be succinct.

See below for some pointers/information about good technical writing.

Presentation: Similar to your Checkpoint 1 in-class presentation, you will give a brief presentation to the class. You should aim to quickly recap the question/problem (don't expect the class to remember it in detail) and present the progress you are making, including your preliminary results.

See below for some pointers to resources for giving good presentations.

Checkpoint 3

Checkpoint 3 is due on Tue Apr 14. It has a written component only, no in-class presentation.

Think of your written component for Checkpoint 3 as a draft for your final report. See the Final Report section below for additional tips on your final report. Your Checkpoint 3 document should have the same structure as you intend for your final report, but some sections of it may be incomplete.

Final Presentation

Each group will have some amount of time to present (TBD). You can use your own laptop to present, or you can send Prof Chong a PDF, KeyNote, Powerpoint, or Google Slides by 10am the day of your presentation. If you use your own laptop, sometime before class make sure that your laptop can project in our classroom, so that we don't spend a lot of time on switching laptops.

In your presentation, you should be trying to tell the n-minute version of your research story. That is:

Make sure you motivate the problem/question. Why is it important?
Explain your approach, give enough details so that the audience can understand what you are doing, why it is difficult/interesting/novel/…
Give your results so far.

See below for some pointers to resources for giving good presentations.

Final Report

Your report should tell the story of the research, i.e., the problem/motivation, the approach you are taking, etc. In general it should not describe the process by which you did the research. That is, you don't need to describe how you started trying to solve one problem, but then pivoted to a different problem, you don't need to discuss the failed directions (unless that is relevant to the story you are telling, e.g., describing why one design choice turns out to be a bad idea).

In terms of structure, your final report should include an introduction (that motivates and explains the problem/question, explains why it is challenging, and describes the contribution of your group's work) and then sections that go into more detail. The exact structure will depend on your project. It should contain a related work section, which meaningfully compares what you have done with other work. Here are the criteria that we will be evaluating your final report.

Problem Formulation: Clearly states and motivates the research question or problem.
Methodology / Approach: Describes the approach in detail, justifies choices, and explains how it connects to the problem.
Use of Formal Methods and Security Insight: The project meaningfully applies concepts from formal methods for security—e.g., modeling, reasoning, verification, specification, or analysis.
Implementation & Execution: Demonstrates substantial implementation work (e.g., experiments, systems, proofs-of-concept) or proof. Shows care in execution.
Results & Evaluation/Validation: Presents results clearly, with appropriate use of figures/tables. Includes quantitative or qualitative evaluation, as appropriate. Discusses limitations and what the results do or do not show.
Related Work & Context: Situates the work within the broader field. Describes and cites related work accurately and clearly. Uses appropriate citation style. Highlights what distinguishes this project from prior work.
Writing & Clarity: Well-organized, clearly written and formatted. Defines terms, avoids jargon, and communicates appropriate to a CS grad student audience.
Insight & Creativity: Shows original thinking or thoughtful synthesis of ideas.

How long should your final report be? Long enough to tell the story, and no longer. That is, make sure that everything in your report is contributing to the story you are telling about your research, and try to make that concise. That said, if you are using a two-column research-paper format, likely 6-10 pages (not including bibliography or appendices) should be sufficient for your final report.

What's appropriate for related work? First, you need to figure what exactly is related to your project. You can make that narrower or broader, as appropriate. I'd say that having about 25-40 citations in your final report would be reasonable, meaning you can draw the boundary of "related" so that it is a manageable number of papers for you to be reading. Second, you should make substantive comparisons between your work and the related work. Don't cherry pick positive things about yours and negative things about theirs; describe and discuss the similarities and differences and the implications of that.

Additional Notes

Use of AI: It is likely that some (many?) of the student projects will be using AI as part of the design or implementation of a system. As with any component of a system, you should be considering whether the component is trustworthy, whether it is trusted, how it relates to the threat model, the security and functional goals of your system, etc. In particular, you should be able to recognize when it is appropriate and inappropriate to use AI in your system. (In general, LLMs should be untrusted and possibly malicious.)

Formal Methods for Security: In general, you should be clear and explicit (in presentations, checkpoints, and definitely the final report) about your security goal, threat model, and trust assumptions.

Giving Good Technical Presentations: There are a lot of resources online about giving a good computer science research presentation, including the following. I strongly recommend reading/watching at least one or two before you start presenting in class.

How to Give a Technical Presentation by Michael Ernst https://homes.cs.washington.edu/~mernst/advice/giving-talk.html
Giving an Academic Talk Jonathan Shewchuk https://people.eecs.berkeley.edu/~jrs/speaking.html
How to Give a Great Research Talk by Simon Peyton Jones https://www.youtube.com/watch?v=sT_-owjKIbA
How to give talks that people can follow by Derek Dreyer https://www.youtube.com/watch?v=TCytsY8pdsc

Good Technical Writing: we could teach an entire class on good technical writing! For an excellent book that contains more information that you need, see Writing for Computer Science, by Justin Lobel. Here are some high-level things to note:

Avoid forward dependencies. That is, introduce appropriate definitions and ideas before you use them.

Think carefully about the story you are telling. You are not presenting a chronological history of your research; you are telling a story. There are many different stories you can tell that motivate your problem and let you describe what you have done, why you have done it, and why it was (or wasn't) challenging; some of these stories will be better than others. Consider different ways of telling the story. Practice telling the story (by relating to your friends, classmates, project group), and understand that questions are a form of feedback on how well the story works.