How do Amber Alerts work?

So I went down a rathole after writing that screed against AMBER alerts because I wanted to find out who was responsible for the format of these alerts.

The Amber Alerts no longer come from the Wireless AMBER alerts program as they once did. The Wireless AMBER Alert Program has been rolled into the Wireless Emergency Alert system (also called “Commercial Mobile Alert System“, or CMAS), which doesn’t use text messages. That explains the crazy “Cell Broadcasting” app, rather than a conventional text message. WEA-capable devices get these messages based on their location, not their phone number or whatever subscriber information the carrier might have. There are only three kinds of messages that can be sent: “Presidential”, emergency, and AMBER alerts. You can opt of out the last two, but “Presidential” alerts are mandatory per the WARN act of 1996, which is wild.

So here’s how it works. The messages are drafted by the local jurisdictions, who forward messages to FEMA, who sends them to the wireless carriers. You can send the messages to FEMA with a system called IPAWS-OPEN¹ (paws! adorable!) after a simple four-step process. The wireless carriers will then dispatch the messages from IPAWS to their subscribers.

Fun fact: broadcasters monitor IPAWS with RSS and ATOM, the same stuff that powers Google Reader. Here’s ten minutes on CAP.

The standard at the heart of it all, and the standard that produced that atrocious message I received, is the Common Alerting Protocol, or CAP. CAP wasn’t started by some obscure standards committee, but by a bunch of volunteers who saw a need for a common language for national alerts. You thought I was going this far without mentioning open source? You were wrong:

I hope that the CAP can serve as an example of an alternative way of doing things from the
grass-roots. Open-source computing is a vital partner for developing solutions.

That’s Art Botterell, who we could call the father of CAP. So what do we find in the CAP standard?

Here’s a sample AMBER alert:

<alert xmlns = "urn:oasis:names:tc:emergency:cap:1.2">
   <identifier>KAR0-0306112239-SW</identifier> 
   <sender>KARO@CLETS.DOJ.CA.GOV</sender>
   <sent>2003-06-11T22:39:00-07:00</sent>
   <status>Actual</status> 
   <msgType>Alert</msgType>
   <source>SW</source>
   <scope>Public</scope>
   <info>
     <language>en-US</language>
     <category>Rescue</category>   
     <event>Child Abduction</event>   
     <urgency>Immediate</urgency>   
     <severity>Severe</severity>   
     <certainty>Likely</certainty>
     <eventCode>
        <valueName>SAME</valueName>
        <value>CAE</value>
     </eventCode>
     <senderName>Los Angeles Police Dept - LAPD</senderName>
     <headline>Amber Alert in Los Angeles County</headline>
     <description>DATE/TIME: 06/11/03, 1915 HRS.  VICTIM(S): KHAYRI DOE JR. M/B BLK/BRO 3'0", 40 LBS. LIGHT COMPLEXION.  DOB 06/24/01. WEARING RED SHORTS, WHITE T-SHIRT, W/BLUE COLLAR.  LOCATION: 5721 DOE ST., LOS ANGELES, CA.  SUSPECT(S): KHAYRI DOE SR. DOB 04/18/71 M/B, BLK HAIR, BRO EYE. VEHICLE: 81' BUICK 2-DR, BLUE (4XXX000).</description>
     <contact>DET. SMITH, 77TH DIV, LOS ANGELES POLICE DEPT-LAPD AT 213 485-2389</contact>
     <area>
        <areaDesc>Los Angeles County</areaDesc>
        <geocode>
           <valueName>SAME</valueName>
           <value>006037</value>
        </geocode>
     </area>
   </info>
</alert>

Looking at the standard, Section 3.2.2 is where we find all those ridiculous fields (“Category”, “Urgency”, “Severity”) that have absolutely no meaning for the average citizen without an IPAWS training certification. I also see a potentially super-handy “web” field, which is explicitly designed to provide recipients a URL for more information. Alas, the guy in the video tells us that “web” field is verboten.

A little further down in section 3.2.3 of the standard, we have ways of providing photos, maps, audio files, or anything else that you could attach to an email. Great!

So that’s what the jurisdictions are sending up to the FEMA’s IPAWS system. Already, we can see where part of the responsibility lies: the local authority² gave us a deeply bad “description” field, which told us to go watch TV. Garbage in, garbage out.

All that crappy, distracting metadata is part of the CAP message sent from the local authorities. Ideally, it would get filtered out by the broadcasters who are grabbing the CAP messages from IPAWS. In my case, it was Verizon who couldn’t help but send me a bunch of CAP metadata and absolutely no actionable intelligence.

So why couldn’t they include a URL? The guy in that video says URLs are forbidden. He says you can’t provide a URL, for fear that you’ll swamp the server that’s being sent. That sounds banananoodles, and I haven’t found any relevant order to that effect. In fact (and I’m obviously not an expert here) item 422³ of FCC’s fifth report-and-order on IPAWS on the Emergency Alert System, which is for TV and radio, seems to explicitly encourage participants to show URLs, video, images, and whatever else the authorities can stuff into a CAP message. So why so careful about mobile phones? I have no idea.

So, excellent. I now understand how the national alerting system works, and I know I can blame Verizon for that horrible, awful, no-good Amber Alert.

Learn More

• If you want a grant from DHS for the IPAWS software, that’s available.
• There’s a mailing list for IPAWS practitioners, too, which I totally signed up for.
• The CAP standard is managed through the OASIS Emergency Management Technical Committee.
• Wikipedia is good enough to provide a list of public CAP feeds.
• open source EDXML framework from MITRE which implements the CAP standard in .NET
• cap-library is the open source Java implementation.
• Art Botterell keeps a pretty great CAP Cookbook wiki.