Sunday, April 22, 2007

Blueprint for An Emergency SMS Messaging System

An hour or two after my last post, I talked with the members of my group about possibly implementing an alert system that would send out an SMS text message to faculty, staff, and students at the university, something that would help get the word out should a shooting occur at our university. That was Tuesday morning.

By Friday afternoon, I had finished two ColdFusion-powered portlets for our still-relatively new university portal: one that let members of the university enter their SMS information, and another that let select individuals send out an alert message using that information.

The code is unremarkable, but I wanted to share the ideas behind those portlets as inspiration or guidance for others.

We decided to design the system to use the SMS gateways provided by the cell phone service providers themselves: almost all of the major providers allow you to send an SMS to someone via an e-mail address comprised of the recipient's cell phone number and an e-mail domain specific to the cell phone provider (for example: would be the e-mail address to send an SMS to a T-Mobile user with a cell phone number of 555-555-5555). My manager found a list of these gateways on a LiveJournal page, and I found a similar page at Wikipedia.

The sign-up portlet (if put into production) will appear in everyone's portal page. The portal takes care of authentication, so the portlet retrieves the unique portal ID of the user from the portal without requiring additional authentication. The portlet window contains some text explaining the service and how it will be used followed by a simple form: a select box containing the names of the different cell phone services that provide cell service in the area, and a text box for the user to provide their cell phone number or their cell service username.

The form is followed by three form buttons. The first button, the "Save" button, submits the form data to be saved to a database table. Basic JavaScript validation is used to make sure that the user has selected a cell service provider and has provided a phone number or username: if the user has JavaScript disabled, similar server-side validations will take place.

If the data is valid, it will be recorded in the user's database record. The record will contain the user's unique ID, the unique ID of the cell service provider (which matches up with a record in the table containing the service providers and their SMS gateway addresses), an encrypted copy of their cell phone number/username (so that data is protected if the database table itself is compromised), and the current date signifying the last time the information was updated. Once the information is recorded, the user will see a message at the top of the portlet indicating whether the data submission was successful or not.

The second button, the "Save and Test" button, triggers the same actions as the regular "Save" button but also executes code to send the user a test SMS message using the SMS information they provided. The message is sent using a tag directed to the e-mail address comprised of the phone number/username and the SMS gateway of the cell service provider. The message contains a unique test message ID number that corresponds to the primary key value of a test message log table. The records in that log table also contain the ID of the user who generated the test message, the IP address of the user's computer, the SMS gateway and an encrypted form of the number/username the message was sent to, and the date and time the test message was sent. This log can be used to determine if anyone is misusing the test mechanism to send spam SMS messages to other individuals. The user's own database record is also updated with the date they sent a test message so that we can determine if the user has tested (and therefore verified) their SMS information. Again, once the information has been saved and the test message has been sent, the user will receive a feedback message, and will be told that they should receive the test SMS shortly.

The third button is a "Removal" button so users can remove their SMS information if they no longer wish to use the service or if they are leaving the university. The button triggers code that removes the SMS gateway and phone/username data from the user's database record, but it does not remove any data the user generated in the test log (to ensure that anyone abusing the testing tool cannot cover their tracks). Again, the user will see a message indicating whether or not the action was successful.

Once users have submitted their SMS information, they will see that information populated in the form on subsequent visits to the portlet. If the "last updated" date in their database record is over 6 months old, they will see a message at the top of the portlet window indicating that they should review their information to make sure it is current and to click the "Save" button to indicate this (thereby resetting the "last updated" date).

The administrative portlet, like the sign-up portlet, retrieves the unique portal ID of the user from the portal without requiring any additional action from the user. However, it then compares that portal ID with the records in a database table that lists the authorized users of the administrative portlet. That table contains the records for two types of users: technical administrators who can only use the portlet to send test messages to users who have agreed to be testers of the service (such users have an additional data field populated in their user database record), and emergency administrators who are allowed to send an alert SMS to all users of the system in an emergency.

If the portal user is a technical or emergency administrator, the portlet redirects them to the appropriate starting page, while unauthorized users are prevented from proceeding (technically, unauthorized users would not have access to the portlet at all anyway). Technical administrators are presented with a single hyperlink that gives them the option to compose and send a test message to the test users. Emergency administrators have that hyperlink as well as the hyperlink to the form for sending a true alert message.

Even though the processes for sending a test message and sending an emergency message are very similar, separate submission forms are used as a security measure to ensure that only emergency administrators can send an emergency message. Each form also checks the user's credentials to make sure they are authorized to perform those particular actions.

