Modern electronic communication tools like ✉ email, ☺ instant messaging, and ✆ telephone systems have made strides in appealing to the public, but fall behind in protecting the information communicated. The protected communication infrastructure will produce deliverables after one year to help bridge this gap.
Please see competing efforts towards the end for a comparison to similar projects.
Procom serves desktop and mobile device users who seek easy communication while excercising their right to privacy via secure channels.
The project gently introduces users to core concepts of protected communication, informs them of current status, and promotes Procom deliverables via education.
Users find this information in:
One-minute Project Presentation Film
Three-minute Overview Starter Film
The infrastructure upholds the law of United Nations member states. Particularly, article 12 of the universal declaration of human rights ① is considered which states that “no one shall be subjected to arbitrary interference with his privacy, family, home or correspondence.”
Deliverables include software components and ready to use applications able to connect over common network technology according to staged releases.
Two client applications are made available. Profon RTC is a simple voice over IP application. Prochat WGT is a embeddable chat widget.
Session border controller (SBC) server applications are made available to offload procom seed service. This allows anyone with system administrator skills and (few) resources to become their own carrier‼ The DNS and STUN based SBC plays the role of a signalling broker, is independent of existing SIP and GSM practices and provides robust operation across diverse network landscapes as expected by users.
Additional client applications are made available. Procam RTC is a web cam video streaming and monitoring application. Promon RTC is a baby phone audio streaming and monitoring application. Protext RTC is a instant messaging application. All communications are protected by the same underlying procom infrastructure.
Client applications are made available to serve advanced use cases such as:
Additional service applications are provided according to client technology employed. These could include Tor, DNS, HTTP, XMPP, SIP, RTP, and IKE service or routing. The service layer is intended to be reproduced by anyone with the appropriate resources and is documented to this end.
Lastly, developer services include a collection and logical assembly procedure of protected communication building blocks. A high level recipe is provided according to developer requirements (OS, architecture) for implementing a particular use case (voice, video surveillance, text chat, email, etcetera.)
The infrastructure focuses development efforts on those emerging platforms providing the software manufacturer the most freedom. This includes Firefox OS, Tizen, and Blackberry 10 due to their high degree of web runtime conformance. It includes Sailfish and Ubuntu Touch due to their high degree of standardized (POSIX for example) interfaces.
The target goals doesn't exclude platforms however, and provide logic for systems such as Android, iOS, and Windows Phone wherever practical.
For its client back ends, the infrastructure leverages WebRTC along with its components controlling mediastreams, peer communication, data channels, and routing. Both DTLS-SRTP and SDES (assuming its standardized inclusion) are implemented through use of existing peer reviewed libraries, and wherever possible ZRTP allow for more comprehensive end-to-end encryption.
③ http://code.google.com/p/crypto-js/ (math.random)
Regardless of shifting APIs in core technology, a preliminary design proceeds. For more information please refer to the following documents to download.
The purpose of this section is to indicate the general design of Procom, a protected communication infrastructure useful for building network connected communications software. Its scope is small due to the early stage of project negotiations as well as the untested nature of the interface standards involved. The intended audience of this section includes those with knowlege in legacy communications protocols like SIP and XMPP and find value in applying WebRTC technology to similar use cases. The project is named Procom, a contraction of the terms 'protected', 'communication', and 'infrastructure.' The name describes the underlying technology leading to server and client (mostly P2P) products of similar names. The products are rolled out in stages to manage complexity. This preliminary design section is part of a larger project proposal document found on the project website. While there are no prerequisite documents, a software requirements specification is due to appear before release of a detailed design document. A number of background documents exist to complement the preliminary design and are listed above and available for download. A test plan will follow the development of a detailed design document.
The software system serves to facilitate communication between parties. Each party consists of an individual person or group of people using a single device to establish a unicast network connection. The initiating party depends on the peer to accept the connection after which data is transmitted and received over a RTCDataChannel in observation of the WebRTC standard. The basic design approach resembles that of a plain old telephone system with added features leveraging WebRTC. An exception to this design relates to automatic peers which reverse the initiation sequence and transmit on a multicast network connection.
This design attempts to leverage past successes with similar models serving similar use cases. WebRTC, the emerging standard which rests in the core of the system, necessitates a careful review of procedures to broker connections. A number of other considerations exist of which most shall be clarified in comparison to the SIP standard as well as review of existing products using other standards.
Assumptions and Dependencies
The user assumes responsibility for the care and maintenance of a working web runtime in their device. The system depends on target platforms' complete implementation of the core APIs. Namely, RTCPeerConnection, RTCDataChannel, and MediaStream APIs must be available. Hardware allowing the transmission of media as negotiated must be in good working order. In some cases, a low latency network connection provides for speech transmission and in some cases the network must be robust enough to carry UDP datagrams with few errors. Verification and validation is carried out in accordance with the test plan. Support is offered to end users on the project website to address quality goals. The user must be experienced enough to dial a typical modern full screen telephone.
The hardware environment may include battery powered devices which require optimization of energy consuming operations. As the system intends to power a number of platforms, portable APIs of the supporting software environment are prioritized. Time critical services run on client devices which in some cases are low powered, requiring adequate memory. The underlying platform must comply with the following W3C and IETF standards.
A forthcoming software requirements specification includes functional and nonfunction requirements to be observed.
Goals and Guidelines
Priority to portable APIs and attention to simple constructs dominate the design. In principle, complex behaviour or feature bloat is avoided and high cohesion embodies the design of the system. The project should produce releases that work, look, and feel like an existing product to improve the user experience.
It is expected that few developers work on this project and as such little attention has been given to negotiation of a development method. While the waterfall method is generally avoided, clear software engineering documentation is valued in accordance with the project plan, with a weak intention to apply the agile engineering method.
Policies and Tactics
Protection against government censorship and ☣ secret court orders is provided by implementing the ☠ dead man's switch design pattern, in which regular transparency reports indicate lack of manipulation:
☢ The Procom seed service has received zero secret orders from law enforcement and spy agencies. Watch closely for this notice to disappear.
HTTP and Websocket transmissions are encrypted using TLS. Self signed certificates are acceptable in deliverables before stage 5.
Where conditions (bandwidth, latency, technology, use case) allow, defense against surveillance is improved by means of IP route anonymization on OSI layer 7 and data encryption on OSI layer 3.
Being that code and concept reuse from existing solutions is maximized, a careful review of other projects must be undertaken. Key concepts receiving scrutiny include:
…with implementation of the most practical match to the use cases motivating the project and attention to avoid storing keys on any server.
As the number of candidate mobile platforms and associated communication standards mature, the utility of tactics employed depends on a clear understanding of interoperation. Research will determine just which combinations are practical and how far to take the principle of implementing the least common denominator.
A mobile client built on the infrastructure determines the standard technology in use and interoperate with other clients regardless of manufacturer. An example of this procedure could involve inspection of URI syntax, and resolution (with security implications) of DNS based (ENUM, SRV, NAPTR) and local (contacts database) communication endpoints.
If Procom grows to include email protection or digital commerce (like bitcoin), it will likely reach such distant goals after consideration of a carefully planned road map.
A number of other groups have produced infrastructure falling short of the goals stated here, despite similar intentions and interests. Regardless of this, outreach has resulted in ongoing cooperation with important competing project developers.
A number of proprietary infrastructures allowed for communication, but forbid peer review or required nonstandard extensions or plugins to work. Such RTC implementations included Flash ⑤, Silverlight ⑥, and Java ⑦. While solving the email use case, pretty good privacy (PGP) ⑧ failed to solve others as well as being too complicated for most tastes. Others like Skype and WhatsApp achieved notoriety for bait and switch tactics swaying users from open standards.
Other infrastructures mostly conforming to standards include those manufactured by Whisper Systems ⑨, Silent Circle ⑩, Wickr ⑪, and Heml.is ⑫12. Although their implementations are open source they lack portability, in all cases producing code appropriate for a fraction of the mobile platforms available.
Additionally, many of these solutions enforce a business model through requirement of a opaque server component, reducing freedom of choice in network topology ☍.
Cryptocat ⑬, Scramble ⑭, and Mailpile ⑮ deserve special mention in that they almost fulfill the project interests. While components taken from them could be be reused, unfortunately these projects fail to completely meet all goals.
The Procom project is presently seeking an investment partner to work with existing management and engineering staff. For information, please contact management .
A business plan is available on request.
The file or operation you chose is not available due to the early stage in which the project still finds itself. Please try again another day.
Michael Schloh von Bennewitz is a computer scientist specializing in network software, mobile computing, and client server design. Responsible for development of network software and maintanance of packages in several community software repositories, Michael actively nourishes the Opensource development ecosystem.
Michael additionally speaks at technical events every year. He has lectured for companies and events including Cable & Wireless, Nokia, Intel, the Linux Foundation, Mobile World Congress, DroidCon, AstriCon, and ClueCon.
For more about Michael see http://michael.schloh.com/