InformAction Forums

After activating the viddler.com flash player placeholder here, viddler.com is added to the NS menu. It doesn't look like any script is loaded on activation, so that shouldn't be happening. Also, if you now revoke temp perms and reload, viddler.com is still in the menu (it isn't on first load)

al_9x wrote:After activating the viddler.com flash player placeholder here, viddler.com is added to the NS menu. It doesn't look like any script is loaded on activation, so that shouldn't be happening. Also, if you now revoke temp perms and reload, viddler.com is still in the menu (it isn't on first load)

It gets to the menu because it is seen during a HTTP redirection then replaced with another URL.

Transient subrequest URLs seen during HTTP redirections are stored by NoScript in a document-level cache, so that they can be shown in the UI even though they're not currently referenced by the document itself, because there are frustrating situations where you can't understand that you need to allow a certain site in order for the page to work because it's been redirected (this is alleviate by "Recently blocked sites" as well, but the document-level cache is more specific while "Recently blocked sites" is a life safer for sources imported in chrome, e.g. by extensions).

There's no easy work-around for your issue and, frankly, the added complexity of a type-aware redirection cache outweighs the IMHO marginal benefit.

If the embedding only domain is already trusted, it appears in the menu. Forbidding it has no effect, and once forbidden it's hidden from the menu, so I think it should be hidden when trusted as well.

al_9x wrote:If the embedding only domain is already trusted, it appears in the menu. Forbidding it has no effect, and once forbidden it's hidden from the menu, so I think it should be hidden when trusted as well.

I'll bypass redirected sites caching for plugin content in next version.

Giorgio Maone wrote:

al_9x wrote:If the embedding only domain is already trusted, it appears in the menu. Forbidding it has no effect, and once forbidden it's hidden from the menu, so I think it should be hidden when trusted as well.

I'll bypass redirected sites caching for plugin content in next version.

Are you perhaps referring to the previous issue? It doesn't seem like showing of trusted domains is because of redirected site caching.

al_9x wrote:

Giorgio Maone wrote:

al_9x wrote:If the embedding only domain is already trusted, it appears in the menu. Forbidding it has no effect, and once forbidden it's hidden from the menu, so I think it should be hidden when trusted as well.

I'll bypass redirected sites caching for plugin content in next version.

Are you perhaps referring to the previous issue? It doesn't seem like showing of trusted domains is because of redirected site caching.

Yes it is.

Giorgio Maone wrote:

al_9x wrote:Are you perhaps referring to the previous issue? It doesn't seem like showing of trusted domains is because of redirected site caching.

Yes it is.

But .75 did take care of the previous, viddler, issue, and not this one. An embedding only whitelisted domain (djo.ca) is still shown in the menu.

al_9x wrote:An embedding only whitelisted domain (djo.ca) is still shown in the menu.

As far as I can see it's shown only if the frame is already unblocked (I can't see any "Forbid djo.ca" until I unblock the frame).
Then, showing it is correct because it may or may not contain scripts, either in the current page or in one you may navigate or can be refreshed from the same domain (it actually contains scripts in the current page).

Giorgio Maone wrote:

al_9x wrote:An embedding only whitelisted domain (djo.ca) is still shown in the menu.

As far as I can see it's shown only if the frame is already unblocked

Check "no placeholder from untrusted" and "forbid djo.ca" should show up.

One of the enhancements in this thread was showing embedding only domains in the untrusted menu when "no placeholder from untrusted" is set. But normally you don't allow the direct transition from whitelisted to untrusted, so is that why you show "forbid djo.ca"? I would argue that at least in this case it would make more sense for djo.ca to be in the untrusted menu for a direct whitelisted -> untrusted transition, than in the main menu, since forbidding it has no effect.

Incidentally, direct untrusted->whitelisted transitions are the only ones available.

in .77 grosbs.com is the menu for no discernible reason

al_9x wrote:in .77 grosbs.com is the menu for no discernible reason

There is an image there http://non.grosbs.com/censure468x60.gif that gets 301 to http://www.grosbs.com/non which is an HTML page with script. But since this is an img tag this html should just be seen as an invalid content and not html parsed, is that right? So it shouldn't be in the menu.

al_9x wrote:in .77 grosbs.com is the menu for no discernible reason

What's the page, exactly?

Giorgio Maone wrote:

al_9x wrote:in .77 grosbs.com is the menu for no discernible reason

What's the page, exactly?

http://djeault.blogspot.com/2007/02/iframe-test.html

al_9x wrote:in .77 grosbs.com is the menu for no discernible reason

It's the redirection cache striking back. The difference with .76 is that request type info is attached to the loading channel for images as well (needed by ABE's INCLUSIONS feature), therefore is "seen" during redirection and subject to caching.
I'm changing the redirection caching mechanism to store exclusively script and XBL info.