Therefore, last month, I wrote up a review of the Web Request APIs, describing a method that could allow for blocking versions of three of the APIs to function with minimal performance impact, which is the key factor in Google's decision to provide them. This means that fully asynchronous notification and response is not a viable option for some events. However, security and privacy enhancing extensions will need the ability to actually block and modify requests with certainty. At the present time, all of the extension APIs are asynchronous, and delivery is optimized so that increasing the number of installed extensions listening for events has negligible to absolutely zero effect on page load time. Google Chrome is a very fine-tuned high performance browser, and keeping it this way is priority #1 for Google. The first major stumbling block is that not only do we need to convince Google that these APIs are useful and needed, but there also has to be a way for them to implement the APIs easily, cleanly, and with very little overhead. With his help, I've identified three major stumbling blocks to us and anyone else who is interested in writing security and privacy enhancing extensions on their platform. I'm also lucky enough to have my brother on the inside: he's one of the Google Chrome engineers who is working on these very APIs. I've been spending my time over the past couple months looking over these rough spots, documenting them, and informing Google. Our prolific Tor volunteer Robert Hogan has also been doing some work on SSL related issues that will prove crucial, as well.Įach of these API sets, however, has its own shortcomings, rough edges, and missing pieces that need to be taken care of before it becomes suitable for us to use. ![]() The three API sets that will make this possible are Web Request, Content Scripts, and the Proxy APIs. It should also soon be possible for many similar privacy and security enhancing extensions to follow suit. In fact, work is now in progress on all the major API sets that we need to build a Tor Mode for Google Chrome, to port HTTPS Everywhere, and also write a separate extension to provide defenses against fingerprinting and a network adversary, all using much simpler mechanisms that we had to use for the equivalent functionality in Firefox. Over the past year, a rather astonishing amount of progress has been made on the Google Chrome Extension API set and also on many items of that list. Many of the items on that first list were a bit far-reaching, and not all were strictly required to produce a Tor Mode for Google Chrome. We drew up a wish list of API categories that would be useful for privacy enhancing extensions. So, starting almost a year ago, we began providing feedback on Google Chrome's extension system APIs to ensure that Google is aware of the APIs that we and others need to write defenses against a network adversary. The added poison for Tor is that plugins and DNS leaks can also reveal your IP address and complete web activity to the network adversary. The Applied Crypto research group at Stanford recently published a comparison of the four major browser's private browsing modes against a dedicated local and remote adversary which details some of these issues. In general, Incognito's major shortcomings are plugins, fingerprinting, DNS leaks, SSL state leaks, auto-formfill and site-specific zoom. This means that Chrome Incognito mode is not safe to use with Tor. Google has taken the same approach as Firefox for their Incognito mode, which means that it provides little to no protections against a network adversary. As I mentioned there, we have also been doing the same thing with Google for Google Chrome. A few months back, I posted that we have been in discussion with Mozilla about improving their Private Browsing mode to resist fingerprinting and the network adversary.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |