If I'm understanding correctly, the plan is to piggy-back on top of the existing Certificate Transparency [0] infrastructure by issuing a regular X509 certificate per Firefox release, but for a special domain name that includes a Merkle tree hash for the files in that release, with a known suffix (".fx-trans.net").<p>In that manner they can piggy-back on top of the CT ecosystem (including existing logs, including existing search / monitoring tools, and presumably gossip if/when that's solved).<p>This seems like a really cool hack! The state of binary software distribution is really pretty scary when you think about it - techniques like this have the potential to restore a lot of confidence.<p>[0] <a href="http://www.certificate-transparency.org/" rel="nofollow">http://www.certificate-transparency.org/</a>
This is a fantastic step forwards for Binary Transparency, which I hope is followed by Linux distros and package managers, so all Free Software gets the benefit.<p>The one worry that comes to mind, though, is that once a binary transparency log check is made mandatory for any update to a piece of software, there is a risk that a bug in the log checking code makes it impossible to ever upgrade the software again. (This reminds me of the HPKP Suicide attack, but is not quite the same).<p>Obviously it should be possible, with Firefox at least, to manually download a new copy of the installer and install it from scratch, but I feel there should be a fall-back mechanism where, say, a release signed with a special offline key should be allowed to skip the transparency check (perhaps only if the transparency check has been failing on an offered upgrade for more than a month).
I wonder how much effort it would take them to actually get to fully reproducible builds.<p>edit:<p>here, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=885777" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=885777</a>
Binary transparency seems to be a nice thing to have though quite limited in scope for linux as distro usually compile from source. Even more limited as mozilla knowingly makes controversial choice stating unhappy users and distro can recompile with a build flag until we strip the code.<p>IMHO mozilla should orient its transparency effort towards its decision process first so we don't end with a binary transparent browser no one use because management decided to remove user choice and break the UI (to look more like chrome), break extensions that contributed to firefox success (to be more like chrome), require pulseaudio and drop alsa and so on.
Really interesting hack. It basically gives (almost) free timestamping (using Let's encrypt for cert issuance and CT logs for storing information). Previously one would use Bitcoin OP_RETURN outputs for timestamping [0].<p>[0]: <a href="https://en.bitcoin.it/wiki/OP_RETURN" rel="nofollow">https://en.bitcoin.it/wiki/OP_RETURN</a>
The stated goal is to enable someone to verify "that they have gotten the same version as the rest of the world and not a special, possibly compromised version." This is actually two goals: (1) verify that your version is the same as everyone else's, and (2) verify that that version is genuine.<p>Why should one care about (1)? All that really matters is (2). As long as I'm using a genuine release, does it matter what the rest of the world is using? Unless I wish to establish trust in a binary based on how popular it is, or unless I care about interoperability between the version I have and the version others have, it doesn't really matter what version everyone else has.<p>I wonder if the author has heard about Nix or Guix? The purely functional software deployment model pioneered by Nix solves (2) trivially, for practically all applications in general, not just Firefox specifically. It also solves many other problems in the field of software deployment that this article doesn't even mention.<p>Long story short, don't reinvent the wheel. Use Nix or Guix. Learn more by reading the first chapter of Eelco Dolstra's thesis, which describes the problems and how the Nix model solves them:<p><a href="https://nixos.org/~eelco/pubs/phd-thesis.pdf" rel="nofollow">https://nixos.org/~eelco/pubs/phd-thesis.pdf</a><p>Edit: Even if one is concerned about (1), the Nix model enables ways to verify that the origin is actually sending a binary that was built from the source it claims to use. For example, consider "guix challenge":<p><a href="https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html" rel="nofollow">https://www.gnu.org/software/guix/manual/html_node/Invoking-...</a>