Known Issue: Inherit PBM

[kainsavage]

I know that the readme has this listed as a known error, but will the be addressed at some point? It seems very odd that opening another tab from a PBM tab continues the context.

As an example, I will have marked Reddit.com as a private browsing mode tab, then I open a link from that tab in a new tab. I'm on the fence with this one; I've gone to an entirely different domain potentially, so maybe it shouldn't be private. On the other hand, I can see the reasoning behind it being in PBM, so maybe this makes sense.

However, opening a bookmark in a new tab while my reddit.com tab is open an escalated to PBM makes no sense to me at all.

Personally, I think it would make the most sense to have only that tab in PBM as the context is "Private Tab", not "Private Tab... and all subsequent tabs."

[Infocatcher]

Unfortunately I don't see easy to implement (and maintain) alternative.
I don't like to patch (more, undoable patch!) many tab-related functions (and extensions may use own functions).
Or I may check call stack in handler for "TabOpen" event. But some tab-related extension may change functions, and call stack will be changed too.

And useful trick with current behavior: you can make current tab private to open link from external application in private tab. :)

[Infocatcher]

About inheritance. What to do for something like onclick="window.open('...')" on pages? It's easy to disable inheritance, but some links may be opened in new tabs without user request.

[kainsavage]

Private_Tab gives the user the ability to choose to open a tab in a private session, but it is in the context of the link they are trying to open. If the user wants the "next" tab to ALSO open in a private session, then they would click "open link in new private tab" again.

In the case of onclick="window.open(...)" or target="_blank", I do not have a good answer. Maybe the user should still have to click "open link in new private tab" again?

I understand the reasoning for your current implementation. I may be trying to shoehorn your API into my use-case, and it just doesn't match up as well as I had hoped it would.

[ssokolow]

@kainsavage I can see the benefit to both sides but, as an end user, I never bother with the context menu and just use middle-click to open new tabs. I expect middle-clicking and window.open to preserve the privacy state of the parent tab unless I explicitly change it. In fact, I care about this much more than issue #40.

Among other reasons:

• it ensures that no site can see both my non-private cookies and a HistoryBlock'd URL via the Referer header. Either the site is private or I manually copied the URL into a fresh tab.
• If window.open doesn't preserve privacy state, you could end up with a child window/tab breaking for lack of access to the parent's session cookie.

I'd be perfectly fine with HistoryBlock turning on Private Browsing for tabs but not turning it off again. It means that I don't forget to turn it on but, if I forget to turn it off, whatever site I visit next is isolated from my "Remember Me" cookies.

Basically, I see it as a way to maximize the chance of mistakes exhibiting failsafe behaviour.

[gopikrish2000]

As a User I'm very much happy with the current behavior of subsequent tabs ( on middle click ) also being private Tabs because if we do a google search in a private tab we definitely want to open the individual results also in private mode with middle click [ rather than right click open as new private tab ] .

@ssokolow as he mentioned it will also maximize the chance of failsafe behaviour .
@Infocatcher I think many users use like me . So please don't change this behaviour