The Sanction of Brian De Moray

I first became aware of this case when it was mentioned in the context of the Wistric Saga, being discussed by Aeron Harper in the second part of his “Tale of Six Sanctions” essay. Aeron’s article was focused on the procedures and policies of the sanctions process, and understandably glossed over some of the technical details, but as a software developer, my curiosity was piqued.

At the time, I was disappointed to learn that Brian was reluctant to discuss the details for fear of additional sanction, but ten days later he published additional information, including technical details of his work, after the Chairman of the Board of Directors assured him that he would not be sanctioned a second time for the same offense.

Having now read all of the above, and having discussed the case with Brian, I am dismayed by the Society’s sanction, which is completely unjustified by the facts available to me. I’ve decided to write out my thoughts on the situation in hopes of calling attention to this injustice, and perhaps, if possible, contributing to correcting it.

Stand Back, I’m a Professional

I’m not a fan of credentialism, but for the benefit of folks who might read this without knowing me personally, I should make it clear that I have some relevant experience.

I’ve been a professional software developer specializing in internet applications for thirty years. I’ve been responsible for creating business-critical web systems as an independent developer, as a staff team leader, as a consultant, as a small business owner, and as a startup co-founder. I’ve worked on systems that handled personal information, pediatric psychiatric and adult medical records, millions of dollars of credit card payments, and Federal congressional and presidential campaign data. And I’ve worked on numerous integrations of web applications written by separate development teams like the one discussed below, including single-sign-on (SSO), headless-browser scripting, and RPC and REST web APIs.

In the context of the SCA, I’ve served at the local and kingdom level, holding the offices of marshal, herald, webminister, and seneschal, among others. I have coded features and bugfixes for the Society’s O&A heraldic database, and am the designated emergency deputy and likely successor for its maintainer. I’ve worked with the East Kingdom webministry in multiple roles over the last five years, I was part of the team that contributed to the rewrite of the Society Webminister’s Handbook released earlier this year, and I was the lead author for the new Society Release Forms Handbook.

All of which is to say that you’re free to disagree with my interpretation and conclusions, but I’m not just some internet rando talking out of their hat.

Atlantia’s Warrant-Tracking System

Brian is a technology professional in the modern world, and he is very active in Atlantia’s fencing community, so it is unsurprising that he volunteered to use his modern skills to address a data-management challenge his kingdom (like every other kingdom) has had to handle: tracking warrants and reports for officers and marshals.

In coordination with relevant officers in his kingdom, he built a database-backed web application which Atlantia uses to record and track warrants and reports for martial activities, as well as the ministries of the Lists and Web. (Similar efforts have been undertaken in multiple kingdoms across the Known World, replacing the pen-and-paper record keeping of the prior century with an electronically-updated roster of current warrants and ensuring that reports efficiently reach their recipients.)

This application Brian built (both its custom Python code and the underlying database) runs on a webserver provided by and controlled by Atlantia’s webministry, and uses role-based access control to ensure people who interact with it are only able to view or modify the information they’re allowed to — eg, that the kingdom rapier marshal has access to rapier warrants, but can’t unilaterally authorize rattan fighters, and so on. (Ahem.)

The Membership Data Files

In order to validate membership information — to confirm that a particular person has actually paid to keep their Society membership current, and that this membership hasn’t been suspended or revoked — the warrant-tracking application relies on being provided with membership data files.

These membership files are generated at the Society level every month and sent out to each kingdom, providing them with a list of current members in their area, including each person’s Society name, modern name, member number, membership status and expiration date. Each kingdom then distributes those data files as needed, including to local branch seneschals and to kingdom-level officers, who are responsible for taking necessary actions such as revoking warrants for officers whose memberships were suspended.

In some cases this might be done by having kingdom officers scroll through the data file each month looking for new members and those who were recently suspended, but it’s increasingly common that folks instead import the data file into another application that allows them to automate those tasks. (For example, in my home kingdom of the East, the Webministry imports this data file every month into a custom application which allows Easterners with current membership to create a member-number@members.eastkingdom.org account which can be used for email and Google Docs.)

