Search Results

Search Results for: hancke

Philipp Hancke

Coming from a chat/signaling background I’ve had the amazing opportunity to work full-time on WebRTC since 2012 in a number of positions which has allowed me cover a wide range of topics from exploring what is possible with the WebRTC API in the browser to running large scale distributed SFUs and tinkering with mobile applications. It has been an exciting journey!

Understanding how WebRTC is used and what we can learn as a community from that has been one of my favorite topics here on WebRTC hacks, resulting in the blackbox exploration posts. ...  Continue reading

Hello, Hello – What’s your real story? A decode by Philipp Hancke

There have been many major WebRTC launches in the past months including Facebook and KimDotCom. Before those, Mozilla started bundling a new WebRTC calling service right into Firefox. Of course we wanted to check out to see how it worked.

To help do this we called on the big guns – webrtcHacks guest columnist Philipp Hancke. Philipp is one of the smartest guys in WebRTC outside of Google. In addition to his paid work for &yet he is the leading non-googler to contribute to the webrtc demos and samples and is also a major contributor to the Jitsi Meet and strophe.jingle projects. Google even asks him to proof-read their WebRTC release notes. ...  Continue reading

How is WebRTC doing and who is driving usage? (Hint: Google Meet)

I have been looking at these Chrome usage statistics available on chromestatus.com for a while together with Tsahi Levent-Levi for WebRTC Insights but they are too fascinating to keep them behind our paywall. Let’s do some coffee ground reading on the usage of a number of important APIs and what it tells us about what drives WebRTC in Chrome:

Google Meet.

Meet (or back in the day Hangouts) is a major driver for WebRTC to Chrome. It is no secret Google invests heavily in this area – surprisingly the only major party doing so. The data shows why. ...  Continue reading

Apple’s not so private relay fails with WebRTC

Apple released iOS 15 with iCloud Private Relay broken for WebRTC - it still divulges your IP address. This post walks through why and how the WebRTC API's use your IP address information and how you can check what IP addresses are gathered.

FaceTime finally faces WebRTC – implementation deep dive

During this year’s WWDC keynote, Apple announced the availability of FaceTime in web browsers, making it available to Android and Windows users. It has been six years since the last time we looked at FaceTime (FaceTime Doesn’t Face WebRTC) so it was about time for an update. It had to be WebRTC and as I’ll show – it is very much WebRTC.

tl;dr

FaceTime Web does use WebRTC for media and it uses the Insertable Streams API for end-to-end encryption. It also uses an interesting approach to avoid simulcast.

Fortunately, my old friend Dag-Inge Aas was around to set up a meeting and helped me grab the necessary data for analysis. Tooling has become a bit better since so in addition to the WebRTC internals dump I got an RTP dump and an SCTP dump from the Chrome logs as well as some of the JavaScript that does the end to end encryption (E2EE).

RED: Improving Audio Quality with Redundancy

Back in April 2020 a Citizenlab reported on Zoom’s rather weak encryption and stated that Zoom uses the SILK codec for audio. Sadly, the article did not contain the raw data to validate that and let me look at it further. Thankfully Natalie Silvanovich from Googles Project Zero helped me out using the Frida tracing tool and provided a short dump of some raw SILK frames. Analysis of this inspired me to take a look at how WebRTC handles audio. In terms of perception, audio quality is much more critical for the perceived quality of a call as we tend to notice even small glitches. Mere ten seconds of this audio analysis were enough to set me off on quite an adventure investigating possible improvements to the audio quality provided by WebRTC.

True End-to-End Encryption with WebRTC Insertable Streams

A couple of weeks ago, the Chrome team announced an interesting Intent to Experiment on the blink-dev list about an API to do some custom processing on top of WebRTC. The intent comes with an explainer document written by Harald Alvestrand which shows the basic API usage. As I mentioned in my last post, this is the sort of thing that maybe able to help add End-to-End Encryption (e2ee) in middlebox scenarios to WebRTC.

I had been watching the implementation progress with quite some interest when former webrtcHacks guest author Emil Ivov of jitsi.org reached out to discuss collaborating on exploring what this API is capable of. Specifically, we wanted to see if WebRTC Insertable Streams could solve the problem of end-to-end encryption for middlebox devices outside of the user’s control like Selective Forwarding Units (SFUs) used for media routing. ...  Continue reading

Does your video call have End-to-End Encryption? Probably not..

Time for another opinionated post. This time on… end-to-end encryption (e2ee). Zoom apparently claims it supports e2ee while it can not satisfy that promise. Is WebRTC any better?

Zoom does not have End to End Encryption

Let’s get to the bottom of things fast: Boo Zoom!

I reviewed how Zoom’s implements their web client last year.

I’m not really surprised of their general lack of e2ee given that their web client did not provide any encryption on top of TLS or WebRTC’s DataChannel. For reasons we will discuss below, this means they weren’t doing any obvious e2ee there. ...  Continue reading