On Nov 2, 3:03 pm, Aaron Boodman <a...@chromium.org> wrote: > > 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?
It depends. We would want different proxy settings, autolaunch settings, and usage tracking settings than Chrome, and even normal Incognito windows. Hence I suggested copy-on-write behavior for the preference systems (or perhaps a "apply to this tab only" bool for the APIs that accomplishes the same). > > a pref to prompt before autolaunch of external apps, > > What do you mean by external apps? Acrobat? I'm not sure about Chrome, but Firefox currently will launch external apps to handle certain mime types. This is the source of proxy-bypass attacks that leverage things like iTunes and MSWord to make network connections outside of the proxy. See: http://decloak.net and http://deanonymizer.com/. We believe its acceptable compromise to simply prompt the user before launching these apps for Tor, but the user doesn't always want the prompting in their normal non-Tor experience. > > 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 Ah nice. Yes, this could work. I think content scripts are insufficient for this because we are very concerned about the ability to dynamically add plugin-handled tags, but if Gleam would allow us approval over this process, that would work. > > 4. HTTP Request and Header Alteration > > 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. Yeah. I discussed the performance concerns with him briefly. A light- weight way to do this without full RPC overhead would be to have the API allow you to register a set of regular expressions that would apply to raw HTTP headers or requests, perhaps as a decision list or decision tree. The downside of simply registering regexes is that it would make extensions that allow the user to fully intercept and edit HTTP requests on the fly (like the Firefox "Tamper Data" extension does) not possible. But the user could always just fill in their own regexes and patterns into an extension's UI and get almost the same ability. > > 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. > > 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#registr...) > 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. Yeah, we had a lot of issues in the Firefox implementation of this because you could delete the hooked objects to reveal the originals for some of the Javascript, access them via __proto__ and prototype, or query Firefox via the XPCNativeWrapper call to get the originals. I did some basic testing and it seems the delete trick at least does not work on Chrome. > > 8. Access to Flash Cookies/Limited Filesystem Access > > Chrome extensions also support native code. Would it be possible to > use the native code to just locate and delete these files? Hrmm, interesting. What form does this take? I worry about supporting native code on a bunch of platforms, but if it was as simple as just building a .so or .dll, that might not be too bad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
