Security and Vulnerability Disclosure Policy

In short

• Members sign in with a passkey, a one-time code by email or an optional password, and we hold as little about you as we can. Section 3 lists what we do. We do not claim the site cannot be broken into. No honest site can.
• One person runs Tillyard. Nobody watches it around the clock, and no outside specialist has tested it yet. Section 4 says so.
• You protect your account by keeping your passkey device and your college mailbox under your own control, and by never giving anyone a sign-in code. Staff never ask for one.
• If you have found a security problem, write to security@tillyard.org. You do not need an account.
• Test by hand and slowly, with your own account. Stop the moment you can see another person's information. No flooding, no bulk scanning, no tricks played on staff or members, and no testing of the companies that host us.
• If you follow this policy in good faith, we treat your research as authorized and we will not take legal action against you or act against your account because of it. Section 9 has the exact words and their limits.
• There is no reward of any kind. With your written agreement we can thank you by name.
• We aim to acknowledge a report and to tell you what we did about it. We do not state a time.

If this summary and the full text below ever differ, the full text governs.

1 What this document covers

1.1 What this document covers, and who is speaking

Tillyard is an Ohio nonprofit corporation. "We" and "us" mean Tillyard.

This document does three things:

• it describes, as fact, what the site does to protect accounts and information (sections 3 and 4);
• it says what members can do to protect themselves, and what to do if an account may have been taken over (sections 5 and 6);
• it says how anyone can report a security problem, what testing we allow, what we do not allow, and what we commit to in return (sections 7 to 13).

It covers Tillyard only. The president also runs a business of their own under another name. It has its own systems and its own contacts, and nothing in this document permits testing it.

1.2 How this fits with other documents

• The Terms of Use (section 5) set out your responsibility for your own account. The Acceptable Use Policy (section 8) forbids probing and attacking the service, except as this document allows. On what security testing is permitted, this document is the more specific one and governs. Section 37.5 of the Terms of Use sets the order among all our documents, including the sections of those terms that prevail over every other document.
• The Privacy Notice says what information we hold and what we do if there is a security incident (its sections 13 and 14). On incident notice, the Privacy Notice governs.
• The Messaging and Monitoring Notice explains that rooms and messages are screened and logged and are not end-to-end encrypted.
• The Cookie and Storage Statement lists the cookies that sign-in depends on.
• The Data Retention Schedule gives the period for each kind of record, including sessions, codes and the staff action log.
• The Email and Communications Policy says how to tell a genuine message from a forged one.

Some other documents call this one the Security and Vulnerability Disclosure Policy. They mean this document.

1.3 Words used here

Words that have one meaning in every one of our documents, such as member, visitor, staff, the editor, record item, hold, case and tip, are defined in Definitions. The words below are added for this document's own subject, or repeated from Definitions for convenience. If a repeated meaning ever differs, Definitions governs the meaning of the word.

• A passkey is a sign-in credential that lives on your own device or in your password manager. You unlock it with whatever your device uses: a fingerprint, a face, a PIN or a security key. We hold no secret that could be leaked to sign in as you.
• A code is a short number we email to your college address to prove that you control that mailbox.
• A session is the signed-in state of one browser on one device.
• A vulnerability is a weakness in the site that could let someone see, change or remove something they should not, act as someone else, or stop the site working for others.
• Good-faith research means looking for and testing a weakness only in order to find it, confirm it and get it fixed, in a way designed to avoid harm to people, and using what you learn to make the site and its members safer.
• Staff means the owner and any person who works for us under a paid, written contract and holds a staff account. At present the owner is the only member of staff. Members are never staff, and no member is given any power over another member's content or account, whatever title or history that member has.
• The staff action log is the record of everything staff do in the staff console.
• A keyed hash is a scrambled form of a value, made with a secret key, that lets us tell whether two values are the same without storing the value.

2 What we claim

