Alissa Cooper On October - 20 - 2010

Note: This was originally posted on the Center for Democracy & Technology blog.

Two weeks ago I had the opportunity to participate at the RTC (Real-Time Communications) Web Workshop, a gathering focused on addressing what technical standards work is necessary to make real-time communications a reality on the web. Engineers and standards veterans from Cisco, Skype, Google, Mozilla, and a number of other companies spent the day debating and discussing an exciting array of potential services and applications that the union of RTC and the web could make possible, including browser-to-browser calling (even between users of different services, like Skype and Google Talk), multi-user features like conferencing and screen sharing, and browser-to-phone or browser-to-VoIP-phone calling. So many applications that were once confined to desktop software have migrated to the web, and it was exciting to spend the day identifying what needs to happen for RTC applications to join their ranks.

Although the discussions were wide-ranging, they returned time and again to the topic of securing RTC against snooping and attack. To achieve reasonable call quality, RTC more or less requires two users to be able to communicate over a direct link between them. On the web, this would mean direct browser-to-browser communication, which is uncommon today and, if implemented without proper security mechanisms, has the potential to create new avenues for attackers. As with other sensitive web communications (like bank transactions and online purchases), the communications channels also need to be encrypted and the encryption keying material secured against attack. Workshop participants gave a number of thoughtful talks about how to address these and other security challenges, and there was general agreement in the room that security risks in many deployment scenarios could be sufficiently mitigated using either existing or soon-to-be-developed mechanisms.

The discussions resulted in a sizable list of work items for technical standards bodies to consider pursuing and it was obvious that engineers in the room are already hard at work writing code to make RTC on the web come to fruition. But it struck me that their ability and incentive to do so would be drastically reduced if the FBI’s recent proposal to require communications applications to be wiretap-friendly became law. Although details of the FBI proposal remain vague, two of its core components would require communications providers to be able to decrypt encrypted messages and intercept peer-to-peer connections for law enforcement purposes. Having spent the day discussing precisely how to prevent such intrusions in RTC systems on the web, it seems unlikely that RTC applications providers would be willing to build the necessary back doors into new web-based products, especially given the fact that those back doors will undoubtedly be exploited by attackers. Given the choice between developing a new web-based application containing known vulnerabilities or not developing anything new, the latter seems far more likely.

Furthermore, introducing a mandate to retrofit existing services with wiretap capabilities would likely occupy time and engineering resources that are usually dedicated to product development and innovation. For applications developers like those at the RTC-Web workshop who have spent countless hours ensuring that the security of their products is air-tight, undoing all of that work so as to provide law enforcement access will be a sizable endeavor that will surely detract from new product development.

Bringing RTC to the web will no doubt provide a wealth of new and innovative ways for consumers and businesses to communicate in the future. But the specter of mandated eavesdropping capabilities calls all of that potential into question, not only for web-based communication, but for communications innovations of all kinds.

Categories: Standards

Leave a Reply