sec-deadlines: a countdown page for security and privacy conference deadlines

What the page is and what it is based on

sec-deadlines is a page of deadline countdowns for academic conferences in security and privacy. The README credits its basis: it is based on ai-deadlines by @abshkdz, the well-known countdown site for machine learning conferences, with the entries narrowed to the security field.

The site itself is a static Jekyll site. The repository layout shows the standard Jekyll skeleton: a _config.yml at the root, the _data/ directory holding the dataset, _includes/ and _layouts/ for the templates, static/ for assets, an index.html as the page itself, and an ical/ directory for the calendar feed.

The scope is stated clearly. The page is meant to host academic conference or workshop deadlines, and the inclusion test is a five-question checklist that a reviewer applies to decide whether an entry belongs.

The first question is whether there is a Call For Papers, a link for submissions and formatting guidelines such as page limits and a style guide. The second is whether security, privacy or cryptography is mentioned in the list of topics. The third is whether there is a review process, and the site checks for a named general chair, program chair or program committee on the website. The fourth is whether an accepted paper will be published in proceedings. If the answer to all of them is yes, the conference or workshop is likely a good fit.

That last question is the one that does the real work, and the examples show why. PrivacyCon, the FTC's event, was not a good fit, and neither was Real World Crypto, because at the time neither published proceedings. The README notes that once PrivacyCon or RWC begin publishing proceedings they would become fit for inclusion. So the criterion is about whether the deadline leads to published research, not about whether the topic sounds adjacent.

The YAML record format

Every conference is one entry in _data/conferences.yml, and the README gives an example record:

- name: Euro S&P
  description: IEEE European Symposium on Security and Privacy
  year: 2018
  link: http://www.ieee-security.org/TC/EuroSP2018/
  dblp: https://dblp.org/db/conf/eurosp/index.html
  deadline: ["2017-08-15 23:59"] # must be a list
  date: April 24-26
  place: London, UK
  tags: [SEC, PRIV, CONF, CORE-A]

The field list is documented as a table, and the required ones are marked with an asterisk.

The name is the short conference name without the year, and the year is a separate field. The description carries either a one-line description or the long name of the conference. A comment field holds extra notes such as a co-located conference or a rolling deadline. The link points at the conference home page, and the dblp field points at the DBLP page, which is optional but useful because DBLP is where the published proceedings live.

The deadline field is required and is always a list, even when there is a single deadline. The timezone field is optional and defaults to UTC-12, the Anywhere on Earth convention used by these sites to mean the deadline is the same moment everywhere.

The tags are the taxonomy, and they have three dimensions. Topic is SEC, PRIV or CRYPTO. Venue is CONF, SHOP or JRN, distinguishing a conference, a workshop and a journal. Rank is TOP4, ASTAR, CORE-A, CORE-B, CORE-C or OTHERS, and the link in the README points to _data/types.yml, which is where the taxonomy itself is defined.

That three-dimensional scheme is what lets the page answer questions like which deadlines are for privacy venues specifically, or which are the top-ranked computer security conferences. A single flat list of names would not.

Rolling deadlines and the timezone sign inversion

Two details in the format are the sort that make or break a contribution, and the README flags both.

The first is rolling deadlines. A conference that accepts papers every month does not have a fixed date, so the deadline field supports templates. You substitute the year with %y for the year of the conference and the year before with %Y. So %y-01-15 23:59 means a deadline on 15 January in the same year as the conference, and a list can mix both forms, for example two rolling deadlines with one at the end of October in the year prior and one at the end of February in the conference year:

- "%Y-10-31 23:59"
- "%y-02-28 23:59"

The second is the timezone format, and the README is unusually candid about it. The timezone format sign is inverted, so UTC+7 is written as Etc/GMT-7, and the README says in as many words that it is not a bug and that the author hates the format too. The reason is given: the author would be happy to move to a different timezone JavaScript library that uses a friendlier format, but does not have the time for it. The format is the IANA time zone database convention, and it is documented with a table of common zones and the warning that the sign is inverted for some weird reason.

The default timezone is UTC-12, described as the AoE convention, so a deadline without an explicit timezone is the same instant for everyone.

There is one more piece of presentation logic worth knowing. If the deadline hour is exactly h:00, it is automatically translated into h-1:59:59, to avoid pain and confusion when it happens to be midnight in the reader's local time. So a deadline written as 23:59 means the end of that day in the given zone, and a deadline written as 00:00 is shifted back to the previous minute, which prevents it appearing as a day later in some timezones.

Display in the reader's local time, and the calendar feed

Two features are worth calling out because they are what turn a table of dates into something usable.

The first is that all deadlines are displayed in the viewer's local time, and the README is explicit that this is a feature rather than a side effect. A researcher in Singapore and a collaborator in Lisbon looking at the same page see the same instant expressed in their own clocks, and neither has to do the arithmetic. The countdown itself is therefore also local, which means the page tells you how long you personally have left rather than how long the world has left.

