NS not showing temp allow - automatically blocking.

[8-bit]

Have another question. I am sure there is a reasonable explanation, just not sure why NS is doing this:

Ok, If go to dell. com (the official Dell website). Here is what I see when I hover over the NS toolbar icon:


Stock. This is before I do anything.


Before temporarily allowing dell .com it is BLOCKING dellcdn. com (which is needed to show certain images on the site) and does not show as temporarily allow on the main hover menu (I do NOT have this site set as untrusted)


I have now temporarily allowed dell .com. dellcdn .com does not appear in the main hover menu so I can temporarily allow it - it is still a blocked object.


For reference/info...

I suppose my question is - why is dellcdn .com not in the main hover menu so I can temporarily allow it from there and why is it auto-blocked when I don't have it set as untrusted?

An explanation as to why this is would me MUCH appreciated. Using NS 5.0.2

Thanks!
8-bit

[barbaz]

I see the same. It's happening because dellcdn.com is not serving any scripts, only fonts.

However, I'm not quite sure whether it's all correct behavior or not.

[8-bit]

Thanks again for your input barbaz...

I will keep an eye on this thread to see what info you come up with (correct behavior/not etc.)

8-bit

[barbaz]

Ah, found the thread I was looking for - viewtopic.php?f=7&t=20430

The Recently blocked sites menu is behaving as expected, more on that later.

[8-bit]

Yes, understood about the Recently blocked sites menu behavior after reading that thread.

This helped me understand why, by design, it is like this:

Giorgio Maone » Tue Jan 20, 2015 11:36 am

I'm not sure about the "bug" we're talking about here.

Blocked 3rd party objects requiring the parent page's site to be whitelisted in order to be impicitly allowed by whitelisting their origin is by design. You can release this restriction by toggling the noscript.forbidActiveContentParentTrustCheck about:config preference to false.

Not showing a 1st class whitelisting "Allow..." menu item for origins which don't contribute any JavaScript to a certain page, but just embedded objects (which fonts are considered alike), is by design as well, asked long time ago by al_9x, IIRC. In theory this way we can discourage giving unneeded permissions (catch-all JavaScript + active content) where using the "Blocked Object" submenu to grant finer-grained privileges to the needed embeddings suffice, but I concede this can become cumbersome/confusing especially when you are not using the Apply these restrictions on whitelisted sites too Embeddings option (which is not the case reported here, though).

Regarding #2, maybe NoScript could show the whitelisting "Allow..." commands even for sites contributing just embeddings in the default configuration, i.e.as long as Apply these restrictions on whitelisted sites too is unchecked, since this option actually makes whitelisting non-JavaScript sources useless.

So, basically, this was a DESIGN decision,correct?

[barbaz]

Yes, understood about the Recently blocked sites menu behavior after reading that thread.

I haven't explained about Recently blocked sites yet. There's a really good explanation of Recently blocked sites, but it's not public. Still trying to see if I can quote it here.

So, basically, this was a DESIGN decision,correct?

Yep, looks like it.

[8-bit]

I haven't explained about Recently blocked sites yet. There's a really good explanation of Recently blocked sites, but it's not public. Still trying to see if I can quote it here.

Well, what I meant by that statement is that you said that the Recently blocked sites menu is behaving as expected. BUT, you did say more on that later. So hopefully you will be able to quote it here. I would be very interested in knowing.

Thanks for your continued support/research on this. I appreciate it very much.

8-bit

[barbaz]

"Recently blocked" contains "Allow all" (which includes both scripts and embeddings in one shot) for anything which got blocked in recently opened pages.
Therefore, if you've got "Apply these restrictions to whitelisted sites as well" checked for embeddings, you're likely to see entries like that until you allow embeddings for that domain as well.

[8-bit]

"Recently blocked" contains "Allow all" (which includes both scripts and embeddings in one shot) for anything which got blocked in recently opened pages.
Therefore, if you've got "Apply these restrictions to whitelisted sites as well" checked for embeddings, you're likely to see entries like that until you allow embeddings for that domain as well.

It is quite logical the way it is doing things, but I must tell you that I do not have "Apply these restrictions to whitelisted sites as well" checked for embeddings.

I can easily live with it, now that I know there may be something there I need to allow as well...

[barbaz]

It is quite logical the way it is doing things, but I must tell you that I do not have "Apply these restrictions to whitelisted sites as well" checked for embeddings.

"Apply these restrictions to whitelisted sites too" is somewhat irrelevant to this specific case. Because here we have a site that serves only embeddings.

Point is, the Recently blocked sites menu entries cover embeddings as well as scripts, by design.

[8-bit]

It is quite logical the way it is doing things, but I must tell you that I do not have "Apply these restrictions to whitelisted sites as well" checked for embeddings.

"Apply these restrictions to whitelisted sites too" is somewhat irrelevant to this specific case. Because here we have a site that serves only embeddings.

Point is, the Recently blocked sites menu entries cover embeddings as well as scripts, by design.

Ok, thanks!

[barbaz]

You're welcome!