Re: [chromium-dev] RFC: Extensions Incognito
After the feedback I received, I realized that my original proposal didn't actually meet one of the goals I intended (that existing extensions would work in incognito transparently). I decided to dial it back a bunch and incorporated some other feedback from Erik and Aaron. Here is v2 of the proposal: https://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=en Changes: - No more separate incognito instance of extension pages. - Users have to opt-in to enable an extension in incognito. - Extension developers can mark their extension incognito safe. We might warn the user if he tries to enable an unsafe extension in incognito. - Some API changes to support incognito data. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] RFC: Extensions Incognito
I've shared a document with you: Extensions Incognito http://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
Right now a convenient way to see if a website is having problems due to some extension's content script is to open an Incognito window. Would it make sense to add a way to easily disable extensions in Incognito mode, like a button in the Incognito window's Browser Actions area or something? (Perhaps the spy guy would then wrap an extra cloak around his face or be surrounded by a force field? :) ) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG * * The idea of having the ability to do both read-only and read-write access to the main profile is one that's mirrored in the low-level APIs inside Chromium, where we have an enum that differentiates between these cases that we can pass when trying to gain access to various data stores, which modifies what happens. I like this parallel and maybe we can implement the high-level APIs in terms of those low-level ones. On Wed, Jan 13, 2010 at 2:45 PM, Antony Sargent asarg...@chromium.org wrote: Right now a convenient way to see if a website is having problems due to some extension's content script is to open an Incognito window. Would it make sense to add a way to easily disable extensions in Incognito mode, I think the use case is important (does one of my extensions break stuff), but the current method to solve it (open an incognito window) is a hack, so I wouldn't want to tie a proper solution to Incognito mode. It seems like this is a good use case to keep in mind when figuring out what UI to give users to control extensions (and plugins). We have some, but there seems to be general agreement that we can do more/better (e.g. a simple disable all button). I also think there's a use case for saying that X extensions should be enabled/disabled in normal mode but not Incognito, but that may be more granularity than we can coherently expose in UI. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
Interesting. So if an extension has a background page, the idea is that as soon as we open an incognito page every extension with a background page would load up a second instance, which would remain running even after the incognito window has closed? One of the things I'm looking at is allowing extensions to expose UI through systray icons (part of my proposal to add persistence to extensions) - if multiple instances of these extensions were loaded due to incognito windows, you'd end up with multiple duplicate systray icons, which seems wonky. These are all issues that would also occur if you had multiple profiles, but I think it'd be confusing to users if there were user-visible artifacts of having multiple extensions loaded due to incognito windows. -atw On Wed, Jan 13, 2010 at 2:57 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG * * The idea of having the ability to do both read-only and read-write access to the main profile is one that's mirrored in the low-level APIs inside Chromium, where we have an enum that differentiates between these cases that we can pass when trying to gain access to various data stores, which modifies what happens. I like this parallel and maybe we can implement the high-level APIs in terms of those low-level ones. On Wed, Jan 13, 2010 at 2:45 PM, Antony Sargent asarg...@chromium.org wrote: Right now a convenient way to see if a website is having problems due to some extension's content script is to open an Incognito window. Would it make sense to add a way to easily disable extensions in Incognito mode, I think the use case is important (does one of my extensions break stuff), but the current method to solve it (open an incognito window) is a hack, so I wouldn't want to tie a proper solution to Incognito mode. It seems like this is a good use case to keep in mind when figuring out what UI to give users to control extensions (and plugins). We have some, but there seems to be general agreement that we can do more/better (e.g. a simple disable all button). I also think there's a use case for saying that X extensions should be enabled/disabled in normal mode but not Incognito, but that may be more granularity than we can coherently expose in UI. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 3:09 PM, Drew Wilson atwil...@chromium.org wrote: Interesting. So if an extension has a background page, the idea is that as soon as we open an incognito page every extension with a background page would load up a second instance, which would remain running even after the incognito window has closed? I think we can terminate the second background page when the incognito window closes, but otherwise that is the idea. One of the things I'm looking at is allowing extensions to expose UI through systray icons (part of my proposal to add persistence to extensions) - if multiple instances of these extensions were loaded due to incognito windows, you'd end up with multiple duplicate systray icons, which seems wonky. These are all issues that would also occur if you had multiple profiles, but I think it'd be confusing to users if there were user-visible artifacts of having multiple extensions loaded due to incognito windows. One of the reasons I wanted to address extensions in incognito now is so we come up with a solution before painting ourselves into a corner. Depending on the way this systray API is designed, it can be specced so that only one systray icon is created regardless of incognito. That said, you bring up a good point in general, and I will add it to the list of cons. Unfortunately I don't know of any alternative approach that doesn't cause extensions to violate incognito mode. -atw On Wed, Jan 13, 2010 at 2:57 PM, Peter Kasting pkast...@google.comwrote: On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG * * The idea of having the ability to do both read-only and read-write access to the main profile is one that's mirrored in the low-level APIs inside Chromium, where we have an enum that differentiates between these cases that we can pass when trying to gain access to various data stores, which modifies what happens. I like this parallel and maybe we can implement the high-level APIs in terms of those low-level ones. On Wed, Jan 13, 2010 at 2:45 PM, Antony Sargent asarg...@chromium.org wrote: Right now a convenient way to see if a website is having problems due to some extension's content script is to open an Incognito window. Would it make sense to add a way to easily disable extensions in Incognito mode, I think the use case is important (does one of my extensions break stuff), but the current method to solve it (open an incognito window) is a hack, so I wouldn't want to tie a proper solution to Incognito mode. It seems like this is a good use case to keep in mind when figuring out what UI to give users to control extensions (and plugins). We have some, but there seems to be general agreement that we can do more/better (e.g. a simple disable all button). I also think there's a use case for saying that X extensions should be enabled/disabled in normal mode but not Incognito, but that may be more granularity than we can coherently expose in UI. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
Have you considered how incognito interacts with extensions that have NPAPI components? It might not be feasible to create a second, isolated instance of those extensions because the NPAPI component has direct access to system calls. I wonder if read-only access to localStorage will be confusing to authors. I can imagine extensions doing wonky things if they assume they can write to localStorage. Maybe we should have a separate API for reading information from the non-incognito localStorage? Adam On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Message from mpcompl...@chromium.org: Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. Click to open: - Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth aba...@chromium.org wrote: Have you considered how incognito interacts with extensions that have NPAPI components? It might not be feasible to create a second, isolated instance of those extensions because the NPAPI component has direct access to system calls. Good point, I hadn't considered that. This is similar to Drew's point about a systray API. I wonder if read-only access to localStorage will be confusing to authors. I can imagine extensions doing wonky things if they assume they can write to localStorage. Maybe we should have a separate API for reading information from the non-incognito localStorage? Would localStorage start off empty (and have no persistence) as it does in regular renderers, then? I think read-only access to localStorage is important because extensions currently use it for storing preferences, and ideally they would share settings without the extension explicitly supporting it. Adam On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Message from mpcompl...@chromium.org: Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. Click to open: - Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
What if the Incognito profile started with a copy-on-write version of extensions' localStorage? That way extensions in Incognito mode would see the writes they just made, but changes would not persist beyond Incognito mode. Then we could either add the messaging API for Incognito - Regular extension communication, or add an explicit settings API that would have the same storage regardless of Incognito mode. On Wed, Jan 13, 2010 at 3:30 PM, Matt Perry mpcompl...@chromium.org wrote: On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth aba...@chromium.org wrote: Have you considered how incognito interacts with extensions that have NPAPI components? It might not be feasible to create a second, isolated instance of those extensions because the NPAPI component has direct access to system calls. Good point, I hadn't considered that. This is similar to Drew's point about a systray API. I wonder if read-only access to localStorage will be confusing to authors. I can imagine extensions doing wonky things if they assume they can write to localStorage. Maybe we should have a separate API for reading information from the non-incognito localStorage? Would localStorage start off empty (and have no persistence) as it does in regular renderers, then? I think read-only access to localStorage is important because extensions currently use it for storing preferences, and ideally they would share settings without the extension explicitly supporting it. Adam On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Message from mpcompl...@chromium.org: Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. Click to open: - Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
On Wed, Jan 13, 2010 at 3:48 PM, Antony Sargent asarg...@google.com wrote: What if the Incognito profile started with a copy-on-write version of extensions' localStorage? That way extensions in Incognito mode would see the writes they just made, but changes would not persist beyond Incognito mode. This actually wouldn't be too hard to do and probably makes the most sense. (SessionStorage, which shares 99% of the same code, already uses COW when you duplicate tabs.) Then we could either add the messaging API for Incognito - Regular extension communication, or add an explicit settings API that would have the same storage regardless of Incognito mode. On Wed, Jan 13, 2010 at 3:30 PM, Matt Perry mpcompl...@chromium.orgwrote: On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth aba...@chromium.org wrote: Have you considered how incognito interacts with extensions that have NPAPI components? It might not be feasible to create a second, isolated instance of those extensions because the NPAPI component has direct access to system calls. Good point, I hadn't considered that. This is similar to Drew's point about a systray API. I wonder if read-only access to localStorage will be confusing to authors. I can imagine extensions doing wonky things if they assume they can write to localStorage. Maybe we should have a separate API for reading information from the non-incognito localStorage? Would localStorage start off empty (and have no persistence) as it does in regular renderers, then? I think read-only access to localStorage is important because extensions currently use it for storing preferences, and ideally they would share settings without the extension explicitly supporting it. Adam On Wed, Jan 13, 2010 at 2:28 PM, mpcompl...@chromium.org wrote: I've shared Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Message from mpcompl...@chromium.org: Hi all, I'm working on adding support for running extensions in incognito mode (bug: http://code.google.com/p/chromium/issues/detail?id=20175 ). Here is a proposal for how it might work. Any and all feedback is welcome. Click to open: - Extensions Incognitohttp://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=eninvite=CJ3Si8MG Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations. [image: Google Docs logo] http://docs.google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
