Security review deadlines:
Project deadlines:
Program Committee deadlines (for the regular papers, not project reports written by other students in the class):
Program Committee deadlines (for projects reports written by other students in the class):
Welcome to the CSE 564 Program Committee! We will read, evaluate, and discuss a number of papers in this course. Since one of our key goals is to help prepare you for a research career (whether in security or some other area), we will model the class after a conference program committee. This means that we will assign some (though not all!) of you to review each paper that we plan to discuss in class. After all the assigned reviews are in, the assigned reviewers should skim all the other reviews for the paper. During class we will call on one or more of the reviewers to "present" the paper. We will then have a general discussion about the paper.
The following describes the "program committee" requirements in more detail:
The goal of this course is to help you prepare for research in computer security, as well as for research in other domains for which there will be a security component. We will therefore read a number of important, representative, and/or new papers in the field. Reading the papers will help you prepare for the classroom discussions, which in turn will help you contribute to everyone's overall learning experience, including your own.
To complement the academic papers, when appropriate, we may also read relevant background material.
As a program committee member, if you are assigned a paper to review then you must read it and upload a high-quality review in advance of the relevant deadline. Note that not everyone will be assigned to review every paper!
If you were assigned a paper, then you must enter a review for that paper by the relevant deadline. You should post your review to the CSE 564 conference review system, http://cse564.cs.washington.edu/. You must include an answer for every question on the review form, except the question marked "Comments for PC".
The reviews must be submitted by 8pm on the day before class.
If you were assigned to review a paper, then you should also skim the other reviews for that paper (after all the reviews have been submitted at 8pm). You also have the opportunity to update your review if you wish. And you can also write comments to other reviewers on the HotCRP web site. (Note that the program chairs -- i.e., the course staff -- will get an email copy of every review, review revision, or comment that you post.)
As a PC member, you also have the opportunity to review and comment on any paper, even if you are not an assigned reviewer.
One of the best ways to deeply understand a topic is to discuss the topic with others. Therefore, everyone is expected to actively participate in the classroom discussions -- whether you were an assigned reviewer or not.
We will begin each paper discussion by asking one or more assigned reviewers to "present" the paper. Just like a real PC meeting, you may not know whether you will present the paper in advance or not. So you should always be prepared to present the paper. Your presentation of the paper should begin with a brief summary of the paper (what are the goals, what is the approach, what are the results, etc). Then briefly summarize the strengths and weaknesses of the paper from your perspective, and then say whether you'd like to accept or reject the paper.
We will then enter a general discussion about the paper. Here we expect non-assigned PC members to join in the conversation. The non-assigned PC members will ask questions about the paper, and the assigned reviewers must be able to answer those questions.
Just as with real conference submissions (at least in security), reviewers will not be required to read and comment on appendices.
Although all or almost all of the papers we'll read are already published, it's important to realize that publication does not mean that they received only positive review scores. So we do expect to see an array of both positive and negative reviews for each paper. However, we hope that all of the reviewers will be looking for reasons to accept papers, not reject papers.
Additionally, when reviewing a paper, try to place yourself in the past -- when the paper was written. For example, if we're reading a paper from the mid-1990s, then try to imagine the state of the art at that time.
Finally, while program chairs do try to assign papers to people that are experts in the relevant areas, PC members are inevitably assigned papers outside of their areas of expertise. If you're assigned a paper that's a bit outside of your comfort zone, then do the best you can with your review.
Unlike a normal conference PC meeting, we would like to focus part of the class discussion on new, follow-on research directions and ideas.
If you expect to be absent from a class, please let the course staff know well in advance. And please remind the course staff again before the papers are assigned for class that you will miss. In some cases we may ask you to answer a few additional questions about the papers over email.
You may choose a research project related to any area of computer security, including areas not directly covered in this course. A conference-style report for your project is due at the end of the final exam period. You will also give a short presentation during the final week of classes. We will have several milestones along the way, just to make sure everything is going smoothly. Our hope is that the course research project can complement your existing research interests and directions, or start you on a new long-term research direction.
You may work in groups of 2--3 people. You may choose your own groups, or we can form groups for you if you haven't already done so by the deadline below. In rare cases it maybe possible to work in a group of size 1; please contact us if you wish to explore this option (this option is primarily intended for people who are actively exploring a research project with others outside this course, in which case you won't actually be working by yourself -- it just happens to be that you're the only person on the project enrolled in the course).
We strongly encourage you to be ambitious and have fun with your projects. While certainly not required, we suspect that some of the projects will evolve into conference or workshop publications. If you have a project that might require special resources, please contact us as soon as possible.
The following is a more detailed description of the project timeline and requirements:
In your progress reports, you should reflect on what you have accomplished and draw preliminary conclusions from your results. If appropriate, you should also explicitly state any additional experiments or evaluations you may need to perform in order to strengthen your preliminary conclusions or answer open questions left by your preliminary conclusions.
You must submit a PDF of your presentation materials to the Catalyst drop box. You must also bring two printed copies of your presentation materials to class (for the course staff).
Your draft should be as complete as possible, with a few placeholders for new results that you hope to obtain between this deadline and the deadline for the final report.
You will be expected to read the draft reports that we assign you and write detailed reviews of those papers. You are to upload those reviews to the HotCRP conference review system by the above-specified deadline. We will send these reviews back to the authors of the papers.
Your report should be structured like a conference paper, meaning that your report should contain an abstract, a well-motivated introduction, a discussion of related work (with citations), a description of your methodology, a discussion of your results, and so on.
Everyone should also submit a short summary of their contributions to the project (not required for groups of size 1). This should be at most a page long and can reference the final report. These should be submitted individually, e.g., if Alice and Bob both worked on the project together, then Alice would upload one summary to the Catalyst dropbox and Bob would upload another.
There are numerous resources on the Internet about how to write a good research paper. If you haven't already read them, you might find the following resources helpful:
The slide deck, the draft reports, the peer reviews, and the final report must be submitted on time in order to be graded; i.e., late slide decks, draft reports, peer reviews, and final reports will receive a zero grade. If you submit other project materials late (proposal, checkpoint), you will be marked down 25% for each day that the material is late. When computing the number of days late, we will round up; so material turned in 1.25 days late will be downgraded 50%.
Another key goal of this course is to get you to start thinking about the world in a different way -- to develop what we call the "security mindset." Toward this goal, we will have several small assignments (called "security reviews") targeted at getting you to think about security on a regular basis, and in contexts where you might not normally think about security. For more background, we've written a little about the security mindset here: http://cubist.cs.washington.edu/Security/2007/11/22/why-a-computer-security-course-blog/.
Your goal with the security reviews is to evaluate the potential security and privacy issues with new technologies, evaluate the severity of those issues, and discuss how those technologies could potentially address those security and privacy issues.
You are required to submit two security reviews over the course of the quarter. The deadlines appear near the top of this page. The ideal mode of operation is as follows: You might be reading Slashdot or some other news source and see the announcement for a new product or service. You immediately start thinking about the security implications and issues associated with the new technology. You then formalize your thoughts (in the framework described below) and submit your writeup to the Catalyst forum and the Catalyst dropbox.
Each security review should contain:
These security reviews should be short (around 1000 words). The security reviews should be posted to the course's Catalyst forum and a PDF of the review should be uploaded to the Catalyst dropbox.
You work individually or in a group of two people. If you work in a group, then the PDF that you upload to the Catalyst dropbox must include the names and UWNetIDs of both authors on the first page.
Each security review should evaluate a different technology -- your security review should not analyze a technology that was previously analyzed by another security review in this course.
As with parts of your course project, you may submit your security reviews late. However, you will be marked down 25% for each day that the material is late. When computing the number of days late, we will round up; so material turned in 1.25 days late will be downgraded 50%.