However, these integrations are subject to a significant limitation: when a new person signs up for a Society membership (or renews their lapsed membership, etc), that data isn’t available to the Kingdom’s applications until the next cycle of monthly membership-file updates, and thus unless special steps were taken they might have to wait a few weeks before they could be given a warrant in Atlantia (or a member email address in the East, etc).

Additional delays could be introduced if the various people responsible for forwarding the data file by email and importing it into the application each month didn’t complete those steps in a timely fashion, or if the format of the file changed, which happens every couple of years when Society decided to add new columns or change the formatting of one of the values.

This would be even more true for an application that served multiple kingdoms, a possibility that was under discussion as other regions expressed an interest in using the warrant-tracking system that Brian had built for Atlantia. Because the membership data files are sent out independently to each kingdom, each of the kingdoms that wanted to use such as system would have to upload their own file every month, creating lots of potential for confusion and tech-support difficulties if the data was up-to-date for one kingdom but still a month out of synch for another.

Society Integration

These data synchronization challenges were among the many issues Brian had to consider as he began exploring the possibility of building a new version of his application that could be shared Society-wide by any kingdoms that were interested in participating.

He talked with the Society Marshal, Alan Gravesend, about such a possibility, as well as the Society VP of Information Technology, Aaron Palomides (“Rusty”), before agreeing to move forward. The plan called for Brian to develop a new generation of his warrant-tracking system, which would run on a server provided by the Society, and which multiple kingdoms could use, working together to support and enhance it over time. In late 2019, the Society VP of IT provided a development workspace on one of the SCA’s servers, and Brian started setting up some test code to work out the details of the new system.

While brainstorming the right approach to use for the Society-wide system, Brian wondered if there was a way to obtain updated information from the Society’s membership system in real time, rather than waiting for the next month’s data file.

At this time, the SCA stored its membership information in a third-party database and associated web application provided by a small company named MembersOnly, which was not very technologically sophisticated, and lacked the kind of real-time API that could be used to integrate the two systems in the ways that have become common with modern web applications.

A Possible Approach

During the second weekend of January 2020, Brian wrote a little bit of code (less than 3KB of Python, most of which is comments and whitespace — only 24 lines of actual code) as a proof-of-concept test for a kludgy workaround: If an SCA member visited the warrant-tracking system, and gave it the login name and password they used for MembersOnly website, the warrant-tracking system could use those credentials to login on their behalf, and verify that their membership was up to date.

If this worked, it would allow newly-registered members to verify their active status without waiting for the next month’s update. And if worked well, it might allow the warrant-tracking system to dispense with keeping track of its own distinct set of passwords — instead, people would have a single login name and password which could be used both to manage their membership in MembersOnly and also to manage warrants in Brian’s new system.

The code he wrote did work — when he put in his own login name and password, the system could access the MembersOnly site and confirm that he was an active member — but the implementation was very awkward and inefficient. Because MembersOnly’s website used the JavaScript-based GWT-RPC system to manage its authentication, Brian’s Python code couldn’t just send a simple HTTPS API request and wait for a response.

Instead, his code ran a full-blown web browser, to take advantage of its JavaScript support, and interactively controlled that browser to load the MembersOnly website, and acted as a person would, “typing in” the name and password, “clicking” the submit button, and then “reading” the next page the browser rendered. (Brian’s proof-of-concept Python code used the open-source Selenium package and the “headless Chromium” version of the Chrome web browser to do this.)

That browser-based approach struck Brian as too resource-intensive to use in a production system, and too fragile — if the MembersOnly team made any changes to their website, like rearranging the fields and buttons on the login form, or changing the text that appeared on the subsequent webpage, his code would need to be changed as well.

He also investigated emulating the web requests that the GWT-RPC code would make without firing up a full-blown browser, but that approach seemed even more fragile; because he would be making calls to an undocumented API, the MembersOnly team might break its functionality at any time, and they wouldn’t be under any obligation to fix it or help him figure out a workaround, which wasn’t a sound basis for a core piece of the new system’s functionality.