• We describe what we do so that you can judge it. Each line in section 3 is meant as a statement of fact about how the site works on the date at the top of this document.
• We do not say the site is "secure", "unhackable" or "bank-grade". Those words have no testable meaning, and we do not use them anywhere.
• We do not promise that an incident cannot happen. We describe how the site is built to make one less likely and less harmful.
• No outside body has examined the site and declared anything about it. We hold no security attestation and show no badge or seal.

If you find that the site does not do something this document says it does, that is something we want to hear about. Write to security@tillyard.org.

3 What we do to protect accounts and information

This section describes how the site is built on October 21, 2026. We test these things before each release. They describe a design. They do not promise that the design cannot fail or will not change, and section 27 of the Terms of Use applies to them. Where a sentence below says "every", "never" or "cannot", read it as a statement of how the software is written to behave, which our tests check, and not as a warranty that no fault exists.

3.1 Signing in

• Passkeys first, passwords optional. A passkey is the strongest way in. A password is optional and kept only as a salted hash made with a secret held outside the database. Five wrong passwords pause password sign-in for that account, and each pause in a row lasts twice as long. A one-time code by email also works.
• Codes only prove a mailbox. We email a code when you join, when you recover an account, at the yearly check of your college address, and when you change that address. A code is not how you sign in from day to day. Recovery is by a code sent to your college address; you can also make recovery codes, shown to you once, each of which works once.
• How codes are handled. A code is six digits, can be used once, stops working after a few minutes and allows only a few wrong tries. We store codes in scrambled form. Only one code is live for an address at a time. The number of codes that can be sent to one address, or asked for from one network, in an hour is limited.
• The same answer either way. The pages that send a code are built to answer in the same way whether or not an account exists for the address typed, so they cannot be used to find out who is a member.
• A bot check first. Every form that sends an email, or that accepts input from someone who is not signed in, sits behind a bot check and rate limits.
• A session opened by code alone is limited. Until you sign in with a passkey, some sensitive actions wait. A data export, for example, waits 24 hours, and we tell you in the app and by email that it was asked for.
• Sensitive changes need a recent sign-in. Changing your name, changing your college address, starting a data export and closing your account each ask you to confirm it is you if you have not signed in during the last few minutes.
• A change of address is slow on purpose. Moving your account to a new college address needs a passkey, a code sent to the new address, and a waiting period of 72 hours during which we tell the old address and you can cancel.
• You are told. We send a security notice when a new device signs in, when a passkey is added or removed, and when an address change is under way. These notices are sent whatever your email settings are.

3.2 Sessions

• Your session is kept in a cookie that scripts on the page cannot read, that is sent only over an encrypted connection, and that is tied to this one site so that no other address can set or read it.
• The cookie holds a long random value and nothing about you. We store a scrambled copy of that value, not the value itself, so a copy of our database would not let anyone sign in as you.
• The value is replaced when you sign in.
• You can see the devices that are signed in and sign any of them out, under Account, "Sign-in and school email".
• A session ends when you sign out, when it has not been used for a long time, or when it reaches a maximum age, whichever comes first. The Data Retention Schedule gives the current periods.
• When an account is suspended or removed, its sessions are ended and its live connections are closed. When an account is set to close, every other device is signed out.

3.3 Checking every request

• Every page and every action starts by asking what the person making the request is allowed to do. The answer is "no" unless a rule says "yes".
• The check that something belongs to you is made inside the database query itself, not afterwards.
• Addresses contain random identifiers. They never contain an account number or an email address. A request for something that belongs to another member is answered "not found", so identifiers cannot be tested one by one.
• Anything that changes something is sent as a form submission, never by simply opening a link, and a request that arrives from another website is refused.
• Everything typed into the site is checked against a strict description of what that field may contain, with a size limit, before it is used.
• All database queries are written so that what you type is passed as data and can never be read as a command.

3.4 What members write