The second is the ical/ directory, which holds the calendar feed. That matters more than it sounds for this particular kind of site. A conference deadline is a thing you want in your calendar with a reminder, not a thing you re-read on a web page. The README's field list does not describe the feed's contents in detail, so the exact behaviour is not documented here, but the presence of the directory in a Jekyll site with a YAML dataset is the standard way of generating an iCalendar file from the same records that drive the page.

Together those two features define what the page is for. It is not a reference list you consult once a year; it is a live countdown that is always correct in your own timezone and that can hand you a calendar entry.

How to add or update a conference

The contribution workflow is four steps, and one of them is a rule that catches people out.

First, read the data format description, and note the inverted timezone sign. Then update _data/conferences.yml, either on GitHub or locally after forking the repository. Then send a pull request. And the rule that catches people out comes first in the list: check if an entry for a prior year's offering exists, and if so update the prior entry rather than adding a new one.

That last instruction is the one that keeps the page usable. Without it, a conference that runs annually would accumulate an entry per year with the same short name, and the list would fill with duplicates of the same venue with different years. Updating in place means one row per conference, whose year and deadlines move forward.

The README's own directory listing notes that the data lives in _data/, and the taxonomy link points at _data/types.yml, so the tags a contributor can use are defined in the repository rather than in the README. That is the arrangement that lets the tag list grow without the README needing to change.

For a project of this kind, the interesting part is that the whole page is regenerated from that one file. There is no database and no server-side code, which is what makes it possible to run on GitHub Pages with no operational cost.

Limits: a narrow scope, a shared dataset and no stated policy

The limits are visible in the README's own framing.

The first is the scope. The inclusion test requires a call for papers, a security or privacy topic, a review process with named chairs, and published proceedings. Any deadline that fails one of those is excluded, including workshops and conferences that are adjacent to security without being part of it, and any industry event. The README gives two worked examples of exclusion, PrivacyCon and Real World Crypto, both of which would qualify once they publish proceedings. That is a defensible line, but it means the page will always be missing deadlines that other countdown lists include.

The second is the shared dataset. Every entry lives in one YAML file in one repository, and every change is a pull request reviewed by the maintainer. There is no per-user curation, no submission from a conference organiser, and no automated feed from the conferences themselves. The accuracy of the page depends entirely on somebody noticing a deadline and submitting it. The record for a prior year is updated rather than duplicated, which keeps the list clean but also means one stale entry stays stale until someone fixes it.

The third is that the README does not describe the build or deployment. The tree shows a Jekyll layout with a _config.yml and standard directories, and the homepage is the GitHub Pages URL, so the hosting is the obvious one. But there is no build script in the repository listing, no Gemfile and no theme configuration to point at, which means a contributor who wants to run the site locally has to work that out from the Jekyll conventions rather than from documentation.

The fourth is the absence of a licence. The repository has no LICENSE file in its top level listing and the licence field is recorded as unknown. For a site of public information that is unlikely to matter, but for anyone who wants to reuse the dataset or the layout in their own project, the terms are not stated.

The fifth is the last push. The repository was updated on 2026-10-20, the same day as the present date, and it has no GitHub releases, so there is no version to pin and the site changes as the data changes.

sec-deadlines against the general conference countdown sites

Two comparisons make the choice clearer.

The first is against the general countdown sites, of which ai-deadlines is the archetype and the direct ancestor of this one. Those cover machine learning conferences comprehensively, with hundreds of venues and a filtering interface by topic, rank and date. The difference in approach is editorial: this page applies a five-question test that a general list does not, so the entries are fewer and more consistently peer-reviewed venues. If you are a security researcher, that narrower list is more useful than a larger one that includes workshops and industry events you were never going to submit to.

The second comparison is against a personal calendar or a spreadsheet. A calendar entry for each deadline you care about gives you reminders, which is the thing the ical feed provides. A spreadsheet gives you a view across many conferences at once, which is the thing the page gives you. Neither replaces the other, and the practical answer for most people is that the page is where you find out what to put in your calendar, and the calendar is where you actually get reminded.

There is a third possibility worth naming, which is doing it yourself. The dataset is a YAML file in a public repository under an open format, and the page is a static site, so you could fork the repository, keep only the conferences in your field, and generate your own view with your own reminders. That is possible precisely because the project is simple enough to understand in an afternoon, which is also the strongest argument that the data, rather than the code, is the valuable part.

Editorial conclusion

Adopt sec-deadlines if you work in security or privacy research and want one page that shows where the next deadlines fall in your own timezone, with a calendar feed on top. Do not expect it to cover every venue, since the inclusion criteria are deliberately narrow and exclude anything without a review process or published proceedings. Verify first that a conference you care about has an entry and that its deadline year and rolling template are right, since a deadline recorded for a prior year is left in place rather than duplicated when a new year is announced.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sec-deadlines/sec-deadlines.github.io on GitHub