Re: [rtcweb] On the topic of MTI video codecs

Eric Rescorla <> Thu, 31 October 2013 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D088A21F9F2D for <>; Thu, 31 Oct 2013 14:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.737
X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vIuOhN-8Mffb for <>; Thu, 31 Oct 2013 14:28:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C00721F9F23 for <>; Thu, 31 Oct 2013 14:28:28 -0700 (PDT)
Received: by with SMTP id u57so3242499wes.18 for <>; Thu, 31 Oct 2013 14:28:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gyXVRwK42aqmvZskkafd5QMIoLdylXwdk7FxgO8ufzo=; b=eVIoZWS8x0Af7g5K9nlnv0g6SbcJgmokmkGlrZ9ZXTDctdXqDFAF5BjiYQyakM4IXj nYO2I1V7VS4Lw5xLUHm/KOD0zj4ks7ITc6/SWSF9OyzOMKyCKJi0kDgD4lXbJQIkIF4g 8il2+TnTPRQ2Adkusyb581B38qJOSnFvWXLlgBALyNcCN6Zpuqy+XQNB6WcjDUnLeDzq TSWNgXwkPEvIVzZDaPsXe9SQSncvauaTQczsyfpkwpldeMjDv4keWGL6xJnBESA+IG9M ecRXOCbw1Qa1JyaMX/QBMHLWpM7MuigIOJI+m+8qLs596s7NlO8kI7jGz/h/RStHVCSx nHxw==
X-Gm-Message-State: ALoCoQkKffwGi9GTLcKeneM3CeR/6aIS5RBBeGK/+OzQ7/Cak4QerPxnnP5vxy+J4y+uqZzlXSKk
X-Received: by with SMTP id u9mr50618wif.5.1383254907474; Thu, 31 Oct 2013 14:28:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 31 Oct 2013 14:27:47 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 31 Oct 2013 14:27:47 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary=f46d04447f6764f69204ea1021ab
Cc: "" <>, Neil Stratford <>
Subject: Re: [rtcweb] On the topic of MTI video codecs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 21:28:39 -0000

On Thu, Oct 31, 2013 at 2:08 PM, Daniel-Constantin Mierla <
> wrote:

> On 10/31/13 4:10 PM, Olle E. Johansson wrote:
>> On 31 Oct 2013, at 10:02, Neil Stratford <> wrote:
>>  On 30 Oct 2013, at 17:55, Adam Roach <> wrote:
>>>  As Jonathan mentioned earlier, this morning Cisco announced that it
>>>> will be open sourcing an H.264 implementation as well as gratis binary
>>>> modules compiled from that source and hosted by Cisco for download. Mozilla
>>>> will be modifying Firefox to support H.264 by downloading Cisco's binary
>>>> module.
>>> It seems like most of the groundwork is being done here for a real codec
>>> plugin API which would obviate the need for any particular codec to be
>>> selected as MTI.
>>> Can we encourage this new codec plugin API to be developed in an open
>>> way as part of the standards process and therefore be supported in all
>>> browsers? (Enabling for example the addition of VP8 to a browser that may
>>> not natively ship with it.)
>> I don't agree. The idea was to create a realtime web platform without the
>> need for any plugins or downloadable modules. We've had that for ages and
>> it is not a good solution.
>> I am still for a MTI codec or set of codecs so we always can set up video
>> calls, regardless of implementation and if it's possible to download by
>> policy or network conditions a specific binary.
> Downloading a binary opens doors for tons of risks, knowing that lot of
> carriers do caching or interpose themselves (e.g., it happens very commonly
> for dns to redirect you to some adds page when typing an invalid domain),
> thus is easy to replace the original source, so a rather complex security
> mechanism has to be put in place.

Solely on the security question...

I'm not sure what you mean by "rather complex". What I would expect is to
have signed
binaries. This addresses the question of attack from the network and is how
intend to handle things in Firefox.

Note that any product that auto-updates (like Firefox and Chrome) already
to have some mechanism for verifying that the things they download are

> Even the argument that the code can be compiled and signatures compared is
> not really feasible - simply it cannot be done by mobile devices - they
> don't have the sdk installed.

I don't see why this would be needed. The containing program (e.g., the
browser) doesn't compile, it just does signature verification.

Obviously, this only addresses the question of attack from the network,
not malicious binaries constructed by Cisco. I expect that to be addressed
by third parties doing verified builds and comparing the binaries.
one could invent some countersignature mechanism to allow clients to
verify that a specific third party had verified a build.