What Makes a Good ACSAC Paper

We are frequently asked what makes a good paper for ACSAC. One of the best ways to get ideas is to look at previous years' proceedings to see what has been accepted in the past. Most papers since 1998 can be read at our web site, and we encourage authors to take advantage of this resource. The program chair also welcomes questions as to whether a topic is appropriate for the conference. We will be happy to help direct you in a way that improves the opportunity for accepting your paper.

Some guidelines for good papers are:

  • Describes an application of security concepts or technologies used in a new way.
  • Describes a security architecture
  • Displays a clear understanding of the relevance of this paper to related efforts and products, including references as appropriate.
  • Is readable without accompanying explanation (i.e., is written in prose, not as bullet items as might be on briefing charts).

Papers must be blinded, and should be the equivalent of no more than 10 pages, when set as two column, 10 point font (about 7500 words). Successful papers are rarely less than five pages. You are not required to format your paper this way; this is just a guideline to help you know if your paper is too long.

Some things to avoid are:

  • Papers that could be used essentially unchanged as a sales or marketing document.
  • Papers that have been published essentially unchanged before in a public forum, as a conference paper, magazine article, journal article, or book chapter. Papers previously published in internal company, university, or other journals (e.g., as technical reports) may be submitted. If you think there may be questions as to the similarity to a previously published version, please be sure to clearly distinguish the submitted version from earlier versions (e.g., by including a paragraph for the reviewers at the beginning of the paper).
  • Papers that are under consideration for publication elsewhere must not be submitted.
  • Papers that are overly long (the limitation on published versions is 10 pages, so if a submitted paper is 20 pages the reviewers will be unable to determine what will actually remain in the published version).
  • Papers that are slide presentations (e.g., bulleted lists of points without any prose).
  • Papers that include the biography (or other identifying information) about the author.
  • Papers that could be published essentially unchanged in a trade magazine.
  • Inquiries about submitting papers significantly after the deadline.

Papers that are sometimes good, but carry a potential for falling over the line:

  • Descriptions of how to use a product. Can be useful if the product (or class of products) are not well known, or if there's something new in how it is used. If it's a summary of a manual, please don't submit it.
  • Updates to earlier papers, unless there's substantial new information.
  • Surveys of related technologies, if they add something new to surveys that have been previously published (e.g., an objective measure of performance, or a detailed look at security capabilities).

We reserve the right to reject papers without review, if we believe they fall outside the guidelines for the conference.