Profile

Cover photo
Justin Uberti
Works at Google
Attended University of Virginia
3,726 followers|773,219 views
AboutPostsPhotosYouTubeReviews

Stream

Justin Uberti

Shared publicly  - 
 
Nice article by +David Auerbach about his role (on the Microsoft side) in the AIM-MSN Messenger war. Definitely worth the $3 cost of the issue.

https://nplusonemag.com/issue-19/essays/chat-wars/

Many times, I wondered what the MSNM folks were thinking as we (at AOL) played this cat and mouse game, and this trip down memory lane did not disappoint:

Maybe a week after the blocks had stopped, I came in to work to find that Messenger had been blocked again, but this time it was different. The AOL server was sending a huge chunk of new gobbledygook that I could not understand. [...] Our client just ignored it, but the AOL client responded to this gobbledygook with a shorter version of the same gobbledygook. I didn’t know what it was. It was maddening. After staring at it for half a day, I went over to Jonathan, a brilliant server engineer on our team, and asked what he thought. He looked at it for a few minutes and said, “This is code.”

While this development spelled the end of Microsoft's attempts to connect to AOL, and we all celebrated our victory, ultimately it was shown to be Pyrrhic. As the author writes, "Despite my ignominious defeat at the hands of AOL’s diabolical mastermind of chat, Messenger did pretty well."

MSNM quickly grew to be the dominant IM client in most of the world. By the time I left AOL, MSNM was crushing AIM in terms of simultaneous users and messages delivered per day. There are many reasons for this, which could be an article all on its own, but perhaps the biggest was that we became obsessed with keeping MSNM out for good. Instead of focusing on growing the service, we tried to invent all sorts of crafty ways (binary verification protocols, steganography) of ensuring that only AOL-sanctioned clients could connect to us. It's clear now that these efforts could better have been spent on other things.

Regardless of how it ultimately turned out, still great to read this piece and briefly relive the AIM war room during that summer of 1999.
In the summer of 1998 I graduated from college and went to work as a programmer at Microsoft in Redmond, Washington. I was put on the group that was building MSN Messenger Service, Microsoft’s instant messaging app. The terrible name came from Marketing, which had become something of a joke for always picking the clunkiest and least imaginative product names. Buddy List? C U C Me? MSN Messenger? No, MSN Messenger Service. I’ll call it Messenger f...
8
3
James McLendon's profile photoMickaël Rémond's profile photoDave Levinson's profile photoJustin Uberti's profile photo
5 comments
 
I was justin0. +Justin Cohen, also a Googler now, was justin1.
Add a comment...

Justin Uberti

Shared publicly  - 
 
Great story on the history of AOL Instant Messenger, including interviews with a couple of the key folks who brought AIM to life. Defining quote from Eric Bosco, my old boss, on the tensions between the AIM (new) part of the company, and the AOL (old) part: "It was always AIM versus AOL. They hated us."

http://mashable.com/2014/04/15/aim-history/
In many ways, AOL Instant Messenger was right in line with the times, just at a company hanging on to a business model that would soon become obsolete.
12
4
bachr chi's profile photoMatt Dragon's profile photoMickaël Rémond's profile photoRandell Jesup's profile photo
 
i always wondered what aol employees opinion was of the subculture of users who were obsessed with collecting screen name trophies through bugs, vulnerabilities, social engineering, sheer luck, etc. Especially now that i read articles stating there were internal wars between departments like AOL&AIM.
Add a comment...
 
Stockholm at night.
9
pamylao souvannasone's profile photo
 
Beautiful
Add a comment...

Justin Uberti

Shared publicly  - 
 
Update on what's new in the latest versions of WebRTC.
 
An update from +Sam Dutton +Justin Uberti and +Serge Lachapelle from the Chrome WebRTC team. http://youtu.be/DvzDzIXoncg
22
1
Alexey Aylarov's profile photoRicardo De Lemos's profile photoRicardo Bastos's profile photoJustin Uberti's profile photo

Justin Uberti

Shared publicly  - 
 
Chrome and Chrome for Android are not affected by Heartbleed.
 
How does this affect webrtc? 
12
1
Patrik Purchart's profile photoLisa Larson-Kelley's profile photoShachar Zohar's profile photoJustin Uberti's profile photo
4 comments
 