• Text that members write is shown as text. It cannot carry HTML, scripts or styling.
• Where light formatting is allowed, such as in a paper, it is rebuilt from a short list of permitted elements, and anything else is dropped.
• A link typed by a member is shown as text and is not clickable, unless it goes to one of a short list of sites we allow. There are no link previews, and our servers never fetch an address that a member supplies. The few outside look-ups the site makes go to fixed hosts we chose: a scholarly reference index and, where switched on, public listing services and a check that links in our own guides still open. None carries anything about a member.
• Text that other people will see is screened before it is shown, or in the case of table chat within about a minute of being sent. The Messaging and Monitoring Notice describes this.
• Every page is sent with a policy that tells your browser to run only our own scripts, each marked with a value that changes on every page, and to refuse scripts written into the page itself.
• The pages cannot be placed inside a frame on another site.
• The only thing a page loads from another company is the bot check, and only on the forms that need it. Fonts and scripts are served from our own address. There are no advertising, analytics or tracking scripts.

3.5 Nothing is uploaded

• The only files the site accepts are figures in a paper for Tillyard Research and receipts for a research grant. It accepts no audio or video.
• When you import a résumé in The Workbench, the file is read inside your own browser and never leaves it.
• Members are shown by their initials. There are no profile pictures.

This removes most of that risk: the editor looks at every figure before a paper is published, and only the grantee and the president see a receipt.

3.6 Limits on abuse and on cost

• Every input has a ceiling: the size of a request, the length of a field, the number of items in a list, the number of messages in a minute.
• Every person has a budget: limits are counted by member, by session and by a keyed hash of the network address, and new accounts have lower limits and cannot send links for their first days.
• A live room in The Shop is joined with a signed ticket that lasts a few seconds. Before it issues one, the site checks your session, the posted hours and whether any restriction applies to you.
• The site keeps count of how much of each daily allowance it has used and reduces what it does in a fixed order as the allowances run down. Section 4.3 describes this.
• Staff can switch off sign-ups, chat, publishing or tips, or put the whole site into a read-only or maintenance mode, in seconds.

3.7 Holding less

The most reliable way to protect information is not to have it. We do not store:

• passwords in readable form. A password a member adds is kept only as a salted hash;
• a date of birth. The date typed at sign-up is checked and discarded in the same step, and only the fact and time of the check are kept;
• government identity numbers or documents;
• photographs, voice or video, or any biometric data;
• card or bank details. Tips are paid on pages run by Stripe, and the site receives nothing about them;
• your network address in readable form in our own database. Where we need to count requests from an address, we keep a keyed hash;
• emails, names or member text in the site's technical logs.

The Privacy Notice lists what we do hold.

3.8 The staff console

• The staff console is part of the site, at tillyard.org/staff. It opens only for an account with a console role, after a recent, strong sign-in with a password or a passkey.
• Staff accounts are held only by the owner and by people working for us under a paid contract. The board's trustees, who are unpaid, and sponsors also have console accounts of their own kinds: a trustee's opens the Board office, and a sponsor's opens only its own page. No member has moderation powers over another member.
• What staff do is written to the staff action log. Each entry is chained to the one before it, so that an entry that was changed or removed would show. The table that holds the log refuses any change or deletion, including by the owner, so the log is not pruned: it is kept for as long as Tillyard operates, and it holds identifiers and reason keys, never names, email addresses or member text.
• The owner can view the site as a particular member sees it, read-only, for up to ten minutes at a time. That view cannot open Messages, drafts, résumé copies or data pages, cannot join a room and cannot send or change anything. Each use needs a reason and is written to the log.
• There is no staff screen for browsing or searching private conversations. Staff can read a message, and up to ten messages either side of it, only when someone in the conversation reports it or screening flags or holds it; a table's chat log can be opened only in the six situations listed in section 6.2 of the Messaging and Monitoring Notice, with a reason recorded first. The first time on any day that a member of staff opens a case's evidence, and each time one opens a table log or a member's page, an entry is written to the log.
• The addresses used for testing and previewing software are switched off for the live site, so the console cannot be reached through them.

3.9 Encryption, keys and backups

