Frequently Asked Questions
Usability
Whiteflag is a digital communications protocol based on blockchain technology to provide an open, near real-time, trusted communication channel between any or all parties in an armed conflict or in disaster areas, without the requirement for a trusted third party or any specific software or system. It is developed for use in addition to any currently existing but limited and unreliable communication methods such as flags, signs, e-mail, registers, etc.
Current armed conflicts are highly complex, because of the sheer number of parties involved: regular military forces, armed groups, peacekeeping forces, neutral parties such as journalists, non-governmental human-rights and aid organizations, civilians, refugees etc. Even though parties are opposing forces, or neutral organizations that do not want to show any affiliation, they do require to quickly and directly communicate to one or more other parties involved for deconfliction, to create shared situational awareness, to minimize collateral damage, to prevent unnecessary loss of life, etc.
Whiteflag uses a pre-defined but extensible set of messages, to prevent misunderstanding and ensure interoperability with existing standards and classifications. Note that Whiteflag messages are not human readable, but intended for processing by devices, e.g. to display information on a map.
The following functional message categories are currently defined in the Whiteflag protocol:
| Protective Signs | Signs to mark objects under the protection of international law |
| Emergency Signals | Signals to send an emergency signal when in need of assistance |
| Danger Signs | Signs to mark a location or area of imminent danger, e.g. an area under attack, land mines, disaster, etc. |
| Status Signals | Signals to provide the status of an object, or specifically for persons: give a proof of life |
| Infrastructure Signs | Signs to mark critical infrastructure, e.g. roads, utilities, water treatment, hospitals, power plants etc. |
| Mission Signals | Signals to provide information on activities undertaken during a mission |
| Request Signals | Signals to perform requests to other parties |
| Resource Messages | Messages to point to an internet resource with additional information |
| Free Text Messages | Messages to send a free text string to clarify and provide context to other messages |
Additionally, parties can reference other messages with a series of referencing options, allowing for more refined communication. More details on message functionality, such as all individual message types, can be found in Section 2.4.2 of the Whiteflag Protocol specification.
Yes, anyone can send Whiteflag messages provided they have internet access and a software application to handle Whiteflag messages. Sending messages only requires a blockchain account with sufficient funds to send a transaction on the underlying blockchain.
Yes, anyone can receive Whiteflag messages provided they have internet access and a software application to handle Whiteflag messages. Nothing else is required since all information on a public blockchain is retrievable by everyone.
No, only unencrypted Whiteflag messages can be read by everyone. Encrypted messages can only be read by the intended recipient. Actually, Whiteflag messages are not meant to be read by humans at all, but are to be processed by computers, e.g. to be displayed on a map.
Whiteflag is always and globally accessible as long as the underlying public blockchain is available. Whiteflag is technically not limited to regions or times of conflict or disaster.
As with any communication system, connectivity is a basic requirement for the use of Whiteflag. In areas where there is no widespread availability of broadband internet, there are typically all sorts of alternatives, such as satellite telephones and cellular services that can be used to send or receive Whiteflag messages. Because a single Whiteflag message requires less than 80 bytes, Whiteflag messages can be efficiently relayed in bandwidth constraint environments.
Yes, Whiteflag provides a mechanism to update earlier information. However, the protocol does not prescribe how incoming messages and updates should be processed, trusted and used; that is implementation depended because it is for the receiver to decide how to appraise the new information.
Technology
No, Whiteflag is not a blockchain in itself. It utilizes existing public blockchains with which Whiteflag applications interface.
There is no controlling actor within the Whiteflag network, just as there is no controlling actor in the underlying public blockchain network and just as there is nobody who owns the internet. The protocol is released in the public domain and the underlying blockchains are open, decentralized systems.
A Whiteflag message is embedded in a blockchain transaction. Depending on the underlying blockchain network, a small transaction fee has to be paid, typically a few cents. There are no platform or license costs.
Technically, Whiteflag can be used unlimited and everywhere where there is internet connectivity, as it is based on free and open blockchain technology. However, the usage of Whiteflag signs and signals may be subject to local and/or international laws. For example, the usage of protective signs is subject to International Humanitarian Law and misuse of protective signs is a punishable violation under local and international laws.
The trustworthiness of information is typically determined by the recipient based on the reliability of source and the credibility of information. Whiteflag has a unique combination of characteristics to help participants assess trustworthiness of information, such as:
- Verification of originator: authentication is required to send Whiteflag messages and therefore one can immediately determine the authenticity of the source;
- Confirmation of messages: participants can, for example, recall, update and confirm messages in the blockchain;
- Blockchain persistence: blockchain technology guarantees that messages cannot be altered after posting and sent messages cannot be repudiated.
These characteristics are all described in detail in the Whiteflag Protocol specification.
Theoretically, there is no maximum number of participants that the blockchain technology is able to support. However, in times of very high transactional load it could happen that the processing time of a Whiteflag message takes longer than usual.
No. Up until this moment, there is no independent, geopolitical neutral network for sharing near real-time information globally with the same level of data integrity. Whiteflag is unique because it is a “whitebox”: participants have full transparency regarding the information that is shared, as well as how the information is processed.
To make a request for a new feature, or to report an error in the specification, please raise an issue on GitHub.
Implementation
No, The Whiteflag Protocol does not replace any existing system, standard, regulation or means of communication, just like e-mail did not replace the telephone. Whiteflag should be seen as an additional means of communication that can be integrated into an organization’s existing information system landscape.
The Whiteflag Protocol specification has been released in the public domain and is free to use. This protocol specification is a communications standard that contains all required information to build an interface to use Whiteflag on, in principle, any blockchain.
Whiteflag is not a software application, but a digital communications protocol. However, there is a low-level open source software implementation available on GitHub as the Whiteflag API (Application Programming Interface). This Whiteflag API is a so called Minimum Viable Product (MVP), which means that it only supports the core features of the Whiteflag protocol for development and test. Since there is a huge range of possible Whiteflag use cases and user environments for different organizations, organizations are advised to develop their own software to integrate Whiteflag in their existing information system landscape.
In theory, any device or system (e.g. smartphone, tablet, laptop, vehicle, drone, etc.) can be used, provided that it has some sort of internet connectivity and software to process Whiteflag messages. Obviously, the suitability of the device and the required software depends on the organizational needs and use case.
First of all, it is important to determine how Whiteflag may contribute to your organization’s mission and operations; the Whiteflag Foundation can provide advice and assistance in this. Secondly, familiarize yourself with the technicalities of Whiteflag, more specifically the protocol specification on GitHub, and possibly also the available software implementation, in order to assess how Whiteflag can be implemented, e.g. build a mobile app, or integrate Whiteflag in an existing system. The Whiteflag Foundation, open source community, startups and commercial IT-companies may be helpful partners!
Potential Risks
As with all information, especially in conflicts, there is always a risk in sharing information. However, this is not a risk specific to Whiteflag as participants always need to assess carefully whether certain information can be shared, especially if publicly posted (like on social media). In addition, for cases where non-public information needs to be shared selectively, the Whiteflag protocol supports strong encryption. Besides, the Whiteflag protocol is designed in such a way that it does not reveal any information about the intended recipient and, depending on the authentication method, also not about the originator.
No. Even though nobody controls access to Whiteflag, Whiteflag does require authentication. The most common method of authentication requires both a private blockchain key and access to a public web resource owned by the participant; even if the public web resource is compromised, someone with ill intent would still need the private key to send a Whiteflag message on behalf of the participant. Of course, appropriate security measures should have been put in place to safeguard the private key and other critical elements.