Last night TokBox released patches to the OpenTok iOS and Android SDKs to resolve a recently identified OpenSSL vulnerability that affects the majority of web service providers.
In early June, a security advisory was issued by OpenSSL, quoting the following:
‘An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.’
OpenTok Mobile SDKs, Revision 2: The Video Driver
In the latest versions of the OpenTok SDKs for iOS and Android, everything is new. We found an opportunity to learn from the lessons of the past two years, and seized it to conduct an overhaul of the architecture of the client. The 2.2.0 release of the iOS and Android SDKs marks the second major revision of the implementation of the OpenTok Mobile SDKs. This post highlights one of the many new features of the 2.2.0 SDKs, about which we are feeling particularly excited: the “Video Driver”. Although the feature exists with parity in both platforms, today we’ll focus on the iOS-variant of the new API.
Nearly 7 months ago, we publicly announced that the OpenTok API would extend its reach to native mobile application developers by publishing the OpenTok iOS SDK. In the time since, we have tightened the performance of the SDK runtime for iOS devices and spent a good deal of time learning about how best to deliver video to the mobile platform. While iOS commands a large portion of the mobile app market, it is intuitive that we should build similar SDKs for other popular platforms outside of the browser. It is a pleasure to announce that we are developing the OpenTok Android SDK, to allow native Android developers to bring live video chat to their apps.
Several partners have been asking us about the options around getting access to media streams as they come and go from an iOS device. While more robust media access features are further off, I wanted to take some time to explore the options an iOS developer can play with today.
The UIKit view hierarchy integrates with a fairly simple animation and compositing API. Every instance of UIView is backed by an animation layer (CALayer), which can be accessed (and manipulated) without much complexity. A neat thing about CALayer is that you render its contents at any time using the
renderInContext: method. Most often, your render target is the window, which is managed by the UIKit view hierarchy, so none of this knowledge is particularly compelling. Unless of course, you wanted to render the contents of the animation layer to a bitmap in memory to perform, say, facial recognition with the iOS 5 CIDetector.
We’ve been working on this project for a few months and are pretty excited to showcase how it’s made and what it can be made to do. I’d like to share some stories that happened along the way.