• All traffic between your browser and the site uses HTTPS, and browsers are told to use nothing else.
• Information is stored on our hosting provider's systems, which encrypt it at rest.
• Notes, threads and table chat are not end-to-end encrypted. They are stored so that they can be screened and so that staff can read a conversation that has been reported.
• The site's secret keys are kept in the hosting provider's secret store, not in the code. Separate keys for separate purposes are derived from one master secret.
• We take a copy of the database about once a week and keep no copy longer than 12 weeks. We do not yet state here how those copies are protected, because the procedure for making and keeping them is still being written; this line will be replaced when it has been adopted and run.

3.10 Email

• Email from the site is sent from tillyard.org, and from nowhere else.
• That domain publishes the standard records (SPF, DKIM and DMARC) that let your mail provider check that a message really came from us and reject one that did not.
• Our email contains no remote images, no tracking and no attachments, and no email of ours signs you in by a link. The Email and Communications Policy says more.

3.11 How the software is built and tested

• The site uses few outside software components, each pinned to an exact version, and scripts that outside components would run during installation are switched off.
• Each part of the site has automated tests that try it as five different people: someone signed out, a member, a different member, a suspended member, and staff. Each part also has tests that try to abuse it: oversized input, too many items, rapid repeats, another member's identifiers, and an exhausted daily allowance.
• A part of the site is not treated as finished while those tests fail.

Automated tests find only what someone thought to test for. They are not a substitute for an outside review, which we have not yet had (section 4.1).

4 Limits

4.1 Nobody outside has tested the site

The site is tested by the people who built it. No outside security specialist has reviewed or attacked it. That is a real limit, and it is one reason this document invites reports.

4.2 One person

One person runs Tillyard and reads the security mailbox. There is no security team and nobody on watch at night. Nothing alerts the president's phone yet, and the president is sometimes unreachable.

4.3 The site can pause

The site runs inside fixed daily allowances from the company that hosts it, and inside ceilings we set ourselves. As an allowance runs down, the site sheds work in a fixed order: drafts save less often, then optional syncing stops, then new sign-ups wait, then chat is switched off, then publishing is paused. It is built to keep sign-in, reporting, the removal forms, moderation and the staff action log running longest. Some pauses last until the allowances reset at 00:00 UTC.

A pause is the design working. It is not a sign that information has been exposed. It does mean that someone could try to pause the site on purpose by flooding it, which is why flooding is forbidden in section 8 and why we ask that testing be done by hand.

4.4 Your college mailbox is part of your security

A code sent to your college address can recover your account. Your college controls that mailbox. Some colleges forward, reassign or close addresses after students leave, and anyone who controls the mailbox can receive a code. The limits in 3.1 are there to reduce the damage: a session opened by code alone cannot do the most sensitive things straight away, and you are told when it happens.

4.5 Things outside our control

We rely on other companies to host the site, deliver email, run the bot check, check text and take tips. We choose them with care and cannot see inside them. We cannot protect your own device, your browser, or a copy of something that you or someone else has saved elsewhere.

4.6 A public page is public

When you share a Record link or publish a paper, anyone who has the address can read it and copy it. Addresses of Record pages are long and random, so they cannot be guessed, but a link you have given out is as private as the people you gave it to. Removing a page later does not reach copies that were already made.

5 What you can do

5.1 Your passkey and your devices

• Create your passkey on a device that is yours, protected by a screen lock.
• Add a second passkey on another device, so that losing one does not lock you out and you never need to fall back on a code.
• Remove a passkey for a device you have sold, lost or given away.
• Keep your browser and operating system up to date.

5.2 Your college mailbox

• Turn on two-step sign-in for your college account if your college offers it.
• Check your college mailbox for forwarding rules you did not set.
• If you are about to lose your college address, for example on graduating, move your account to a new address first, under Account, "Sign-in and school email".

5.3 Codes

• Never give a sign-in code to anyone, by email, by phone, in a note or in table chat. Staff never ask you for a code.
• A code is only ever typed into a page on tillyard.org that you opened yourself.
• If a code arrives that you did not ask for, do nothing with it. Nothing happens without the code. If codes keep arriving, tell us.

5.4 Shared computers

• Sign out when you finish.
• Tell The Workbench that the computer is shared, so that nothing is kept in the browser after the tab closes.
• Do not create a passkey on a computer that other people use.

