Blocked content: "*@https://..." and "unknown@http://..."

[vgoevuzu]

I have iFRAMEs blocked in the embeddings tab. So when I go to some sites, I get a NoScript blocked content indicator. If I go to the NoScript Menu and look at what blocked content there is, I see what is in the screenshot I've attached.

As you can see in the png, I see three different kinds of description:

Code: Select all

<IFRAME>@https://www.google.com/cse

Code: Select all

*@https://www.google.com

Code: Select all

unknown@https://www.google.com

What is the "*@" communicating to me? What should I understand from this?
What is the "unknown@" communicating? What should I understand from this?
Should I click one of these, but not others? How do I go about making this decision and understanding this communication?

http://i.imgur.com/sAWnPW2.png

[Thrawn]

What is the "*@" communicating to me? What should I understand from this?

If you click on that menu item, then all plugin objects coming from that site, of any type (Flash, Java, IFRAME, etc), will be allowed to run. This will not allow objects from other sites.

What is the "unknown@" communicating? What should I understand from this?

It means 'some kind of plugin object, but not one that the Blocked Objects feature specifically handles'.

Should I click one of these, but not others? How do I go about making this decision and understanding this communication?

Just as you do for scripts, you should decide whether you trust the site that the objects are coming from, then experiment to find out what is needed for the page to run. I wouldn't recommend using the '*@' in most circumstances; use the specific object instead (IFRAME@).

Any further questions? Blocked Objects can be confusing at times.

[Tom T.]

To add my vote to Thrawn's fine reply, Best Practice is to use the *most restrictive* of the permissions offered, provided that they fulfill the need.
You may need more than one.

I, too, avoid wildcard permissions:

Code: Select all

*@http://somesite.com

Often, this is a Font download, and while they may be legit, if you search the Web for "font vulnerability", be prepared to be shocked.

[Thrawn]

Also, fonts are very rarely needed for the page to run. The only consistent exception that I've found has been when viewing a PDF in pdf.js.

And I'll pre-empt Tom by adding that if you're concerned about downloading font objects in any circumstances, then you can use an external PDF reader like Foxit or Sumatra instead. Adobe Acrobat Reader is not usually a good choice, because it's huge (which means more places where the code could contain exploitable errors) and frequently targeted by attackers.