If we restrict installation of per-machine extensions by the admin/root user of the system, it should not cause security issues.
On Wed, Dec 17, 2008 at 9:21 AM, NingiaChrome <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
