Re: [chromium-dev] RFC: Extensions Incognito

[Matt Perry]

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_g6CjAZGdzZHJnanJfM2RiY3N3dmZz&hl=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

Re: [chromium-dev] RFC: Extensions Incognito

[Jeremy Orlow]

On Wed, Jan 13, 2010 at 3:48 PM, Antony Sargent  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 wrote:
>
>> On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth  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,  wrote:
>>>
  I've shared Extensions 
 Incognito
 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 
 Incognito


 Google Docs makes it easy to create, store and share online documents,
 spreadsheets and presentations.
 [image: Google Docs logo] 

 --
 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

Re: [chromium-dev] RFC: Extensions Incognito

[Antony Sargent]

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  wrote:

> On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth  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,  wrote:
>>
>>>  I've shared Extensions 
>>> Incognito
>>> 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 
>>> Incognito
>>>
>>>
>>> Google Docs makes it easy to create, store and share online documents,
>>> spreadsheets and presentations.
>>> [image: Google Docs logo] 
>>>
>>> --
>>> 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

[Matt Perry]

On Wed, Jan 13, 2010 at 3:16 PM, Adam Barth  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,  wrote:
>
>>  I've shared Extensions 
>> Incognito
>> 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 
>> Incognito
>>
>>
>> Google Docs makes it easy to create, store and share online documents,
>> spreadsheets and presentations.
>> [image: Google Docs logo] 
>>
>> --
>> 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

[Adam Barth]

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,  wrote:

>  I've shared Extensions 
> Incognito
> 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 
> Incognito
>
>
> Google Docs makes it easy to create, store and share online documents,
> spreadsheets and presentations.
> [image: Google Docs logo] 
>
> --
> 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

[Matt Perry]

On Wed, Jan 13, 2010 at 3:09 PM, Drew Wilson  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 wrote:
>
>> On Wed, Jan 13, 2010 at 2:28 PM,  wrote:
>>
>>  I've shared Extensions 
>> Incognito
>>> *
>>> *
>>>
>>
>> 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 
>>  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

[Drew Wilson]

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  wrote:

> On Wed, Jan 13, 2010 at 2:28 PM,  wrote:
>
>  I've shared Extensions 
> Incognito
>> *
>> *
>>
>
> 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 
>  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

[Peter Kasting]

On Wed, Jan 13, 2010 at 2:28 PM,  wrote:

> I've shared Extensions 
> Incognito
> *
> *
>

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 
 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

[Antony Sargent]

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

[chromium-dev] RFC: Extensions Incognito

[mpcomplete]

I've shared a document with you:

Extensions Incognito
http://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZz&hl=en&invite=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