On Nov 3, 7:47 pm, Aaron Boodman <a...@chromium.org> wrote: > 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 > > 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.
Yes, this could work well, so long as we were also able to somehow signify the change has applied to all open Incognito windows (perhaps by altering their UI to add a Tor graphic). > >> > 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.netand > >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? So long as enumeration is also possible so it is easy to write a handler that can apply to everything, yes, this would be great. > >> > 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. Yeah. The content and the network are both very adversarial. https://www.torproject.org/torbutton/design/#adversary The one thing it looks like we would need added to the Gleam API is a trustworthy indicator as to which plugin is actually going to handle which tag. We are really interested in doing something like shipping a version of Gnash with our browser bundles for example, but almost every closed source plugin needs to be disabled because their behaviours wrt privacy and proxies are so unpredictable. > >> > 4. HTTP Request and Header Alteration > > 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. Agreed. Just pointing out the option if the performance impact ends up being prohibitive. > >> > 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. Yeah, but we can afford to play a little fast-and-loose with these initially, as they are mostly just reduce anonymity set if undone (as opposed to plugins, which lead to total anonymity compromise). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