5.5 Keep an eye on your account

• Look at your device list from time to time and sign out anything you do not recognize.
• Read the security notices we send. If one describes something you did not do, act on it (section 6).
• Account, "History", lists the events on your account and every permission you have given.

5.6 Email that claims to be from us

• We never ask by email for a code, for payment, for bank details or for an identity document, and we never send attachments.
• If a message asks for any of those, or comes from an address that is not at tillyard.org or tillyard.org, it is not from us. Forward it to security@tillyard.org and delete it.

The Email and Communications Policy has the full list of what a genuine message looks like.

5.7 Your own copies

A data export contains your notes and drafts. Keep the file somewhere only you can reach, and do not leave it in the downloads folder of a shared computer.

5.8 People who say they act for us

No member can approve your paper, grant a title, remove a member or act for us in any way. If someone who is not staff says they can, they cannot. Please report it.

6 If you think someone has been in your account

1. Sign in with your passkey and open Account, "Sign-in and school email".
2. Sign out every device you do not recognize, and remove any passkey you did not add.
3. If an address change you did not ask for is waiting, cancel it. A change waits 72 hours before it takes effect, and the page shows when.
4. If the account has been set to close, choose "Keep my account". Nothing is erased during the 14-day closing period.
5. Check your college mailbox for forwarding rules, and change your college password.
6. Write to security@tillyard.org from the address on your account and tell us what you saw. Do not send us a code.

If you cannot sign in at all, write to security@tillyard.org. We confirm it is you by sending a code to the address on the account. If you no longer control that address, we may be unable to confirm that the account is yours, and we do not hand an account to anyone on their word alone.

We may pause an account that we believe has been taken over, end its sessions, or hold a change that is waiting, while we look into it.

7 Reporting a vulnerability

7.1 Where to write

• Email: security@tillyard.org
• The site publishes a security contact file at /.well-known/security.txt. It gives the same address and links to this page.

You do not need an account, and you do not need to give your real name. We welcome a report from someone who stays anonymous.

Please do not report a vulnerability through the report control, the dispute form, table chat or a note. Those go to other queues, and some of them are seen by other people.

7.2 What to include

• What you found, in a sentence or two.
• Where: the address of the page, or the name of the form or action.
• The steps to reproduce it, written so that someone else could follow them.
• What an attacker could do with it, as far as you can tell.
• The date and rough time of your testing, and the public identifier of the account you used if you used one, so that we can find it in our records.
• How you would like to be thanked, if at all (section 11).

One problem per message is easiest for us to follow.

7.3 What not to include

• Other people's information. If you saw someone else's name, note, draft or email address, tell us that you did and where. Do not paste it into your report, and do not keep a copy.
• A code or a session value that belongs to someone else.
• More proof than is needed. The smallest demonstration that shows the problem is enough.

7.4 Encrypted reports

We do not publish an encryption key at present. If your report contains details that should not travel by ordinary email, write to security@tillyard.org first with a one-line summary, and we can agree a way to send the rest.

7.5 Language

Please write in English.

7.6 Things that are not vulnerabilities

• Something a member wrote or did: use the report control on the item, or the Reporting, Enforcement and Appeals Policy.
• A request about your own information: use your account, or write to legal@tillyard.org.
• A problem using the site with assistive technology: write to accessibility@tillyard.org.
• A part of the site that is paused for the day: section 4.3.
• An email that pretends to be from us: this is worth reporting. Forward it to security@tillyard.org.

8 The rules for testing

These rules are what "following this policy" means in section 9. They exist because the site is small, runs on limited daily allowances, and holds real conversations between real students.

8.1 Do

• Use your own account. Test against your own account and your own information. If you are not eligible to join, test only what can be reached without signing in, or write to us first.
• Go by hand, and slowly. Work at the pace of a person using the site. The site runs on small daily allowances, and automated scanning can take it offline for everyone until midnight UTC.
• Stop at the first sight of someone else's information. Once you can see that a problem exposes another person's data, you have confirmed it. Do not look further, do not copy it, and tell us.
• Tell us promptly and privately, at security@tillyard.org.
• Give us time. Please do not tell anyone else about the problem until we have told you it is fixed, or until 90 days after your report, whichever comes first. If we need longer we may ask you, and say why.
• Delete what you collected once we confirm that we have your report.

