I think per-machine extensions are very dangerous, think of a user than open chrome with his profile just to discover a new installed extension ( installed by someone else ). How does he get rid of that unwanted extension?
In my opinion Incognito mode should not be able to run any extensions but if that feature is important for someone maybe we should use the extensions related to the profile who launched Incognito mode. And as someone else appointed extensions data must be different between profiles even if the extension code is machine-wide. Excuse my bad english. On 17 Dic, 15:10, Amanda Walker <ama...@chromium.org> wrote: > I'm not a heavy extensions user, but I can think of basic use cases for both > per-browser and per-profile installation, mostly having to do with whether > or not the extension has state. It seems to me that stateful extensions at > the very least need per-profile state, even if the extension itself is > installed per-user or per-machine. > --Amanda > > On Tue, Dec 16, 2008 at 8:34 PM, Aaron Boodman <a...@chromium.org> wrote: > > > I've been struggling with how extensions and profiles should relate. > > My initial thinking was that we should support installing extensions > > per-profile and per-machine (the latter for distribution deals > > mostly). Currently, our extension manager (ExtensionsService) object > > is owned by the profile and looks for extensions inside the profile > > directory. As for incognito mode, my assumption was that it was more > > correct to have extensions keep working in incognito mode than to have > > them stop working (there are tradeoffs both ways though). > > > My immediate issue is that I'm trying to implement support for the > > extension:// protocol, which looks like this: > > extension://<extensionid>/path/inside/extension. In order to implement > > this, I need to be able to track a request back to the profile it came > > from. But at the point my custom protocol handler gets invoked, > > profile information is long since toast. > > > Stepping back, I could make some simplifying assumptions: > > > * We could start by implementing per-chrome-install extensions only. > > In that case a static protocol handler is fine. I'd also have to > > change the extension service to be a singleton and instead look for > > extension inside the app directory, similar to how npapi plugins work. > > > * I could keep extensions installed per-profile for now, but assume > > that there is really only one profile per-browser process. In this > > world, I'd still make ExtensionsService be a singleton, but I'd > > initialize at browser startup with the path to the profile that was > > picked at startup. > > > Any thoughts, either on advantages or disadvantages to installing > > extensions per-chrome install, or to assuming that there is only one > > profile per browser process? > > > Thanks, > > > - a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