The Innocuous Post

So, Brian shelved that code and went back to the drawing board, posting a quick comment to his friends on Facebook explaining how he’d spent his weekend working on an unpaid project for the SCA.

(For those unfamiliar with developer jargon, anyone with a serious interest in the technology field would understand that Brian was obviously using “hack” here in the sense of “an expedient, temporary solution… meant to be replaced with a more elegant solution at a later date” rather than “an illegal attempt to gain access to a computer network.”)

A few of Brian’s acquaintances in the tech field commented on the post, but there was no substantive discussion, and he turned his attention to other subjects — so this should be where the story ends.

Enter the BoD

But six days later, Brian’s brief post was the subject of discussion at the quarterly meeting of the Society’s Board of Directors.

While recent Board meetings have been held via video conference, and were recorded for posterity, the January 18, 2020 meeting was held in person, in Milpitas, CA, and so we have little information about what was said beyond what appears in the minutes.

…. (Brian de Moray)

Motion by Dan Watson to direct the Society Seneschal to issue an administrative sanction against …. (Brian de Moray) prohibiting him from holding any offices in the SCA for a period of twelve (12) months, effective immediately and concluding on January 18, 2021. Second by: Natalie Degerstrom. Opposed: None. Motion carried.

Minutes of SCA Board of Directors Quarterly Meeting, January 18, 2020

(In keeping with my usual practice, I have redacted Brian’s modern name.)

Putting aside all of the procedural issues outlined by Aeron in his analysis of how this sanction was implemented, what was the substantive reason for it?

The letter sent to Brian lays out the case for the sanction:

On January 17th [sic], 2020, the Board of Directors reviewed the details of a recent matter in which you publicly detailed an exploit in which you could record the membership information of a SCA member without their or the SCA’s consent.

Due to the pubic [sic] manner in which you published the exploit and vulnerability without regard for the established procedures for identifying and reporting such issues, the Board reviewed the matter and determined that an Administrative Sanction should be imposed.

Sanction Notice sent to Brian de Moray, January 2020

The Sanction Was Profoundly Mistaken

If you’ve been reading closely, and were able to follow the technical details of the previous section, at this point your head should be ready to explode, because basically every statement in there is wrong.

1. As far as I can tell, Brian’s 113-word Facebook post is the only thing he “published” about this — hardly a “detailed” “exploit.” Brian wrote that “I figured out how to” do something — but his post doesn’t describe the technique or provide any sample code. (The proof-of-concept code linked to above was only posted in the last day, more than three years after this incident.)

2. This technique absolutely can not work without the “consent” of the SCA member — it can only access information if the member chooses to provide their login name and password to the membership site, which they are under no obligation to do, and there’s no indication of coercion or deceit.

3. No security expert would consider this a “vulnerability” — if you provide system A with your username and password for system B, it can use those values to sign in on your behalf, but nobody would describe that as a security flaw in system B; it’s just a fundamental reality of how password-based credentials work. (For example, the exact same technique could be used with the SCA’s new membership system adopted in 2023, which uses a completely different technical underpinning.)

4. To the best of my knowledge, the SCA has never had any “established procedures for identifying and reporting” technical security issues, either when this incident occurred or at any other point in time.

Impact of the Sanction

As a result of this sanction barring him from holding any office, Brian was forced to step down as Atlantia’s Kingdom Rapier Marshal, even though his kingdom martial service was completely independent of the software development work he was doing for the Society.

The sanction also breached Brian’s trust in the Society’s leadership, and as a result he halted his efforts to develop a new version of the warrant-tracking system which could be used by other kingdoms.

(To be clear, the development effort wasn’t halted by the Society; in fact, the Society Marshal and Society VP IT were both content to have Brian continue working on that system — a few days after the sanction was issued, the Society Marshal wrote that the VP IT “let me know when I spoke to him last that he felt that Brian could continue to help with the marshallate database,” which would be surprising if Brian’s actions were truly egregious — but Brian has stated that he is unwilling to undertake any IT work at the Society level unless Society leadership acknowledge that this sanction was in error.)

