The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts – whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points – a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.

The Concept

Last year, I was involved in a project in New Zealand to produce an investigative report on Public Alerting Systems with the New Zealand Centre for Advanced Engineering. This report will hopefully soon go public, and I’ll provide a link when it does.

This report was looking at the different technological solutions for getting alerts out to people in as timely a manner as possible. At one point in the search for different systems, we started discussing means of injecting HTML in web pages via an ISP, so that a public alert could be sent out to anyone on the Internet. I’ll talk about this and other options later. Let me get to the point of this post.

After starting at the HTML injection idea, and progressing through a few others, I reached a kind of natural conclusion that a more suitable means of alerting users via a web browser would be a browser plugin that can subscribe to Common Alerting Protocol (CAP) feeds, and when a relevant alert comes in via CAP, this is displayed to the user in their browser using the XUL:notificationbox at the top of the webpage.

Draft Requirements

Anyway, a possible idea for a Google Summer of Code 2009 project is that of constructing a browser plugin for Firefox that implements this alerting capability, and expanding Sahana to support full publishing of CAP alerts. Here are some features it could/should support.

Firefox Plugin

• Bundle publicly available CAP feeds (ideally listed in a nice Country/State taxonomy – this will make it easy to discover and utilise existing CAP services.
• Allow users to optionally register location in some manner, so as the plugin can identify relevant alerts (by location) and give them higher status than say remote alerts. Users should be able to register multiple locations – whether it has home & work, or multiple cities. Privacy is of course king and this information must be protected.
• Provide a means of adding additional user provided CAP feeds to the plugin.
• Provide the ability to open the alert in a new tab and format in a human-readable manner, including niceties such as embedding Google Maps to show geospatial information and links back to the source website of the alert for verification.
• Implement means of verifying messages that are digital signed, and decrypting encrypted messages.

Sahana

• Implement a CAP feed in Sahana so that Sahana can act as both a producer (in terms of creating a CAP message) and a publisher (in terms of making it available via a CAP RSS/Atom feed).
• Implement a CAP proxy or similar, so that say all users of a Sahana server can obtain CAP alerts directly from the Sahana server – rather than going to an external website. This may be useful for distribution of alerts within an organisation or centre without having every client browser connecting to an external server.

What would be very nice, but may be beyond the capabilities of Sahana servers currently, is making the CAP service on a Sahana server easily discoverable on a LAN via zero-conf services such as Bonjour.

Draft Outcomes for Assessment

The outcome of such a project would be to produce a working solution whereby a Firefox Browser plugin is capable of working with public CAP alerts and that CAP within Sahana is capable of fully acting as a CAP server via RSS/Atom feeds to the CAP alerting plugin.

Compulsory

• Implement the specified requirements
• The browser plugin works as expected with publicly available CAP feeds.
• The browser plugin works as expected against the Sahana demo server. (Yes, this means that your modifications to CAP on SahanaPHP need to be implemented).

Optional

• Implement the Sahana CAP server in SahanaPY
• Provide one or more standalone CAP clients for a mobile platform e.g. Google Android, Apple iPhone/iPod Touch etc
• Write an Internet Explorer plugin with similar functionality – it is important that this functionality is also provided for IE given its widespread usage and deployment.

Whilst the plug-in can and should operate completely independently of Sahana, it should also be designed to work well with Sahana servers (e.g. SahanaPHP and SahanaPY).

Anyway, this is just an idea I wanted to float and get out in the community for discussion. I’d welcome any further comment or ideas to build upon this!

This GovTech article spawned the discussion on the IAEM email list. Twitter is certainly not a robust notification system, but it is a social messaging system that does have its place – particularly for interacting with the public.

Concerns were raised about how Twitter usernames could masquerade as offical agencies, and other issues around the authority of information provided on Twitter.

In reply on the list, I made the following brief comments that may help an agency adopt and utilise a social network such as Twitter and mitigate some of the issues.

Hi Eric,

Some valid concerns about the risks, but there are always means of mitigating them.

1. Re: Globalisation – one of the biggest issues you missed is that of privacy and the protection of private information submitted and stored in these systems. Ironically, the United States is one of the few civilised countries that doesn’t provide wide-ranging privacy protections when compared to European countries and the likes of New Zealand that have very strong privacy legislation. The way information submitted to social networking sites vary significantly depending on the jurisdiction it is hosted in. As many sites are hosted in the United States, it would indeed be good to see the United States implement stronger legislation protecting personal information (e.g. to the level provided in Europe and New Zealand, not sure on Canada, and I think Australia might fall somewhere between US and NZ).

2. As per any form of public alerting/notification, it is important to teach the receiver that they should attempt to cross-check, verify, and go hunting for more information. One technique that was mentioned in the Govtech article linked earlier in this thread was using TinyURL to embed links to official websites to provide corroboration of information, or more detailed information than can be wedged into the 140 characters provided by Twitter. Likewise, agencies should put pages up on their websites that act as a means to identify their official Facebook page, official Twitter username etc. Not only can they point out their official Twitter username for example, but they could also identify usernames that may be masquerading as that organisation. You could use the Twitter > Profile > More Info URL to link back to this page on a web site that the agency controls. It is still not perfect, but it would provide a far more robust approach for providing evidence that a given Twitter username does represent an official person/agency.

3. Official and unofficial directories of usernames can be provided e.g. <http://govtwit.com/> These can be constructed and the people/organisations using them can contact the organisations to verify that they do indeed manage that username. This, again, allows for a far more trustworthy list of official representatives to be constructed. A state EM organisation for example could maintain a web page on their official website that lists all the official EM and related agencies Twitter usernames in that state. As long as you have a trusted representative constructing the directory, there is less concern about those usernames in the directory as they will perform the authentication for you. E.g. IAEM may elect to build a register and maintain it on our website.

4. If an agency finds someone masquerading as their organisation, they can always approach say Twitter, and highlight the problem username and that they do something about it. Twitter is a private company in San Francisco. E.g. if the unofficial usdhs Twiiter username started spreading false information during an emergency, I’m sure a call from DHS to Twitter in San Francisco would fix that fairly quickly.

The whole idea of social networks is that you build your own network of trust. This means that there is some work associated with constructing it, but there are a number of means to build this web of trust – some of which I’ve mentioned above. Link with other official agencies, link to it from your official websites that you control. Fake usernames will not be able to compete with this and will quickly be identified as fakes as they will not be able to build up a web-of-trust.

And yes, social networks are not for secure communication. They are to get information out and widely disseminated as quickly as possible.

One reason sites like Twitter have become so popular with the public is because they can get information quicker than we, as emergency managers, are able to otherwise provide it. That sends a pretty strong message that we need to do better in terms of getting information out to the public.

Cheers Gavin

I’ll try and expand on this in the not-to-distant future – I might end up writting an article for the IAEM Bulletin. As an aside, a related topic is how to use tags to identify emergency management related posts on a social network site such as Twitter. I’ve passed this on to the EIIF W3C Incubator Group I’m involved with as I believe that any tagging structure needs to be compatible with other standards used for emergencies and disasters. This way software could watch out for certain tags to pick them up and into a disaster management system such as Sahana.

Once again the key point is trying to create an integrated approach to an emergency management information system (EMIS) – the software is only half the deal, the other half is the suite of information standards to communicate with other systems. Any tags designed for Twitter, much be designed in a way that an EMIS can search, gather and try to understand them.

• 3n Online
• Alertus
• American Emergency Notification
  
• Blackboard Connect
• CityWatch
• clearTXT
• CodeRED
• Contact One RegionCast
• Dialogic Communications
• e-sponder
• Emergency Notification Systems
• Emergeo
• GDACS
• Groupcast
  
• Hormann America
• Intrado
• MadahCom
• MessageOne
• Midland Radio
• MIR3
• PAETEC
• Rave Wireless
• Reverse 911
• Roam Secure
• Send Word Now
• SevereAlerts.com
• SquareLoop
• Thunder Eagle
• Twenty First Century Communications
• Universal Alert
• ViaRadio
• VoiceGate
• Zingerang