Seth David Schoen: > Luis writes: > > > What are the reasons that makes building a Tor Browser using Chromium > > not such a good idea? I recall reading somewhere that while making a Tor > > Browser with a Chromium base would have its benefits due to Chromium's > > superior security model (i.e. sandboxing), there are "serious privacy > > issues" that would have to be solved to make that possible. > > My question is what are those issues? What is preventing someone from > > digging out all the Google integration and possible privacy-endangering > > features and making a Tor Browser Bundle out of it? > > https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs > > I think that list is kept relatively up-to-date. You might also like: https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study#chrome In particular, this paragraph is relevant to the recent Superfish MITM (see http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/): "The worst offender on this front is the use of the Microsoft Windows CryptoAPI for certificate validation, without any alternative. This bug means that certificate revocation checking and intermediate certificate retrieval happen outside of the browser's proxy settings, and is subject to alteration by the OEM and/or the enterprise administrator. Worse, beyond the Tor proxy issues, the use of this OS certificate validation API means that the OEM and enterprise also have a simple entry point for installing their own root certificates to enable transparent HTTPS man-in-the-middle, with full browser validation and no user consent or awareness." In fact, I tried to argue with Ryan Sleevi and Adam Langley about the dangers of using CryptoAPI in this way, but I got crickets in response. I believe that supporting such MITMs is a deliberate policy from Google corporate that they cannot change. Adam went so far as to tell me that I should just fork Chromium, because they would not even consider merging an alternate browser-only cert store, even as a user option. However, since our ultimate goal with any browser fork is to re-merge with upstream so we don't have to maintain invasive patches like this, a corporate-level blocker on basic security patches is a non-starter for any project involving Chrome. P.S. How I miss the days when the outlandish doomsday scenarios that I imagined were still merely hypothetical. It seems every week a new nightmare comes true. (Man, I sure hope I'm wrong about the likelihood of wide-scale software build system attacks. I kind of like having computers). -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk