RFE: Use separate permissions for Private Browsing windows

[CitrusBoard]

I have just been horrified at behaviour of NoScript and this thread topic seems to be the only recently active topic that is related to the problem I've seen.

The problem is that NoScript doesn't respect the Private Window mode of Firefox.
I usually block Tynt since they are basically a tracker.
On one occasion I wanted to use a google-based visitor origin map provided by amung.us.
I was surprised to find that allowing amung.us was insufficient to get the map working.
I discovered that amung.us was also referring to Tynt.
Instead of allowing Tynt, I first created a Private Window because a Private Window will start with no cookies and so any prior tracking cookies would not flow across to the map app in the Private Window, and no information/cookies gained in the Private window will be able to get back to the normal browsing sessions.
I then Temporarily Enabled amung.us, tynt, and other required sites in NoScript IN THE PRIVATE WINDOW.
The visitor origin map then worked correctly in the amung.us Private Mode window.
I left the private window open and continued to use the first browser window for browsing a blog.
I suddenly realised with horrow that now Tynt was allowed in the main browser window too. I think this breaks the expectations that are set by opening a Private Window.

Each Private Window should be treated as a separate security domain which is initialised with the permissions that are configured in the NoScript saved settings, and the permissions for that window can only be changed by the NoScript buttons/icons in that window only.

[Thrawn]

Hi, CitrusBoard.

I've split this into a new topic, since it was not really related.

Having separate permissions in a private browsing window is not unreasonable. However, I don't see it as being essential, either. NoScript is not a privacy addon; it is a security addon.

You may notice that your other browser settings (proxy settings, filetype handlers, download settings, etc) are retained in a Private Browsing session, too. If you installed a new addon in a Private Browsing window, I think you'd find that it would be installed for all windows. Only your browsing history, cookies, etc, are isolated.

Retaining NoScript permissions does not allow sites to track you across windows (given that the cookies and history are isolated), so I don't think that this actually breaks the contract of private browsing.

However, as I said, it's not unreasonable, and if Giorgio has time to implement it, it makes sense. Particularly for temporarily-allowed sites. I can definitely see some usefulness in having temporary permissions isolated by private browsing.

But I suspect it would be a lot of work for him, and he already has a lot keeping him busy. I wouldn't put it high on his to-do list.

[Giorgio Maone]

Each Private Window should be treated as a separate security domain which is initialised with the permissions that are configured in the NoScript saved settings, and the permissions for that window can only be changed by the NoScript buttons/icons in that window only.

I understand your point, even though it should be noted that Private Browsing is not about anti-tracking/anonymity (check the TOR Browser for that, albeit it has also its share of issues): Private Browsing is mainly about not leaving local traces behind you, e.g. in your filesystem, for instance to prevent your family or your co-workers from investigating your browsing habits.

Anyway, unfortunately Gecko's ScriptSecurityManager component and CAPS, the Mozilla technology leveraged by NoScript to reliably implement inline script blocking, are site-based, globally configured and window-agnostic. They predate both global and per-window Private Browsing by several years, and very few Mozilla developers dare touch them. Therefore retrofitting them to properly interact with PB would take a lot of work, reviews and risk-taking in a very sensitive code area (security) not just from me, but from Mozilla itself, and it's quite unlikely to happen any time soon.
At any rate, you may want to watch this bug about improvements in this area where I'm going to link your RFE too.

I'm exploring other alternatives, like shifting away from CAPS (declarative permissions) and implement them programmatically, which would give NoScript finer grained control on its permission handling strategies, but again it's not something that will happen overnight because it would be a fundamental architectural overhaul.

[EDITED] added reference to a RFE bugzilla entry related to CAPS.

[barbaz]

Just curious if this is actually possible now with the new APIs in Gecko 29+ ?