On Tue, Nov 3, 2009 at 11:31 AM, Mike Perry <mikeperry.unu...@gmail.com> wrote: > > 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).
Right, my idea was that incognito mode and normal Chrome mode might be changed so that they can have different values for some (or all?) preferences. In that case, Torbutton could change the value for incognito mode only. >> > 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. I see. There have also been proposals for APIs that allow extensions to intercept requests by mimetype (for example to implement a custom PDF handler). It seems like this would be useful for a wider variety of extensions than a simple pref to allow/disallow. Would that work for you? >> > 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. It really depends how adversarial you think content is to privacy. If your model is that content is very adversarial, then I admit that content scripts may not be powerful enough. >> > 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. I'm open to declarative components to the API if necessary. In general, I like us to go programmatic where we can because it is more flexible. >> > 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. Ok, yea, those are the types of issues I was alluding to. >> > 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. NPAPI: http://code.google.com/chrome/extensions/npapi.html Your brother is the expert on this feature. - 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 -~----------~----~----~----~------~----~------~--~---