Chrome-Firefox is OK too, since Firefox uses NSS instead of OpenSSL. Chrome either uses NSS or a version of SSL with heartbeats compiled out.
Add a comment...
Have him in circles
3,726 people
Niklas Enbom's profile photo

Justin Uberti

Shared publicly  - 
 
Most of what there is to say about Heartbleed has already been said. But perhaps the lesson is best learned when presented in the form of a parable:

“Chiuyin, the Governor’s treasurer, is blind as an earthworm. A thief may give him a coin of tin, claim that it is silver and receive change. When the treasury is empty, which man is the villain?"
4
Add a comment...

Justin Uberti

Shared publicly  - 
 
UberConference adds WebRTC-based screen sharing. Nicely integrated, and shows that the extension-based approach to screen sharing isn't a significant hurdle for WebRTC developers.
 
"Chrome offers the best viewing experience." You bet!

Free Screen Sharing for Conference Calls
11
4
Brian Peterson's profile photogeorge oloo's profile photo
Add a comment...
 
Fuzz testing is supposed to prevent bugs like Heartbleed. Why didn't it work here? Well, the problem is that encryption is a natural protection against fuzzing. Any damage to the packets will cause them to be discarded by the outer protocol layers, namely TLS' authentication checks.

In a world where everything is encrypted, the fuzzer really needs to work on the data before the encryption stage. Then it can get past the outer defenses and pound on the rest of the code that we really want to test.

This is not just an issue for TLS - it has relevance to WebRTC too, where any malformed packets will get tossed by the SRTP or DTLS layers. Again, we can avoid this issue if the fuzzer can do its mutation of the data on the send side before it goes to the encryption layer. But this means the fuzzer needs to be completely rethought - rather than something that simply changes bits on the wire, it needs to be part of the actual client.

Something to consider adding as an option in Chrome.

http://en.wikipedia.org/wiki/Fuzz_testing
4
2
Serge Lachapelle's profile photoMark Foltz's profile photogeorge oloo's profile photoJustin Uberti's profile photo
3 comments
 
Fuzzing on an unencrypted session would be useful in many cases. The advantages of the client-fuzzer I describe are a) that you could fuzz packets inside the encryption machinery (e.g. heartbeats) and b) you could fuzz other webrtc endpoints without needing to specially configure them to accept cleartext traffic.
Add a comment...

Justin Uberti

Shared publicly  - 
 
Sunny Stockholm.
19
pamylao souvannasone's profile photoGustav Hållberg's profile photosameer ansari's profile photo
3 comments
 
Nice… that you can't tell how bloody cold it's been :)
Add a comment...
 
Heartbleed's root cause: forgetting to sanity-check all size values in the protocol. Otherwise known as "Rule #1 of network programming".

See for yourself at https://github.com/openssl/openssl/commit/4817504d069b4c5082161b02a22116ad75f822b1#diff-38dc72994741420e2b6c5ee074941a45R1480
13
2
george oloo's profile photoMichael McDonnell's profile photoDave Cridland's profile photoJustin Uberti's profile photo
4 comments
 
The real bug is the failure of the stack to barf when the length is invalid.

The reason a standard fuzzer didn't catch this is because the heartbeat is encrypted. Any damage to the packet will be discarded by the TLS encryption layer.

This raises a pretty interesting point, namely that fuzzing must be done at multiple levels, i.e. both in the plaintext and encrypted domains.
Add a comment...
People
Have him in circles
3,726 people
Niklas Enbom's profile photo
Work
Occupation
Tech Lead, Google Real-time Communications
Employment
  • Google
    Tech Lead, 2006 - present
  • AOL
    Chief Architect, 1997 - 2006
  • IFusion Com
Basic Information
Gender
Male
Relationship
Married
Other names
juberti
Apps with Google+ Sign-in
Story
Tagline
Trained Professional
Bragging rights
Brief work history: Tech Lead for WebRTC, Google+ Hangouts, Gmail Call Phone, Google Video Chat, AOL Instant Messenger
Education
  • University of Virginia
    Mathematics, 1992 - 1995
They did a superb job fixing my iPad with a cracked screen. From unusable to good-as-new in a week. Price was very reasonable, and great customer service too - checked it over when I dropped it off, let me know what to expect, notified me when it was ready to pick up, super smooth transaction. I went to their Bellevue location, which is convenient but kind of tucked away in a nondescript office building.
Quality: ExcellentAppeal: Very goodService: Excellent
Public - a year ago
reviewed a year ago
1 review
Map
Map
Map