InformAction Forums

I had an idea for a way to avoid breaking sites in situations where a page reload, particularly one with scripts partially blocked, may be undesirable (eg when performing a financial transaction).

What if NoScript could be put into a mode where, instead of simply blocking scripts from unknown domains, it would prompt you for each domain? With options to permanently/temporarily allow, mark as Untrusted, or return to normal mode.

Already-whitelisted domains would be ignored, of course, and probably Untrusted domains would too. Even so, it would be far too noisy for general use. But if you know you're going to be paying for something, etc, then it may be valuable to have NoScript ask you every time during that interaction, instead of potentially breaking something.

This could also help solve the problem of multiple page reloads for nested scripts; you could put NoScript into interactive mode, then make a decision about each site in a single pass.

Anyone's thoughts? Giorgio in particular?

nvm

Unfortunately this wouldn't work for the nested script loads case, because until the first script is loaded and executed NoScript cannot "foresee" what else is gonna be required.
Investigating other use cases, thank you.

So...NoScript doesn't get to intercept the script as it's running? It has to know everything that will be loaded in advance?

I was under the impression that if, say, script from domain A waits 2 minutes and then tries to load scripts from domain B, then NoScript will block domain B at that point (2 minutes in) and add B to the menu.

This would change that so that after 2 minutes, NoScript would pop up a confirmation dialog of some kind, asking whether you want to allow B.

Maybe I misunderstood NoScript's mechanisms. Surely it is able to intercept and check each HTTP request? (Otherwise we couldn't have ABE.)

As mentioned, this would be much too noisy/intrusive for general browsing, but useful in specific situations where you don't want to risk breaking something sensitive.

Basically, within MainContentPolicy.shouldLoad, before rejecting a request, if in interactive mode, then first pop up a confirmation dialog to the user. If they want to continue blocking the domain, that's fine (ideally find a way to silence further confirmation dialogs for that domain on the current page, maybe based on a timer). If they choose to allow the domain, then it gets added to the whitelist and the original request never gets blocked; shouldLoad returns CP_OK. That way, you don't need to reload the page unless you later change your mind about a domain, meaning that the issue of nested scripts doesn't arise and sensitive interactions don't get broken.

Maybe logic could be added to the ns.reject function for this, so that if it's in interactive mode, then it checks with the user first.

Bump.

Is it feasible for behind-the-scenes code like MainContentPolicy to launch a confirmation dialog to the user? It's not usual practice, I know, and it would easily become intrusive, but in the specific case where the user has requested interactive script-blocking, can it be done?

It's more than just nsIContentPolicy work, what about inline scripts and such?

barbaz wrote:what about inline scripts and such?

I don't think they're a problem, because if the top-level site is blocked, then all scripts are blocked, so there's no need for interactive mode.

I guess there might be issues in cases like Disqus opening a frame to log you into Google etc...