This is chromium bug[1] deserves more stars from the privacy community that wants to choose to use Chrome/ Chrome OS via tor. It's a different privacy/security trade off depending on your threat model.
Chrome is getting much more friendly towards multiple simultaneous profiles which makes it usable to have a privacy hardened profile. I suspect the first place we see a build system attack is in court documents or a Lavabit type scenario. [1] https://code.google.com/p/chromium/issues/detail?id=447978 On Thu, Feb 19, 2015 at 2:34 PM, Mike Perry <[email protected]> wrote: > 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 > > -- > tor-talk mailing list - [email protected] > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
