This is a presentation about risk, preparedness, and how to do make your best attempt to build defenses against some of the worst threats and potential problems that might ever arise in your life. Keeping your loved ones as well as your community safe is something to always keep in mind and this presentation walks through some of the most critical steps that it is possible to take... before your world explodes in a disaster.

Between July and October of this year, I did a lot of reading and writing about the role of Meta and Facebook—and the internet more broadly—in the genocide of the Rohingya people in Myanmar. The posts below are what emerged from that work.

The format is a bit idiosyncratic, but what I’ve tried to produce here is ultimately a longform cultural-technical incident report. It’s written for people working on and thinking about (and using and wrestling with) new social networks and systems. I’m a big believer in each person contributing in ways that accord with their own skills. I’m a writer and researcher and community nerd, rather than a developer, so this is my contribution.

More than anything, I hope it helps.

A common question: “Is Python interpreted or compiled?” Usually, the asker has a simple model of the world in mind, and as is typical, the world is more complicated.

Today at 1651 UTC, we opened an internal incident entitled "Facebook DNS lookup returning SERVFAIL" because we were worried that something was wrong with our DNS resolver 1.1.1.1. But as we were about to post on our public status page we realized something else more serious was going on.

The title of this post is pretty specific. It relates to the meme on Twitter where users identify a trait or preference that they see as problematic, and identify it as a red flag. The emoji represents the red flag. For example: A stylized red flag Blaming Screen Readers 🚩🚩🚩🚩🚩…

And here we see the usual pattern repeat itself. An inaccessible meme goes viral. After it is so tired that brands use it, someone relying on assistive technology points out how annoying this can be. Authors and developers jump up to blame assistive technology for being terrible at internetting.

Many companies have been trying to disrupt email by making it proprietary. So far, they have failed. Email keeps being an open protocol. Hurray?
No hurray. Email is not distributed anymore. You just cannot create another first-class node of this network.
Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality.

The gender-neutral singular they is a safe, better-than-guessing pronoun to use in situations where you can't ask.

When Grace started her job in security and open-source, she didn’t get the joke about honking geese folks in security would throw around and there was never a good time to ask. The same thing is happening for supply chain security. The landscape is evolving rapidly with high adoption but comprehensive documentations and talks, especially for beginners, are still lagging behind. Starting with why we care about supply chain security, the talk will provide an overview of the landscape and how tools like Fulcio, Rekor and cosign come together. Unlike geese, we won’t hiss at you!

In this Discourse, Tom Scott talks about science communication in the age of social media, how to be popular on the internet, and dealing with a world where view counts are often more important than truth.

Okay, we get it, anyone can edit Wikipedia so it's unreliable — have you tried reading the citations though?

We're not quite sure exactly when email was invented. Sometime around 1971. We do know exactly when spam was invented: May 3rd, 1978, when Gary Thuerk emailed 400 people an advertisement for DEC computers. It made a lot of people very angry... but it also sold a few computers, and so junk email was born.

Fast forward half a century, and the relationship between email and commerce has never been more complicated. In one sense, the utopian ideal of free, decentralised, electronic communication has come true. Email is the ultimate cross-network, cross-platform communication protocol. In another sense, it's an arms race: mail providers and ISPs implement ever more stringent checks and policies to prevent junk mail, and if that means the occasional important message gets sent to junk by mistake, then hey, no big deal - until you're sending out event tickets and discover that every company who uses Mimecast has decided your mail relay is sending junk. Marketing teams want beautiful, colourful, responsive emails, but their customers' mail clients are still using a subset of HTML 3.2 that doesn't even support CSS rules. And let's not even get started on how you design an email when half your readers will be using "dark mode" so everything ends up on a black background.

Email is too big to change, too broken to fix... and too important to ignore. So let's look at what we need to know to get it right. We'll learn about DNS, about MX and DKIM and SPF records. We'll learn about how MIME actually works (and what happens when it doesn't). We'll learn about tools like Papercut, Mailtrap, Mailjet, Foundation, and how to incorporate them into your development process. If you're lucky, you'll even learn about UTF-7, the most cursed encoding in the history of information systems. Modern email is hacks top of hacks on top of hacks... but, hey, it's also how you got your ticket to be here today, so why not come along and find out how it actually works?

When we build a website these days, there’s a 110% chance that it’s got some form of JavaScript on it. Whether it’s a full framework, for animations, to trigger a popup or as a tracking script, JavaScript is all around us.

But what if I told you that you didn’t have to use JavaScript at all? Not even as a build process? Thanks to updates in browser technologies, there’s now a plethora of native browser features that allow building modern, functional websites, sans JavaScript.

So together, we’ll build out a completely static website, a collection of HTML and CSS files, no tracking, no scripting, no servers, no third-party resources. Let’s build a website the way we used to (but no marquees).

This presentation will highlight some of the most exciting and shocking methods by which my team and I routinely let ourselves in on physical jobs.

Many organizations are accustomed to being scared at the results of their network scans and digital penetration tests, but seldom do these tests yield outright "surprise" across an entire enterprise. Some servers are unpatched, some software is vulnerable, and networks are often not properly segmented. No huge shocks there. As head of a Physical Penetration team, however, my deliverable day tends to be quite different. With faces agog, executives routinely watch me describe (or show video) of their doors and cabinets popping open in seconds.