8.2 Do not

• Flood or overload. No denial-of-service testing, no load testing, and nothing meant to use up the site's daily allowances, its email allowance or its bot-check or text-safety allowances.
• Run bulk tools. No automated scanners, crawlers or fuzzers at volume, and no trying of codes, links, ticket numbers or identifiers in bulk to find ones that work.
• Touch other people's accounts or information. Do not sign in as anyone else, read their notes or drafts, or change or remove anything that is not yours.
• Contact a person whose information you came across. Tell us, and we decide with care whether and how they are told.
• Involve other members. Do not send test messages, nods or invitations to real members, sit at a live table in order to test it on the people there, or submit test papers to Tillyard Research, where a student reader or the editor would have to read them.
• Use the report, removal, dispute or confirmation forms as test targets. Each one opens a real case. Some start a legal clock. If you believe one of these forms has a weakness, describe it to us and we can arrange a safe way to check.
• Make the site send email to an address that is not yours.
• Trick people. No phishing or pretexting of staff, members, outside confirmers or our providers, and no impersonating us.
• Test our providers, or anyone else's systems. Section 10.2 lists what is out of scope.
• Leave anything behind. No backdoors, no stored scripts left in place, no accounts created to keep access.
• Open extra accounts. The Terms of Use allow one account per person. If a test needs a second account, ask us and we may be able to set one up.
• Ask for money. A report that comes with a demand for payment, or with a threat to publish unless something is given in return, is not good-faith research.
• Break the law. Nothing in this document permits anything that is unlawful.

8.3 If something goes wrong

If your testing causes harm you did not intend, for example a room stops working or you find you have changed something, stop and tell us at once at security@tillyard.org. Telling us honestly counts in your favour.

8.4 If you come across something by accident

You do not have to be looking for problems to find one. If you see information or a function that clearly was not meant for you, stop, do not copy or share it, and tell us. Reporting an accident honestly is never held against you.

9 Safe harbour for good-faith research

9.1 What we commit to

If you make a good-faith effort to follow this policy while you look for, test and report a security problem in the things listed in section 10.1:

1. Authorized. We consider what you did to be authorized by us, for the purposes of the federal Computer Fraud and Abuse Act and similar state laws, so far as it is ours to authorize.
2. No legal action by us. We will not bring a legal claim against you because of it, and we will not ask a law enforcement agency to investigate you because of it, unless a law requires us to make a report.
3. Not a breach of our terms. We will not treat it as a breach of the Terms of Use, the Acceptable Use Policy or the Community Guidelines. Where a rule in one of those documents would forbid research that this policy allows, this policy governs for that research and for nothing else.
4. No action against your account. We will not suspend or remove your account, withdraw a title or a record, or change your standing because of it.
5. Technical measures. We will not bring a claim against you under the anti-circumvention part of the Digital Millennium Copyright Act for getting round a technical measure of ours in the course of it.
6. If someone else objects. If another party takes legal action against you over research that followed this policy, we are willing to state in writing, at your request, that you acted under this policy.

9.2 The limits of that commitment

• It is ours alone. We cannot authorize testing of systems that belong to someone else, and we cannot bind the companies that host us, your college, other members, a prosecutor or a court. If your research touches a provider's system, that provider's own policy applies.
• It covers research inside this policy. It does not cover flooding, bulk scanning, social engineering, looking through another person's information after you had confirmed the problem, anything in section 8.2, or anything outside section 10.1.
• It does not cover a demand for payment. Section 8.2 applies.
• It does not stop us protecting members. While a test is under way we may still end a session, pause a feature or hold an item if that is needed to keep other people safe. That is not a penalty, and we aim to tell you why.
• It does not stop us meeting a legal duty. We may fix the problem, tell members who were affected, keep records, and tell an authority where a law requires it.
• Automatic limits do not know about it. The site's rate limits, automatic holds and screening treat a researcher like anyone else, and one of them may stop you in the middle of a test. That is not a decision about you. Tell us, and we can look at it.
• It does not change the law. Some things are unlawful whatever we say. Reading other people's private messages, for example, may break laws that we have no power to waive.

