3 ms·

Splitting Up Trust

• dane-pgp 5y ago
  > In a world of autoupdating (that is, the world of most modern browser users today), an overtly malicious browser vendor could push malicious code, potentially even stealthily to a subset of targeted users. We can dream about a world in which such a malicious update might be detectable, but that’s not the world we live in today, by a long shot. I appreciate the nod to Binary Transparency, but wish it were seen as more than a dream. There's no reason why browsers couldn't reuse their existing Certificate Transparency code to check that the hash of each version update they download has been included as the subdomain of an entry in multiple public logs. It seems like the resistance to doing that is due to policy/demand rather than technical concerns, so we shouldn't be going easy on browser makers by talking of "dreams". However, the simplistic way of implementing this feature would be to install the update if and only if the record existed in the log, which would mean that attacks would only be detected after the fact. (A targeted attack would actually be quicker to detect and raise the alarm about, since it wouldn't require any code auditing, just the absence of any released code corresponding to an entry in the log). Also, it would technically add a little to the attack surface, since blocking the log servers would be equivalent to blocking the update servers.