The forms for composing a test message and composing an emergency message both consist of a textarea control and a submit button. The directions preceding the forms are slightly different: emergency administrators using the emergency message form are reminded that while they can send more than one message, a second or third message may be delayed by increased cell traffic generated in response to the first message, and to keep that in mind when composing the initial message. Technical administrators (and emergency administrators using the test message form) are reminded that their test message should clearly indicate that the message is a test message and not a real one.

Beneath the textarea control are two text blocks, one that indicates the number of characters in the textarea and one that counts down the number of characters used from a starting number of 110. The number of characters an SMS message can contains varies between cell service providers. Based on the information we had on the SMS gateways our users would use, we decided that 110 characters was the number of characters almost all users would be able to receive, and that 140 characters was the upper limit of characters we would allow.

As the user types, a JavaScript function fires every time a key is released that counts the number of characters currently in the textarea and then uses that information to update both counters. Any user with JavaScript enabled will know exactly how long their message is and whether it exceeded the safe 110 character limit. If the message exceeds 140 characters when they submit the form, a JavaScript alert box will inform them that they need to shorten the message. If JavaScript is disabled, server-side validation code will perform a similar task.

Each of the form pages is followed by a confirmation page, where the user is asked to confirm their decision to send the test message or emergency message. The user is shown the message they composed one more time. Any characters beyond the 110 safe character limit in the message are shown in red to indicate to the administrator what text might be truncated and therefore not received by some recipients. Following the message are two form buttons, a confirmation button and a cancellation button.

If the user clicks the cancellation button, they will be sent back back to the composition screen along with the text of the message (so the contents of the message are not lost if the user merely wants to make some changes to the content).

The confirmation button for sending a test message retrieves the SMS data for all of the users identified as test users, while the confirmation button for sending the emergency message retrieves that information for ALL users. The code then loops through those query results. During each loop iteration, the user's cell phone number/username is decrypted and the message is sent via to the address comprised of the decrypted number/username and the SMS gateway of the user's cell service provider. Once all of the messages have been sent, a new record is recorded in a database table that logs all messages sent by technical and emergency administrators: each record contains the administrator's ID number, the text of the message, the date and time the message was sent, and a value indicating whether the message was a test message (that only went to test users) or not. These log records ensure that anyone who sends out an unauthorized message can be identified.

Once the message has been processed, the administrative user will be returned to the appropriate composition form and will see a message indicating whether or not the message was successfully sent out. The user can then opt to send another message or return to the initial portlet screen. there you have it.

A stand-alone application designed to perform similar tasks would have to include an authentication system, and might have to run a scheduled task to check the age of each user's SMS data and send them an e-mail if their data was old, but I think everything else could be designed to work in a similar manner to the system I just outlined.

Tuesday, April 17, 2007

Twitter as Alert System?

Yesterday's tragedy at Virginia Tech underlined the importance of sending out warnings regarding dangerous situations as quickly as possible and through as many channels as possible.

Listening to the news last night, it sounded like the VT administration used every channel of communication at their disposal: the campus website, mass e-mails, broadcast phone messages to all campus phones, and a siren system. The university I work at (the University of Maryland) also has all of those means of getting the word out.

The one communication channel that wasn't mentioned, however, was cell phones. That's not surprising: I suspect few universities specifically collect cell phone numbers from their students, and most students would probably be hesitant to give their cell number to the university out of privacy concerns.

But in light of yesterday's events, maybe universities should rethink that issue. Messages sent to land-line phones and e-mail addresses are only received if the recipient is at their phone or is actively checking e-mail. A message sent to a cell phone, which folks usually carry with them, has a much better chance of getting the recipient's attention immediately, even if they are walking between classes. While not every student owns a cell phone, those that did and received the message could spread the word to the people around them, getting the word out much faster.

So let's assume universities offered to send emergency messages (and only emergency messages) to students who provided a cell phone number to contact: how would the university broadcast an alert to those phones?

A long-term solution would be to put a SMS messaging system in place at the university designed specifically for this purpose (universities like mine that run ColdFusion 7, for example, could build an application using the SMS Gateway service provided by the ColdFusion server).

A short-term solution could be Twitter. Twitter is a social networking tool where you can receive short messages from friends via a web page, IM, or via SMS.

A university could set up a Twitter account to use to send out emergency messages, then instruct students to get a Twitter account (which is free) and "follow" the university Twitter account. The students can then control whether they receive updates from the university Twitter account via their phone or not.

Granted, this is not what Twitter was designed for, but I think it could serve as a stop-gap measure for getting warnings out until a more robust system is put in place.