9.3 If you are not sure

If you are unsure whether something you plan to do is inside this policy, ask first at security@tillyard.org. A question is never treated as an admission.

10 What is in scope for testing, and what is not

10.1 In scope

• The website at tillyard.org, signed in and signed out: every page, form and action.
• The addresses on tillyard.org that the site's own scripts call, and the live connections used by The Shop and by notices.
• Public pages: published papers, Record pages and the "check a record" page.
• The forms that need no account, as targets for analysis only: see the warning in 8.2 before sending anything through them.
• The staff console at tillyard.org/staff: whether someone without a console account can get into it, or a sponsor account can see more than its own page. Do not go further if you find that they can.
• Email that the site sends: whether a message of ours can be made to carry someone else's words, to reach an address that did not ask for it, or to sign someone in.
• The security contact file.

10.2 Out of scope: systems that are not ours

• The companies that work for us: the hosting and network provider, including its bot check; the email delivery provider; the text-safety services; the scholarly index; and Stripe, including its payment pages. If you find a problem in one of them, report it to that company.
• Any college's or university's systems, including its mail system and its sign-in.
• Members' devices, browsers and mailboxes.
• Other websites that the site links to.
• Any other business the president runs under another name.
• The president's or any staff member's personal accounts, devices or home network.
• Our postal address and anything physical.

10.3 Out of scope: kinds of finding

These are the kinds of finding we are unlikely to act on. We list them so that you can spend your time better elsewhere:

• anything that depends on flooding the site or exhausting an allowance, since we know that is possible and describe it in section 4.3;
• a missing security header, cookie setting or mail record, reported without a way it could be used against someone;
• output pasted from an automated tool that has not been checked by hand;
• a weakness that needs the victim's device to be already compromised, an outdated browser, or the victim to paste something into their own browser's tools;
• being able to place a page with nothing sensitive on it inside a frame, or to sign someone out;
• the exact numbers of our rate limits;
• the versions of software we use, where no weakness is shown;
• information that is public by design: a Record page that its owner chose to share, a published paper, a member's name and college as shown to other members, the fact that a college is on the list;
• what members write. Use the report control;
• the behaviour of the bot check or a provider's challenge page.

10.4 What we most want to hear about

• Reading another member's private notes, threads, drafts, settings or export.
• Acting as another member, or keeping access after a session has been ended.
• Reaching anything in the staff console without being staff.
• Getting round a block, or writing to a member you are not connected with.
• Learning who reported someone, who read a paper in a blind reading, or who blocked whom.
• Making an item on The Record say that staff approved it, or that someone confirmed it, when they did not, or altering what a public Record page shows.
• Making a tombstone or an erased account give up a name.
• Joining without an allowlisted college address, or getting past the age check in a way that leaves no record.
• Getting a script, a live link or a remote image into something another person sees.
• Making the site send email to an address of your choosing, or put your words in an email.
• Forging or reusing a signed link: an unsubscribe link, a confirmation link, a status link, a room ticket.
• A way to make the site spend its allowances far faster than normal use would. Describe it. Do not run it.
• A copy of members' information, or of the site's own records, found somewhere it should not be.

11 No reward, and how we say thank you

11.1 No bounty

We do not pay for reports. There is no bounty, no prize, no merchandise and no discount, because there is nothing here to discount. Please do not report in the expectation of payment.

We do not work with any bounty platform or go-between. A message offering to tell us about a problem in exchange for a fee is treated as section 8.2 describes.

11.2 Thanks

If your report helped, and you would like to be named, we can add your name to the list in section 15 once the problem is fixed. We list a name only with your written agreement, in the form you ask for, and we remove it whenever you ask. You are equally welcome to stay unnamed.