Appeal

Brian promptly filed an appeal of the sanction, explaining what he had done, laying out the purpose of the code he had written, and pointing out that his development work had been authorized by the Society Marshal and Society VP IT.

(The Society’s leadership failed to act on the appeal for more than a month, then directed Brian to re-submit his appeal — the details of this procedural hiccup do not seem to put the Society’s leadership in a good light, but I am attempting to gloss over the procedural issues in order to focus on the technical questions, and so I will not dwell on this.)

When the Board finally considered Brian’s appeal, two months after he had filed it, it appeared to be the subject of some debate during the closed-to-the-public Executive Session. Two Board members moved to uphold Brian’s appeal, both of which efforts failed, and in the end they compromised by reducing the term of the sanction from one year to six months.

… (Brian de Moray)

Motion by Dan Watson to uphold the appeal of [Brian de Moray]. As there was not a second the Motion failed.

Motion by Gigi Coulson to uphold the appeal of [Brian de Moray]. As there was not a second the Motion failed.

Motion by Gigi Coulson to amend the end date of the sanction of … (Brian de Moray) to July 18, 2020, effective immediately. Second by: Natalie Degerstrom. Opposed: John St. Dennis, Vandy Pacetti-Donelson. Motion carried.

Minutes of SCA Board of Directors Quarterly Meeting, April 4, 2020

As a result of this compromise, the sanction preventing Brian from holding office expired in mid-July, and Atlantia soon restored him to the position of Kingdom Rapier Marshal.

Conclusion

So, what should we make of this incident?

Let’s set aside the procedural issues discussed by Aeron Harper regarding how the Society handles sanctions and appeals, both in general and in this case.

Perhaps there are additional facts that have been kept hidden, and which if known would put this entire incident in a different light — perhaps Brian used a secret space laser to hack into the Milpitas mainframe, or had for years made a hobby of kicking the Society President’s dog, or some other transgression that would help to justify this sanction — but it seems unreasonable to assume facts which are not in evidence.

Based on the public record and the information available to me, as laid out above, and informed by my thirty years of professional experience in the field of internet software development, my take is as follows:

1. Brian did not “hack” or “exploit” any of the SCA’s IT systems. He wrote a few lines of totally boilerplate code that caused a web browser to visit the members.sca.org website and fill in his own login name and password. No personal information was displayed to anyone or revealed in any way.

2. Brian did not “publish a vulnerability” in any IT systems. The message he posted would not allow anyone to obtain another member’s personal information without their consent and participation.

3. Based on the information available to me, Brian did not say or do anything wrong during this episode, and he should not have been sanctioned for it.

4. The sanction had a lasting impact on Brian’s willingness to volunteer his considerable IT skills at the Society level, and thus was to the detriment of the SCA.

5. Now that the details of this case have come to light, the sanction is having an impact on the willingness of other technologists to volunteer their IT skills at the Society level, and is therefore causing ongoing damage to the SCA.

6. Unless there are some shocking additional details which have been kept a secret until now, the Society’s leadership appears to have made a serious error in this case.

7. If the sanction was imposed in error, the Society’s leadership should take steps to rectify that mistake by publicly apologizing to Brian and expunging the sanction from his record.

8. If the sanction was imposed in error, the Society’s leadership should examine the decision-making process that allowed that to happen. How did this case go from a Facebook post on January 12 to a sanction on January 18 without, as far as I can tell, any investigation or discussion with senior technologists whom would have been able to provide the context needed to understand the situation?

Of course, if it turns out that there really is more to Brian’s case — space lasers or whatever it might be — I’m absolutely willing to accept that evidence, and to condemn him to whatever extent the facts require.

But in the absence of that evidence, and given a public record that strongly suggests that the Board misinterpreted and overreacted to something they didn’t fully understand, I’m left in dismay by yet another star-chamber episode that shows the Society’s leadership in an incredibly unflattering light.