Contact Adam Shostack

cute graphic

You know those fancy contact us pages that web designers build? The ones that take your request and leave you wondering if it was even sent, never mind read? We don't like 'em either. So instead, email Adam at
(What's up with that strange address? See the threat model below!)

Some links for reasons you might want to email us:

Wiley will also provide copies for educators considering using the book as a textbook. Please use Wiley's textbook request form.

You can also see my personal homepage: Adam Shostack.

Subscribe to "Adam Shostack's New Thing" mailing list

Adam's setting up a mailing list for those who'd like to be notified when he creates something new. It's cleverly named "Adam Shostack's New Thing." It'll be the first place to hear about the new things he's creating — books, games or anything else.

He promises to send fewer than 13 messages a year to this list, each about something he's created, or something awesome that a friend has created. He'll aim for one message a month (or even less frequent!)

This list is intended for be his least-frequent, most important content. Sign up so that you don't miss what he's been building!

Why would you sign up for this versus following him on Twitter, Emergent Chaos or the New School blog? This list is designed to be his least-frequent, most important content. Sign up so that you don't miss what he's been building.

* required information
Email Format


A brief threat model for this page

Since this is a site for a book on threat modeling, it makes sense to explain the threat model which led to this contact page. That is, what concerns should we have, how do those interact with requirements, and what can be done to address the threats? Since Adam knows a thing or three about threat modeling, the first approach was to brainstorm and come up with a list of expected threats.

Expected Threats

Based on experience, you might be worried about:

A more structured approach

But perhaps you can do better than that? Let's see what happens when you apply the lessons of the book. That is, let's sketch a model of the system, use a more structured approach to walk through it, and then mitigate the threats you find. (Foreshadowing: you get different results!)

Build a model

So here's a model:
Email threats graphic

As you'll learn in chapter 1, the rounded rectangles are code Adam controls, while the sharp-cornered ones are entities outside his control. The dashed box is a "trust boundary," where everything interacts at the same privilege level.

Walk through the model

The model abstracts spam away from email addresses, and focuses on messages coming in (over some unnamed channel). So you think about that, moving from email to a web front end doesn't remove the spam, it just changes the form. Since we see "contact us" forms all over the web, you might jump to the idea that it's a superior pattern. But every blogger has good evidence that web forms get spam.

The next set of threats is that spam filters eat your email, and not the spammer's email. There's a related threat that your spam filter will eat Adam's response, but you're outside of his trust domain control, so he can't address that threat.


There should be a want a way for you to contact Adam where it's easy to have a smart spam filter, that doesn't add risk of vulnerabilities, and is easy to maintain.


There are many ways to mitigate spam threats. Some of the most common are attempts to make mailto links that only work if the spammer is processing the page in some "right" way. You shouldn't trust those, there's too much evidence that spammers are smart about harvesting email addresses.

So what we've decided to do is to use an arbitrary email address and rotate in a new arbitrary email when Adam starts getting spam. (Of course, we'll need to be slightly clever to handle lag.)


This page gives you an example of a quick and dirty threat model. The model was built in under an hour as we were implementing the contact us page, and asking how to ensure that we don't have exploitable web vulnerabilities in the page. As we thought it through, we realized that the planned design exposed extra attack surface (in the web technologies), required a special anti-spam layer, and didn't provide a great user experience.

A threat model like this shows how you can go from worrying about expected threats to a more refined set of threats and mitigations. It doesn't need to be complex to add business value.