11.3 What a report does not create

• Reporting a problem does not make you our employee, contractor or agent, and it creates no duty on our part to pay you or to work with you.
• A thanks is not a title, a perk or an item on The Record. Nothing on The Record comes from reporting a security problem.
• You keep whatever rights you have in your own write-up. By sending it you allow us to use what it tells us to fix and describe the problem.

12 What happens after you report

1. A person reads it. Today that is the president.
2. We acknowledge it. We aim to reply in a few days to say that we have your report. One person reads this mailbox, so it can take longer, and we do not state a time.
3. We try to reproduce it. We may come back to you with questions.
4. We decide what it is. We may conclude that it is a vulnerability, that it is something we already knew about, that it belongs to one of our providers, or that we do not agree it is a problem. We aim to tell you which, and why.
5. We fix it, starting with whatever protects members' private information and sign-in. If a fix needs a part of the site to be switched off meanwhile, we may switch it off.
6. We tell you when it is fixed, so that you can check if you wish.
7. We tell anyone who was affected, where the law requires it or where we believe there is a real risk to them. The Privacy Notice, section 14, governs.

Once a problem is fixed we may describe it publicly, in general terms, so that members know what happened. We do not name the person who reported it unless they agreed (section 11.2).

If two people report the same problem, we aim to tell the second that it was already known. If we disagree with you about whether something is a problem, you remain free to say so publicly after the period in 8.1, and the safe harbour in section 9 still applies to research that followed this policy.

13 If there is a security incident

If we learn that information has been reached or taken by someone who should not have it, the steps are, in outline:

1. Contain. Switch off the affected part, or the whole site, using the switches described in 3.6. End sessions if sign-in may be affected.
2. Replace keys. Change any secret that may have been exposed.
3. Keep the evidence. Preserve the relevant records before they reach their normal deletion date.
4. Work out what happened and who is affected.
5. Tell people. Where a law requires us to notify you or an authority, we do so in the way and in the time that law sets. Where no law applies and we believe there is a real risk to you or your account, we aim to tell you anyway, by email and by a notice in the app, and to say what happened, what was involved and what we suggest you do.
6. Fix the cause, and write down what we learned.

The Privacy Notice, section 14, is the governing statement on notice, and this section is a summary of it. Because we hold no readable passwords, identity numbers or payment details, an incident here may fall outside the laws written around those things. That is one reason for the second sentence of step 5.

A message about an incident comes by email from tillyard.org and as a notice in your account. It never asks you for a code, for payment or to install anything.

14 How we handle your report

• We use what you send us to understand and fix the problem.
• We do not publish your name or pass it to anyone else without your agreement, unless a law requires it.
• We may share the technical details, without your name, with a provider whose system is involved or with someone helping us fix the problem.
• Email sent to security@tillyard.org is kept for the period the Data Retention Schedule gives for correspondence, and longer if it becomes part of a legal matter.
• Reporting a problem never affects your standing here.

15 Thanks

People who reported a security problem that we fixed, and who asked to be named, are listed here.

Nobody is listed yet.

16 Changes to this document

The version number and effective date are at the top, and earlier versions stay available. A change to sections 3 and 4 is a correction of fact and applies when posted. If we narrow the commitments in section 9, the earlier wording continues to apply to research carried out before the change was posted.

17 Contact

• A security problem, or a message that pretends to be from us: security@tillyard.org
• Help with your own account: support@tillyard.org
• A request about your information, or a legal notice: legal@tillyard.org
• Post: Tillyard, Security, 10602 York Rd SW, Etna, Ohio 43062

Please do not send details of a vulnerability by post. Write to security@tillyard.org first.

Questions about this document

support@tillyard.org

Legal notices

legal@tillyard.org

By post

10602 York Rd SW, Etna, Ohio 43062

For anything else, see where to send what.

Fingerprint of this text (SHA-256): c86b261bc91ad9a5b9cc818fa10ed96821ca318d6936d66ecb0295bca9015981