Printer-friendly version

1. A "preproposal" listing your group members and a tentative topic.
2. Two "progress reports" that focus a discussion of your progress with the instructor.
   
3. An oral presentation on your project by one group member, to share what you have learned with the class.
4. Two drafts of a paper reporting the results of your project. 
   

• Preproposal: Sep. 18
  
• Progress Reports:  Oct. 16,  Nov. 13
  
• First Draft: Nov. 25
  
• Final report: Dec. 9 (NO EXTENSION!!).

• Pre-proposal. (0% but required - failure to submit implies an F for the project)
  By 11:59 pm on September 18, one member of each group should use the ITLabs submit tool to hand in a one-page preproposal (named "preproposal.pdf", and in PDF format) with the following information:
• Who: All members of the proposed group, and a group or project name.
  
• What: A clear description of the problem you want to solve.  There is no requirement that this is the final problem, and it can be a somewhat general area, for the preproposal.
• Why: Why should we be interested in the result of your project?  What will it tell us that we didn't know before, or enable us to do that we can't do now?  Why would it be useful to know or be able to do this?
• How: You should be thinking about how you will approach the problem you want to work on.  For your preproposal, a good start will be to list a few (2-5) relevant papers from high-quality conferences or journals.
  
• Over the next week each group will schedule a 30-minute meeting with me to discuss your proposal, including suggested references, topics, milestones, etc.
  
• Progress reports. (0% but required - failure to submit implies an F for the project)
  By 11:59 pm on Oct. 16 and Nov. 13, exactly one member of each group should submit a two-page status report ("report.pdf") that discusses the group's progress since our last meeting, and the current status of the project.  Additionally, each group should submit a tar-gzipped directory including any deliverables  (e.g. implementation source code, experimental results, annotated bibliographies)  agreed upon in previous meetings.
  
  • If you are way ahead, what extra work will you do? 
  • If you are behind, what difficulties did you encounter? 
  • Do you have a plan for what work to drop, if necessary? 
  • The report should give a brief summary of what work was completed by each member and how many hours each member spent.
    
    
• First Draft. (15%) By 11:59 PM on Nov. 25, one member of each group should submit a first draft of the final report on the project.  Like the final report, it should be in the style of a scientific paper (e.g. a conference or journal paper) and should present the project's motivation, approach, results, contribution, related work, and conclusions.  It's not necessary to have all the results in this draft and some sections might outline planned work, but submitting at this stage will give me an opportunity to suggest improvements before your final report.
  
  
• Presentation(15%). Each group will give an in-class presentation of their work during the last three lectures.  This could be a demo, or a formal presentation.  The time available will depend on the number of groups - likely 15 minutes. The entire group has responsibility to ensure the best possible presentation.  The group member who presents will receive some "bonus points" (2% of the total project grade is available). 
  

• Final Report (70%).  By 11:59 PM on Dec. 9, one member of each group should submit a tar gzipped directory which includes any "deliverables" and a (maximum 12 page + appendices) report ("report.pdf") on the project.  This report should be in the style of a scientific paper (e.g. a conference paper) and should present the project's motivation, approach, results, contribution, related work, and conclusions.  A separate file ("contrib.pdf") should summarize the hours spent, and contributions of each group member.

• Originality (15%) To get full credit, your project should contain new ideas (new design, new analysis, new implementation, new evaluation), which could be publishable in academic conferences (not necessarily top notch).  A project which is well done and the result of lots of hard work but has no original ideas is worth a maximum of 85%.  For example,
  
• A simple implementation (e.g. re-implementing a previously implemented system without new analysis, or no comparison) will be worth at most 85%.
• A survey paper is worth at most 92%, but a survey that simply summarizes existing papers will not get full credit. A survey paper should be written so that it conveys information to the reader. When grading the paper we will ask ourselves whether other students in the class might learn about the topic you choose by reading your paper. The paper should contain original analysis of the the papers you choose to cover, and ideally suggest directions for future research on the topic.
  
  
• Project scope: Clarity, Focus, Relevance, Ambition (15%).  To what extent does the paper explore an interesting and relevant system or problem?  Do the authors adequately argue for the importance of their problem?  Is there a clear and precise definition of what the paper will address? For example:
• A paper that attacks an obscure system published at a minor conference that is not used anywhere is less interesting or relevant than a paper that extends or investigates results from a major conference.
• A survey paper that reports on 30 random papers in "wireless security" will be worth less than a paper that surveys 15 major conference papers on "ad hoc routing security protocols."
  
  
• Scholarship (20%).  A good scholar knows the state of the art in their project area.   Does the paper include the important related work?  How is the paper contrasted with other work?  How well do the authors distinguish between what has been written by others and their own work?   A good sign of poor scholarship is a lack of well-explained comparisons to previous papers from top-notch venues; in particular, any good project should be able to cite at least 10 such papers.
  
  What are top-notch venues? In security, the "highest-quality" conferences are (in no particular order) Oakland, CCS, USENIX Security, and NDSS.  Other good conferences with slightly lower quality or a more narrow scope include RAID, ACSAC, ESORICS, CSFW,  PET, WEIS and SOUPS.   The top cryptography conferences are CRYPTO, Eurocrypt, Asiacrypt and TCC.  Good conferences in some other fields related to security include STOC, FOCS, SODA and PODC for theory; SIGCOMM, INFOCOM and NSDI for networks; OSDI and SOSP for operating systems; CHI for usability; and so on.   This is not an exhaustive list, and of course other venues can publish important and interesting papers, but if you have no papers from venues on this list you may be missing some of the definitive work related to your topic.
  

• Evaluation (25%). To what extent do the authors evaluate their approach and establish or support their claims? For example:
• If you propose a new intrusion detection system, what are some potential ways to avoid detection?  How feasible are they?  How did your system perform on standard benchmarks?
• If you propose a new attack, how realistic is it?  Can you carry it out empiricially?  Are there simple countermeasures that can reduce the effectiveness of your attack?
• If you report on experiments, do you analyze their statistical significance?  Do you give enough information that another group could replicate your results?  If your claims are analytical, do you give enough details of the proofs?
  
  
• Miscellaneous (25%).  Is the paper well-written?  Did you accomplish what you set out to do?  Did each group member contribute a minimum of 50 hours on the project?  How much did you learn?  Did you work effectively?  Did you incorporate the feedback received at various points? etc...