Hi Mike, First, apologies we took so long to reply to this. We are in the middle of a release push and I think this mail just kept crossing the "requires too much time to do right now" boundary, for me, anyway.
We've discussed your proposals below among the team, and at a high level I would say that doing a compelling Torbutton extension is doable in Chromium/Google Chrome, but adding the necessary APIs is a significant amount of work (I would estimate several man-months). But if you, or someone else from Tor was interested in working on it, we would welcome the changes because we think most of them would be good general additions. The high level way that I can imagine this working is: a) Overload the concept of Incognito mode to be "Tor mode". This would require changes to the extension system so that extensions could work in Incognito mode. Currently they do not, because there are tricky design questions around what it means for extensions to work in that mode (should they get fresh storage? If so, what about their settings?). But we think these questions are addressable. b) Implement the proposed proxy API. c) Implement the proposed network intercept API. d) Use content scripts to do things like blocking plugins and intercepting various JavaScript hooks. I would encourage you to start small with a Tor extension that does the simplest possible thing (maybe the proxy API?) and build out from there. More detailed responses to each of your points follow... On Thu, Oct 22, 2009 at 1:10 PM, Mike Perry <mikeperry.unu...@gmail.com> wrote: > 1. Profile Manager Access > > The most important API is the ability to launch Incognito-style (yet > distinctly tagged) browser windows via an extra menu item, perhaps by > requesting windows to be launched under specific existing or > programmatically altered profiles. There are also Firefox addons like > SwitchProfile that enable basic multiple identity support for users > that could leverage this level of access. Chrome does not currently have any concept of profiles. There is some code in there from an aborted attempt to add this feature, but it is slowly rotting, and it isn't clear if we will ever add the feature for real. Because of this, I would not suggest tying a Torbutton extension to profiles. Instead, I'd suggest using incognito mode. Currently extensions don't work in incognito mode, but we have some ideas on how they should work, and doing that could be part of bringing up Torbutton. Incognito mode is implemented using the half-working profile code, so it is likely that if profiles were ever introduced into Chrome, an extension that relied on incognito mode would transition relatively painlessly to becoming profile-aware. > 2. Per-Tab/Per-Profile Settings Access > > There already is a wishlist item for Settings Access, but I would like > to extend the wishlist item to include a copy-on-write method of > temporarily changing settings for individual tab processes or for > specific profile instances. If Torbutton were based on incognito mode, it seems that the need for temporary changes to settings goes away, right? > In particular, privacy enhancing extensions will typically want access > to the following settings: proxy settings Ok > a pref to prompt before autolaunch of external apps, What do you mean by external apps? Acrobat? > a pref to disable the opt-in usage tracking ... and a list > of ports that the browser is forbidden to post/connect to. With the extension system, we don't generally provide direct access to the browser's internal preferences store. Instead we poke each preference through as an API separately (see http://code.google.com/chrome/extensions/i18n.html as an example of this). So we'd have to take each of these on a case by case basis and see how important they are and whether there was a better way to do them. For example... > prefs to modify user agent and platform strings, In this case, I think the http intercept API is a better, more powerful way to do this. > 3. Per-Plugin Enable/Disable Controls > > Many plugins are not safe for privacy and security. In general, it > would be nice if extensions could enable or disable which plugins are > allowed for a given tab process or profile. This would enable not just > Torbutton but also security-oriented addons to do things like > temporarily disable plugins with known unpatched CVE advisories. I think this could be done using content scripts to start. In the future, I hope to implement more powerful ways to filter content. See: http://dev.chromium.org/developers/design-documents/extensions/gleam-api > 4. HTTP Request and Header Alteration > > The ability to alter HTTP headers would assist in User Agent spoofing, > Referrer alteration, Accept alteration, Cookie alteration, GET/POST > alteration and so on for many addons. With this and the item below, it > would be possible to do high-grade user agent spoofing without Chrome > providing any actual preferences or additional APIs to do so. > > It would also be possible to do things like remove the RLZ identifier > from Google GET requests during Tor+Incognito mode, which many privacy > conscious users view as a violation of trust by Google during normal > Incognito mode (despite it not being 100% unique). > > This could be part of the Navigator interception wishlist API. For > example, in Firefox, the "on-modify-request" HTTP event allows early > interception and alteration of HTTP requests. I'm really interested in getting started on trying to implement the HTTP intercept API. Before we start writing code, we need to measure the performance impact of synchronous requests to extension processes. The younger Perry has already done some rough measurements of this, but we had an idea to actually check in and deploy code that did a synchronous "ping" to an extension inside various points in the HTTP stack to measure it. We have infrastructure in the codebase that make it easy to build histograms of how long things like this really take in the wild. We would want to do this relatively early so that we could get good data before putting tons of work into the API. > 5. Javascript Hooking Support > > It would also be useful to be able to reimplement certain Javascript > functions and objects such as navigator.* (for thorough useragent > spoofing), window.Date, window.screen and window.history. > > The ability to inject unprivileged 'script' tags from extension > content scripts will provide the ability to create reimplementation > hooks, if this injection can happen before any other script on the > page is run. There does not need to be any communication between the > extension and unprivileged script. It's not clear to me from the API > docs if this type of injection is yet supported and if it will cause > the tag to be evaluated early enough in the page load and display > process. I think it is possible to go pretty far in this direction with content scripts. They support a "run_at": "document_start" feature (http://code.google.com/chrome/extensions/content_scripts.html#registration) that injects scripts before any other code runs. Since this kind of extension code and web JavaScript run in the same environment and have the same privileges, it is possible for you to get into an arms race with aggressive code that wants to work around your interception. I'm not sure if that matters to you or if it is surmountable. > 6. Fine-grained Cookie Control > > The ability to read, add and remove selected cookies would come in > handy for extensions like Cookie Culler, Add-n-edit cookies, and > Torbutton that protect, alter and delete specific cookies. This has been requested by several developers. I'm open to adding it. > 7. SSL Session ID Clearing > > SSL Session IDs are GUIDs used to reduce round trips on the SSL > handshake by providing an identifier to reference a recently > established SSL session. > > I checked the Incognito code, and it does clear the approved SSL > certificate cache, which is great. However, if a user connects to > https://secure.wikileaks.org without Incognito and then opens up an > Incognito window to do the same, the Session IDs remain the same > across both windows, and are a unique identifier that can be used to > generally track users. You can see this happen with Wireshark on > Windows Chrome 3.0.195.27. > > Exposing an API to completely reset the SSL state in a specific tab > processes or profile instance would be workable, however I could also > see this code just being added to the code that already rebuilds > Incognito's SSL cert caches in > OffTheRecordProfileImpl::GetSSLHostState(). It seems like maybe this is just a bug in Chrome? If so, perhaps a good place to start would be to fix it. > 8. Access to Flash Cookies/Limited Filesystem Access > > Assuming Tor would eventually be able to safely allow Flash or Gnash, > any site with a Flash applet can still read and write cookies, leaving > traces of the access to that site on the harddisk of the user and also > exposing the user to tracking and correlation between regular browsing > and Tor+Incognito browsing. > > The Firefox addon Better Privacy simply removes these cookies from the > macromedia directory for each of the major platforms, and this seems > to work well, even during a running session. On operating systems that > support native file locking, it may also be possible to ensure that > the flash cookie directory is only readable+writeable by non-Incognito > tab processes. Chrome extensions also support native code. Would it be possible to use the native code to just locate and delete these files? - a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensions@googlegroups.com To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
