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?
On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman <a...@chromium.org> wrote: > 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?
From a user perspective, I would very much want per-profile extensions. I have no opinion on whether per-machine extensions would be widely useful (I suggest punting that until someone cares) but I would certainly not want that to be the only, or the default, choice.
We need to at least support per-profile enabling/disabling of
extensions. The extension package may live outside the profile
directory, but if another profile has Random Extension X enabled, I
shouldn't be forced to use it as well.
As for the technical details of request interception, every request
has an URLRequestContext, which has a 1-1 mapping to a Profile object.
Perhaps you can use that to either store the info you need or get
access to the right Profile. The thing you need to be careful about
is that Profiles can only be accessed on the UI thread. I had to deal
with a similar problem when working out request interception for
Gears, so maybe I can help you with details.
On Tue, Dec 16, 2008 at 5: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?
On Tue, Dec 16, 2008 at 5:50 PM, Mike Belshe <mbel...@google.com> wrote: > My thought is that extensions should not apply in the incognito mode.
I don't know. From my perspective as a user, "incognito" is more like a flag I temporarily set on my current window/profile, rather than a different profile. (Which is also fairly true implementation-wise.) In that sense I wouldn't expect extensions to be disabled unless they wrote state to disk or something.
per-machine extensions are very important. that turns out to greatly
simplify the task of distributing an extension via a third-party installer.
-darin
On Tue, Dec 16, 2008 at 5:40 PM, Peter Kasting <pkast...@chromium.org>wrote:
> On Tue, Dec 16, 2008 at 5:34 PM, Aaron Boodman <a...@chromium.org> wrote:
>> 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?
> From a user perspective, I would very much want per-profile extensions. I
> have no opinion on whether per-machine extensions would be widely useful (I
> suggest punting that until someone cares) but I would certainly not want
> that to be the only, or the default, choice.
> We need to at least support per-profile enabling/disabling of > extensions. The extension package may live outside the profile > directory, but if another profile has Random Extension X enabled, I > shouldn't be forced to use it as well.
> As for the technical details of request interception, every request > has an URLRequestContext, which has a 1-1 mapping to a Profile object. > Perhaps you can use that to either store the info you need or get > access to the right Profile. The thing you need to be careful about > is that Profiles can only be accessed on the UI thread. I had to deal > with a similar problem when working out request interception for > Gears, so maybe I can help you with details.
Ditto. This is something you get for free in Chrome. URL requests from a RenderView are contextual. The only time we have trouble mapping an URL request to a Profile is when it is a global service issuing the URL request. This comes up for things like the metrics service.
The trickiness definitely lies with the fact that the Profile can only be used on the main thread. We have a variety of solutions in use to expose services to the IO thread and other background threads. We might want to think about unifying those under some kind of ThreadSafeProfileData class or perhaps a separate class associated with the Profile that only gets accessed on the IO thread.
> We need to at least support per-profile enabling/disabling of
> extensions. The extension package may live outside the profile
> directory, but if another profile has Random Extension X enabled, I
> shouldn't be forced to use it as well.
Enabling / disabling of extensions per profile seems like the right thing to
do, but at least to me, installation outside the profile directory would be
more natural. We already have an install path that is per user so most of
the time the person using a profile X is the same one that installed the
browser and any additional extensions, and it would be natural to have them
available on all profiles.
> As for the technical details of request interception, every request
> has an URLRequestContext, which has a 1-1 mapping to a Profile object.
> Perhaps you can use that to either store the info you need or get
> access to the right Profile. The thing you need to be careful about
> is that Profiles can only be accessed on the UI thread. I had to deal
> with a similar problem when working out request interception for
> Gears, so maybe I can help you with details.
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?
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?
On Wed, Dec 17, 2008 at 9:21 AM, NingiaChrome <oppifjel...@gmail.com> 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 <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?
On Wed, Dec 17, 2008 at 6:10 AM, 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?
Chrome should give users the ability to disable extensions regardless of how
they are installed. Installation of an extension should just be about
making Chrome aware of extensions. I'm envisioning something that works
just like Firefox's system. When Firefox discovers a new extension
(installed globally on the system), it prompts the user to decide if they
wish to have it enabled. That seems like a decent solution. (We might want
to explore non-modal ways of prompting.)
-Darin
On Wed, Dec 17, 2008 at 7:21 AM, NingiaChrome <oppifjel...@gmail.com> 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 <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?
Firefox does not have such a restriction. I don't think we should go
overboard here. If a user can install Chrome, then they should also be able
to install other software that installs Chrome extensions. If we try to
prevent that from happening, then we will fail. People will instead write
nasty code to figure out where the Chrome profile is and then they will
modify the files in there to cause the profile to somehow know about their
extension. This is what people did for Firefox before Firefox supported an
official way to install extensions globally (or per user) on the system.
Best not to try to repeat those mistakes. The last thing you want is
people mucking around in the profile directory. One of Chrome's top crashes
was for a while related to people modifying theme.dll !!
-Darin
On Wed, Dec 17, 2008 at 9:09 AM, Josh Roesslein <jroessl...@gmail.com>wrote:
> 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 <oppifjel...@gmail.com>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 <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?
On Wed, Dec 17, 2008 at 10:44 AM, Darin Fisher <da...@chromium.org> wrote: > Absolutely... extensions should be able to store data in the profile. I > think that issue is orthogonal to where the extensions get installed.
Is it orthogonal to where Chrome itself is installed? i.e. if we have two distinct per-user Chrome installs, would a "per-machine" extension be visible to both, or just one (so it's really "per-Chrome-install")?
My concern in broad terms is for multi-user systems; if my wife installs an extension I don't really want to get prompted to install it myself (or have it turn on automatically). I'm OK with Chrome using the same instance under the hood if we both decide to use the same extension; that's invisible to me as a user.
Of course, one could also argue that this kind of prompting is useful, especially in the typical case. I feel a bit torn. My mental conception of both OS- and browser-level profiles is something of "never the twain shall meet", but I recognize that that's not true for everyone.
Keep in mind that some users will use a "high-security" profile for
online banking and a "low-security" profile for reading blogs. I
might decide that I like a certain extension enough to install it in
my low-security profile, but that doesn't mean I like it enough to
install it in my high-security profile.
On Wed, Dec 17, 2008 at 10:51 AM, Peter Kasting <pkast...@google.com> wrote:
> On Wed, Dec 17, 2008 at 10:44 AM, Darin Fisher <da...@chromium.org> wrote:
>> Absolutely... extensions should be able to store data in the profile. I
>> think that issue is orthogonal to where the extensions get installed.
> Is it orthogonal to where Chrome itself is installed? i.e. if we have two
> distinct per-user Chrome installs, would a "per-machine" extension be
> visible to both, or just one (so it's really "per-Chrome-install")?
> My concern in broad terms is for multi-user systems; if my wife installs an
> extension I don't really want to get prompted to install it myself (or have
> it turn on automatically). I'm OK with Chrome using the same instance under
> the hood if we both decide to use the same extension; that's invisible to me
> as a user.
> Of course, one could also argue that this kind of prompting is useful,
> especially in the typical case. I feel a bit torn. My mental conception of
> both OS- and browser-level profiles is something of "never the twain shall
> meet", but I recognize that that's not true for everyone.
> PK
On Wed, Dec 17, 2008 at 10:51 AM, Peter Kasting <pkast...@google.com> wrote: > On Wed, Dec 17, 2008 at 10:44 AM, Darin Fisher <da...@chromium.org> wrote:
>> Absolutely... extensions should be able to store data in the profile. I >> think that issue is orthogonal to where the extensions get installed.
> Is it orthogonal to where Chrome itself is installed? i.e. if we have two > distinct per-user Chrome installs, would a "per-machine" extension be > visible to both, or just one (so it's really "per-Chrome-install")?
> My concern in broad terms is for multi-user systems; if my wife installs an > extension I don't really want to get prompted to install it myself (or have > it turn on automatically). I'm OK with Chrome using the same instance under > the hood if we both decide to use the same extension; that's invisible to me > as a user.
> Of course, one could also argue that this kind of prompting is useful, > especially in the typical case. I feel a bit torn. My mental conception of > both OS- and browser-level profiles is something of "never the twain shall > meet", but I recognize that that's not true for everyone.
> PK
This touches on some of the murky issues with browser profiles...
From this thread and talking to people in person, I came to the conclusions that:
a) profile-level and machine-level extension installations are both important use cases b) there are relatively easy ways to work around the technical problem I was having implementing profile-level extension installations
I have a implementation working and I'll be sending it out for comment soon.
On Wed, Dec 17, 2008 at 12:34 PM, Aaron Boodman <a...@chromium.org> wrote:
> Thanks everyone for your feedback and examples.
> From this thread and talking to people in person, I came to the > conclusions that:
> a) profile-level and machine-level extension installations are both > important use cases > b) there are relatively easy ways to work around the technical problem > I was having implementing profile-level extension installations
> I have a implementation working and I'll be sending it out for comment > soon.
Hmm. This isn't the conclusion I came to. First off, I think there was a bit of confusion in terminology. People were throwing around per-user vs. per-machine, and that's not what Aaron was talking about here. The main issue right now is that Chrome still has a notion of multiple profiles. Even though most users don't use multiple user profile directories, many use incognito, which is a separate user profile. Since chrome is currently installed per-user, this makes things a bit murky when you say per-installation. In reality, I think all we're currently talking about is per-user vs. per-profile. When we have machine-wide installs again, we can talk about per-machine extensions.
The second thing I saw people blurring was installation vs. configuration. Just because you install the extension doesn't mean it has to be enabled across all profiles or that it should have the same configuration data. In fact, I would argue that by default, they wouldn't be enabled across profiles and wouldn't share configuration data.
Some of this discussion is also messed up because multiple profiles isn't really a first class citizen in our UI, so it's unclear how much time we should spend worrying about the use case.
Here's my take about how things should work - installation of extensions should be per-user (with the possibility of per-machine when we have it) - configuration (including whether or not it's enabled) should be per-profile - incognito should be a special case - users can manually disable extensions for incognito, but we also pass a special flag into extensions when running in incognito mode so that if they do run, they can behave appropriately (ideally this is how we'd like to see plugins work as well)
> On Tue, Dec 16, 2008 at 5:50 PM, Mike Belshe <mbel...@google.com> wrote:
>> My thought is that extensions should not apply in the incognito mode.
> I don't know. From my perspective as a user, "incognito" is more like a
> flag I temporarily set on my current window/profile, rather than a different
> profile. (Which is also fairly true implementation-wise.) In that sense I
> wouldn't expect extensions to be disabled unless they wrote state to disk or
> something.
Doing per-user extension installation w/ per-profile disabledness override and configuration is an interesting idea. Seems simpler in some ways, and perhaps better than purely per-profile.
Since I already have this change almost lined up that implements per-profile, I'll send it out anyway so we can have something to poke at. It might even be good to just check this in as a checkpoint and then back it out to per-user.
More thoughts inline...
On Wed, Dec 17, 2008 at 2:18 PM, Erik Kay <erik...@chromium.org> wrote: > Hmm. This isn't the conclusion I came to. First off, I think there was a > bit of confusion in terminology. People were throwing around per-user vs. > per-machine, and that's not what Aaron was talking about here. The main > issue right now is that Chrome still has a notion of multiple profiles. > Even though most users don't use multiple user profile directories, many > use incognito, which is a separate user profile. Since chrome is currently > installed per-user, this makes things a bit murky when you say > per-installation. In reality, I think all we're currently talking about is > per-user vs. per-profile. When we have machine-wide installs again, we can > talk about per-machine extensions.
Conceivably, extensions could be installed at all these levels:
- per-profile (inside the user data dir) - per-installation (next to chrome.exe) - per-user (in some known subdir of ~) - per-machine (in some known subdir of /)
We don't need or want all of this though. We should pick a few levels that make sense. Currently the feedback I've heard voiced is: - We need an easy way for third-party software to install extensions per-machine or perhaps per-user - Sometimes it makes sense to install (or enable) an extension per-profile, sometimes not - Sometimes it makes sense to enable extensions in incognito mode, sometimes not
> The second thing I saw people blurring was installation vs. configuration. > Just because you install the extension doesn't mean it has to be enabled > across all profiles or that it should have the same configuration data. In > fact, I would argue that by default, they wouldn't be enabled across > profiles and wouldn't share configuration data.
Separating enabled/disabled-ness from installation is a really interesting idea. Usually extensions are installed per-profile in Firefox, but they can also be installed per-machine, though that is much less frequently used. In the case of per-machine extensions, you can override installation with a disabled flag. I can't recall if there is actually UI for this.
What UI do you envision for disabling extensions per-profile? I guess this could go in a future management UI? What about for incognito mode? Perhaps in the management screen, we could have a checkmark for whether an extension is enabled in incognito mode?
> Some of this discussion is also messed up because multiple profiles isn't > really a first class citizen in our UI, so it's unclear how much time we > should spend worrying about the use case.
I agree this isn't a big deal. But if it's something that comes relatively cheaply (it turns out to), then it seems better not to break existing assumptions in Chromium and to go with the flow.
> Here's my take about how things should work > - installation of extensions should be per-user (with the possibility of > per-machine when we have it) > - configuration (including whether or not it's enabled) should be > per-profile > - incognito should be a special case - users can manually disable extensions > for incognito, but we also pass a special flag into extensions when running > in incognito mode so that if they do run, they can behave appropriately > (ideally this is how we'd like to see plugins work as well)
This makes sense to me. Let me send out the review and we can continue from there.
On Wed, Dec 17, 2008 at 5:43 PM, Aaron Boodman <a...@chromium.org> wrote: > Doing per-user extension installation w/ per-profile disabledness > override and configuration is an interesting idea. Seems simpler in > some ways, and perhaps better than purely per-profile.
I like it--that would cover all of the "wanting different extensions active for different profiles" examples I can think of.
> What UI do you envision for disabling extensions per-profile? I guess > this could go in a future management UI? What about for incognito > mode? Perhaps in the management screen, we could have a checkmark for > whether an extension is enabled in incognito mode?
That would work. This is more or less how add-ons work in games (such as World of Warcraft): whether something is installed is separate from whether or not it's enabled. This also opens up the possibility of some "compatibility level" checking, where extensions that were known to break with an update could be disabled as part of the update. But that's getting fancy. Just a set of checkboxes in the list of installed extensions would be a place to start.
On Wed, Dec 17, 2008 at 14:18, Erik Kay <erik...@chromium.org> wrote:
> On Wed, Dec 17, 2008 at 12:34 PM, Aaron Boodman <a...@chromium.org> wrote:
>> Thanks everyone for your feedback and examples.
>> From this thread and talking to people in person, I came to the
>> conclusions that:
>> a) profile-level and machine-level extension installations are both
>> important use cases
>> b) there are relatively easy ways to work around the technical problem
>> I was having implementing profile-level extension installations
>> I have a implementation working and I'll be sending it out for comment
>> soon.
> Hmm. This isn't the conclusion I came to. First off, I think there was a
> bit of confusion in terminology. People were throwing around per-user vs.
> per-machine, and that's not what Aaron was talking about here. The main
> issue right now is that Chrome still has a notion of multiple profiles.
> Even though most users don't use multiple user profile directories, many
> use incognito, which is a separate user profile. Since chrome is currently
> installed per-user, this makes things a bit murky when you say
> per-installation. In reality, I think all we're currently talking about is
> per-user vs. per-profile. When we have machine-wide installs again, we can
> talk about per-machine extensions.
We do per-machine installs today when we are distributed with third-party
installers that install per-machine. (This is new as of the 1.0 release last
Thursday.)
User profile data is still under %USERPROFILE%, but the app and binaries are
under %PROGRAMFILES% instead of %LOCALAPPDATA%.
We might need to make sure to distinguish an extension's code (potentially
system-wide) from data/configuration/enabled state (always user-specific).
> The second thing I saw people blurring was installation vs. configuration.
> Just because you install the extension doesn't mean it has to be enabled
> across all profiles or that it should have the same configuration data. In
> fact, I would argue that by default, they wouldn't be enabled across
> profiles and wouldn't share configuration data.
> Some of this discussion is also messed up because multiple profiles isn't
> really a first class citizen in our UI, so it's unclear how much time we
> should spend worrying about the use case.
> Here's my take about how things should work
> - installation of extensions should be per-user (with the possibility of
> per-machine when we have it)
> - configuration (including whether or not it's enabled) should be
> per-profile
> - incognito should be a special case - users can manually disable
> extensions for incognito, but we also pass a special flag into extensions
> when running in incognito mode so that if they do run, they can behave
> appropriately (ideally this is how we'd like to see plugins work as well)
On Dec 16, 8:50 pm, Mike Belshe <mbel...@google.com> wrote:
> My thought is that extensions should not apply in the incognito mode.
That would be terrible. Imagine a usability extension (zoom part of
the view, support for alternate input method, etc)
and it would go away when you're incognito. Sorry to disagree but if I
say they absolutely must work in incognito mode.
> Another option is to have scoping of extensions; globally or profile based. But that sounds complicated.
> Maybe for now just implement profile-scoped extensions, and if this is
> obviously insufficient then you can add global scopes?
Let me propose a slight variation: Extensions are installed globally,
enabled or disabled per-profile and globally
set as enabled or disabled by default. Here is the rationale:
- Based on the fact users want different extensions (moslty because
they like different behaviors/UI/etc) we
need to be able to selectively enable them per-profile.
- IMO, the main argument for global extensions (or even profile
options) for vendors is to set extensions and options
before any user account is created. Say you are Lenovo and you want
an extension for reporting issues to Lenovo
but you do not have a place to put because user's haven't created
any profiles yet, they haven't even bought the
machine. If you can globally set what extensions (and options) are
enabled (selected) by default then each time
a new user starts Chrome for the first time, all those things get
set into their (new) profile. From that point, users
are free to disable and change any extensions and options they want.
On Thu, Dec 18, 2008 at 7:01 AM, idanan <chr...@cybernium.net> wrote:
> On Dec 16, 8:50 pm, Mike Belshe <mbel...@google.com> wrote: > > My thought is that extensions should not apply in the incognito mode.
> That would be terrible. Imagine a usability extension (zoom part of > the view, support for alternate input method, etc) > and it would go away when you're incognito. Sorry to disagree but if I > say they absolutely must work in incognito mode.
> > Another option is to have scoping of extensions; globally or profile > based. But that sounds complicated.
> > Maybe for now just implement profile-scoped extensions, and if this is > > obviously insufficient then you can add global scopes?
> Let me propose a slight variation: Extensions are installed globally, > enabled or disabled per-profile and globally > set as enabled or disabled by default. Here is the rationale:
> - Based on the fact users want different extensions (moslty because > they like different behaviors/UI/etc) we > need to be able to selectively enable them per-profile. > - IMO, the main argument for global extensions (or even profile > options) for vendors is to set extensions and options > before any user account is created. Say you are Lenovo and you want > an extension for reporting issues to Lenovo > but you do not have a place to put because user's haven't created > any profiles yet, they haven't even bought the > machine. If you can globally set what extensions (and options) are > enabled (selected) by default then each time > a new user starts Chrome for the first time, all those things get > set into their (new) profile. From that point, users > are free to disable and change any extensions and options they want.
> - Itai
Yes, this is exactly the kind of use case that led to adding support for globally installable extension in Firefox. We had a number of Google products shipping Firefox extensions and IE extensions, and it was desirable to be able to register a Firefox extension before Firefox had even been installed, just in case Firefox happens to be installed, the extension will then become visible to Firefox.
|
