[tbb-bugs] #15910 [Tor Browser]: Figure out what to do with Open264H (downloads)

[Tor Bug Tracker & Wiki]

#15910: Figure out what to do with Open264H (downloads)
-----------------------------+----------------------
     Reporter:  gk           |      Owner:  tbb-team
         Type:  task         |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  ff38-esr
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------
Description changed by gk:

Old description:

> We should think about what we want to do with the OpenH264 video codec
> plugin which Firefox downloads since version 33 shortly after it got
> started for the first time (see:
> http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and
> https://wiki.mozilla.org/QA/WebRTC/OpenH264).
>
> The good news is, the code is free: https://github.com/cisco/openh264.
> The bad news is it needs to get downloaded from Cisco as a binary blob
> due to patent issues. And there is currently now known way to build this
> binary blob deterministically:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.
>
> I think we should make sure that the plugin does not get downloaded as:
>
> 1) It is currently only used for WebRTC which we have disabled
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make
> sure that this argument still holds for ESR 38 when we ship it if that
> matters)
>
> 2) The binary blob is not built reproducibly which poses security risks.
> Although there seems to be kind of a mechanism for Mozilla to verify
> things:
> {{{
> Mozilla and Cisco have established a process by which the binary is
> verified as having been built from the publicly available source, thereby
> enhancing the transparency and trustworthiness of the system.
> }}}
>
> 3) The download uses essentially Mozilla's "cert pinning". We might want
> to have something stronger in place.
>
> ...
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to
> disable the plugin download.

New description:

 We should think about what we want to do with the OpenH264 video codec
 plugin which Firefox downloads since version 33 shortly after it gets
 started for the first time (see: http://andreasgal.com/2014/10/14/openh264
 -now-in-firefox/ and https://wiki.mozilla.org/QA/WebRTC/OpenH264).

 The good news is, the code is free: https://github.com/cisco/openh264. The
 bad news is it needs to get downloaded from Cisco as a binary blob due to
 patent issues. And there is currently now known way to build this binary
 blob deterministically:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.

 I think we should make sure that the plugin does not get downloaded as:

 1) It is currently only used for WebRTC which we have disabled
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make
 sure that this argument still holds for ESR 38 when we ship it if that
 matters)

 2) The binary blob is not built reproducibly which poses security risks.
 Although there seems to be kind of a mechanism for Mozilla to verify
 things:
 {{{
 Mozilla and Cisco have established a process by which the binary is
 verified as having been built from the publicly available source, thereby
 enhancing the transparency and trustworthiness of the system.
 }}}

 3) The download uses essentially Mozilla's "cert pinning". We might want
 to have something stronger in place.

 ...

 See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to
 disable the plugin download.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15910#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online