Emergency Messaging for Digital Signage: an Asset or a Liability?

October 15th, 2007 Brian Dusho

There is a lot of talk in the industry around whether or not digital signage networks should participate in the Emergency Alert System. Although digital signage networks are not yet obliged to do so (they are not included in the list of media that are required by law to participate in the EAS), this looks like a temporary situation that may soon be legislated, given the growing reach of digital signage.

Even in the absence of the legislation many networks have recognized the need to incorporate the EAS or other types of emergency alert systems. Often the nature of the venue demands this functionality (for instance, student campuses, hospitals, arenas, etc.)

Today the proactive network owners are approaching this “need” in a way that makes them responsible for gathering the information, putting the information in a content format and then wanting to push this information to the screen, thus disrupting the current program. There is definitely a tremendous value in providing this service, when it’s done right, but at what cost?

My concern is that on occasions the network owners will not be able to implement the alerts within acceptable time-frames. How long will it take to get the information? What should be the response time limit? What format should it be displayed in? What content needs to be associated with it? Who should approve the message and the final output? After all this is sorted out and the Send button is pressed – the emergency could be over and who is now liable?

Common Alerting Protocol (CAP) is an ‘XML-based data format for exchanging’ messages between alerting technologies. It ‘allows a warning message to be consistently disseminated simultaneously over many warning systems to many applications’ (definition by Wikipedia). We should evaluate this process as an option to our industry as it may be a more reliable and appropriate technology, and create a standard process for delivering emergency alerts to Out-of-Home Video Networks.

Entry Filed under: Uncategorized

1 Comment Add your own

  • 1. Bryan  |  October 16th, 2007 at 1:00 pm

    This is an excellent point. CAP is definitely the direction that network operators need to be heading in as opposed to an “emergency push” approach. However, certain challenges remain before large scale implementation can begin.

    1) Availability. As of this writing, there are remarkably few publically accessible CAP feeds. As time goes by, more and more governments and companies should gravitate towards the standard.

    2) Scalability. By their very nature, emergency messaging systems are vulnerable to the Slashdot Effect because as soon as a message is posted, all recipients require it immediately. This can place a high load on the CAP server and stress its available burst bandwidth. Any reduction in QoS will introduce delays that diminish the value of the message. An alternative would be to push out the message via satellite multicast, however, usually multicast providers allow you only a certain window of time each day. If your emergency does not fall within your provider’s multicast window, it will be irrelevant by the time it is delivered.

    3) Security. Network operators typically want emergency messages to preempt the regular schedule and/or preempt the entire display by going fullscreen. That requirement makes it a very dangerous feature because it introduces a means to easily hijack a digital sign. This is compounded by the fact that CAP is typically disseminated over regular HTTP which is vulnerable to all kinds of man-in-the-middle and DNS-based attacks. Using HTTPS and enforcing verification of the server’s certificate on the client side would go a long way to mitigate this risk, however, CAP providers really aren’t thinking about security yet, they seem to be more in the proof-of-concept phase.

Leave a Comment

You must be logged in to post a comment.

Trackback this post  |  Subscribe to the comments via RSS Feed


Broadsign

Subscribe to this blog

Calendar

October 2007
M T W T F S S
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Most Recent Posts