Your term project should address a research issue in network security, interpreted broadly (it need not be a topic discussed in class). The goal in terms of depth and quality is to develop the effort to a degree that would merit a workshop-caliber publication. Most projects will fall into one of the following general categories:
I encourage you to find a topic of interest to you; feel free to be creative in selecting a project topic! You're welcome to pick a topic that is connected to your current research, and in general I'm happy to discuss possible topics with you in advance. (See the end of this writeup for a list of past projects to get the flavor of what students have done. I can provide more specifics about these if you'd like.)
Often you can pursue the same project jointly for two different classes. If this would be the case, you need to discuss it first both with me and with the other instructor(s).
In general, you should work in a team of two. Individual projects may be doable but require prior discussion with the instructor. If you want to work in a team larger than two, first talk with me about why this is appropriate and how the work will be divided.
With coauthors, I've written some papers providing advice for researchers:
(Note that the following dates are at this point tentative.)
The Initial Thoughts email is due the evening of Friday Jan 31.
The project proposal is due the evening of Friday Feb 14.
Put together a related work writeup. This writeup should reflect a solid grounding in the literature relevant for your project, written in a style similar to the related work sections in the papers we've been reading. For each item of previous related work, briefly discuss the contributions of the paper, its relevance to your undertaking, and (if appropriate) in what ways it differs from your effort.
In general, you can tell if your related work framing is possibly too narrow is by looking at the citations of those papers you currently discuss. If you see that they cite tons more work that at least from their titles sounds like they could be germane, then it's your task as a researcher to then track those down - ideally, all of the ones that sound like they could be relevant - and assess which ones you indeed need to read and absorb. Note, read-and-absorb here can run the range from reading in detail, similar to how you read papers for the class, to just reading sections or such, as you gauge relevance.
You then recurse on the citations in those papers, repeating the process until you converge by not finding any new papers, and/or the ones you find become only lightly related.
At this point, you've then mastered the full literature on the area you're working in (and usually gotten a bunch of new ideas about what to try or, often more importantly, not try).
When gathering these related papers, you may run across some that require payment through portals such as those run by ACM or IEEE. Note that UCB has site licenses for most of these libraries, so you should be able to readily fetch them using a campus machine/address without needing to provide payment.
The related work writeup is due the evening of Friday March 7.
The status report writeup is due the evening of Friday Apr 11.
Prepare a class presentation. These will be held at the end of the semester, likely extending into RRR week due to the size of the class. I may also have students make interim presentations earlier in the semester, but haven't decided about this yet.
24+ hours prior to the class in which you'll be presenting, post a brief (~2-3 paragraphs) description of your project to Piazza.
There's an art to scoping a presentation to effectively make use of the available time. You need to gauge what context your particular audience (here, this means your classmates) already has regarding the problem space your work addresses, and not spend time developing that broader context; at most, just remind them. However, it will (better!) be the case that your particular area has depth beyond what the average audience member knows about. You do need to frame this additional context, both in terms of what makes the problem interesting and significant, and how the problem space has been previously viewed in terms of prior work and the assumptions this work reflects.
Note: it's possible that instead of presentations we will have a poster session. I will determine which of these well in advance of the presentation dates.
Finally, your project report is due on Tuesday May 13, at 1PM. No extensions will be granted.
You are expected to write a technical paper, in the style of a conference submission, on the research you have done. State the problem you're addressing, motivate why it is an important or interesting problem, present your research thoroughly and clearly, compare to any related work that may exist, summarize your research contributions, and draw whatever conclusions may be appropriate. There is no page limit (either minimum or maximum), but reports will be evaluated on technical content and not on length.
If relevant, include a section where you describe how others (beyond your team) contributed both to different parts of the work and to the text in the writeup. My expectations are that the strong majority of both the work you report on and the writeup text will be yours, but it's generally okay if relatively minor subsets are from others, as long as these are flagged as such.
Be sure to pay attention to these pointers regarding writing technical papers.
Submit either PDF or HTML, via email attachment. I generally review papers from hardcopy, so it needs to print clearly and with sufficiently large text and figures. If you use color figures, mention that in your cover note so I can send it to an appropriate printer. In addition, also submit your document source. It doesn't need to build (e.g., okay to leave out LaTeX packages and figures; it can be helpful to include your bib file, though).
To give you a flavor of possible projects, here are examples of what students have done in the past (note that some of these could make sense to redo or work on further):