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

Richard Barnes <> Thu, 31 October 2013 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E8211E8244 for <>; Thu, 31 Oct 2013 15:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.889
X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t94-a6V0H+0N for <>; Thu, 31 Oct 2013 15:36:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 859DA11E8182 for <>; Thu, 31 Oct 2013 15:36:45 -0700 (PDT)
Received: by with SMTP id j6so3768884oag.23 for <>; Thu, 31 Oct 2013 15:36:45 -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:date :message-id:subject:from:to:cc:content-type; bh=KvLjw2KtP5kSTwP34RkeDGNDnXC+A65r1tsb91pGViM=; b=lCfeDe+gVT7XDgoZApR3goDXYgI+exq4n6alN+LjxxKCsX4x4XUsOBrdzHmZ/zB6Cg uK+GcTdR15mgjnrhmmI2mgOWwcGNVfsgfWeQYAa5I0um6fqOD3mOZeOjzpdJsQke67+m w7akXk+hbz584qXSs5CnYMxIYBlqI6Lj7SyR5RTFADcFN8fgkVfn0Y1tk8QRPLvEA+e+ TWz7fjZW83SdUgJqO7FZ3R3uKstvLKxalHDNo3V4uRo78imvpgqEiaeSspQofFMRlvqH SuM+ETg8B9pg4yjMW3ei9hvztCRBU4sSJbOkM1u9bK5gHaGh/kpwbxeWLNw0mv12Q7LE 9djA==
X-Gm-Message-State: ALoCoQkwlp15rDN+b5VoOTfLvz2sAtQPiRJsgMmZXExpXoLh47pUovgznPLLWr6jzbsBN2PaJem8
MIME-Version: 1.0
X-Received: by with SMTP id x9mr30114oel.88.1383259004853; Thu, 31 Oct 2013 15:36:44 -0700 (PDT)
Received: by with HTTP; Thu, 31 Oct 2013 15:36:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 31 Oct 2013 18:36:44 -0400
Message-ID: <>
From: Richard Barnes <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a11330a009dfae004ea1115e7
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 22:36:50 -0000

On Thu, Oct 31, 2013 at 5:27 PM, Eric Rescorla <> wrote:

> 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 we
> intend to handle things in Firefox.

You would need something more than that if you don't trust Cisco not to
tinker with the binaries (no offense).  But even that doesn't have to be
complicated.  You could just do something like have the software call back
to the vendor whenever it gets a new binary from Cisco to check that the
binary it just got is good (say, by comparing hashes).

That way at least Cisco and the vendor would have to collude to introduce a
bad modification to the binary.  Which is not so bad, because the user is
already trusting the vendor not to screw them in all sorts of other ways.


> Note that any product that auto-updates (like Firefox and Chrome) already
> need
> to have some mechanism for verifying that the things they download are
> correct.
>> 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.
> Presumably,
> one could invent some countersignature mechanism to allow clients to
> verify that a specific third party had verified a build.
> -Ekr
> _______________________________________________
> rtcweb mailing list