InformAction Forums

I'm trying to figure out whether I should forbid <FRAME> & <IFRAME>. These are allowed on a default NoScript install.

I read the FAQ on this. But it makes it sound like because of NoScript updates I can enable <IFRAME> without any problems. It says nothing about the <FRAME> option.

Could someone say something about these? Will there be subtle breakage if I forbid both Frame and iFrame on a system that allows scripts globally but applies all embeddings to whitelisted sites? Or will any breakage be obvious and immediately apparent? What's the difference between Frame and iFrame? when would I forbid one but not the other?

Thanks

nickr wrote:I'm trying to figure out whether I should forbid <FRAME> & <IFRAME>. These are allowed on a default NoScript install.

Some concessions to best safety have been made so that novice users don't become discouraged and disable NoScript as soon as a page breaks.
(This has happened a lot over the years.)

The maximum safety is achieved by checking *everything* on the Embeddings tab, though that will involve selectively allowing various things at various sites.
There is always a trade-off between security and convenience. If everyone were honest, we wouldn't need locks on our doors and keys in our pockets, right?

nickr wrote:I read the FAQ on this. But it makes it sound like because of NoScript updates I can enable <IFRAME> without any problems.

It says that you should enable IFRAME *blocking*.

Furthermore, since clickjacking became popular, enabling it (( IFRAME blocking)( is probably a good idea

nickr wrote:Will there be subtle breakage if I forbid both Frame and iFrame on a system that allows scripts globally but applies all embeddings to whitelisted sites? Or will any breakage be obvious and immediately apparent?

If a page works as desired, then there isn't a problem or a decision to be made.

If a page doesn't do what you expect it to do, note that the NoScript logo is no longer solid blue. It's shaded, or part red, or all red.

You should also see a placeholder (red NoScript block-logo), depending on your settings in NS > Options > Embeddings:
"Show placeholder icon"
"No placeholder for objects coming from sites marked as untrusted".

Open the menu and point to Blocked Objects to display the list of frames and other code objects that are being blocked.
Or hover the mouse pointer over said placeholder, and read the tooltip that identifies the blocked object and its source.

Observe their source, then determine whether you trust that source and wish to allow it.
Hint: If it isn't necessary -- if the page works without it -- no need to allow. Those that have "ad" or "ads" in the name are rarely necessary.

What's the difference between Frame and iFrame?

Nothing that affects your decision-making. Not being condescending; just trying not to get too technical in the reply.
Something is either trustworthy or it isn't, no matter what kind of code, script or object.

More info is available, should you like.

when would I forbid one but not the other?

As said, I block them all by default, then enable those that are necessary at sites that I trust and from sources that I trust.

Thanks

You're very welcome.
If you have specific examples -- URLs and what objects are trying to run, or what's not working on the page -- feel free to post them.

Also, as you become more comfortable with this powerful protection, try unchecking "Scripts globally allowed".
It isn't really all that hard to get used to creating a whitelist or temp-allowing sites, and there are plenty of resources to help you: the NoScript Quick Start Guide, NoScript FAQ, searching this forum, and, if those don't answer your questions -- us.

therube wrote:Difference Between FRAME and IFRAME

[quote="Tom T"."]Nothing that affects your decision-making... [/quote]
And that information affects the trust decision -- how? (rhetorical question)

Tom T. wrote:

nickr wrote:I'm trying to figure out whether I should forbid <FRAME> & <IFRAME>. These are allowed on a default NoScript install.

Some concessions to best safety have been made so that novice users don't become discouraged and disable NoScript as soon as a page breaks.
(This has happened a lot over the years.)

The maximum safety is achieved by checking *everything* on the Embeddings tab, though that will involve selectively allowing various things at various sites.
There is always a trade-off between security and convenience. If everyone were honest, we wouldn't need locks on our doors and keys in our pockets, right?

nickr wrote:I read the FAQ on this. But it makes it sound like because of NoScript updates I can enable <IFRAME> without any problems.

It says that you should enable IFRAME *blocking*.

Furthermore, since clickjacking became popular, enabling it (( IFRAME blocking)( is probably a good idea

nickr wrote:Will there be subtle breakage if I forbid both Frame and iFrame on a system that allows scripts globally but applies all embeddings to whitelisted sites? Or will any breakage be obvious and immediately apparent?

If a page works as desired, then there isn't a problem or a decision to be made.

If a page doesn't do what you expect it to do, note that the NoScript logo is no longer solid blue. It's shaded, or part red, or all red.

You should also see a placeholder (red NoScript block-logo), depending on your settings in NS > Options > Embeddings:
"Show placeholder icon"
"No placeholder for objects coming from sites marked as untrusted".

Open the menu and point to Blocked Objects to display the list of frames and other code objects that are being blocked.
Or hover the mouse pointer over said placeholder, and read the tooltip that identifies the blocked object and its source.

Observe their source, then determine whether you trust that source and wish to allow it.
Hint: If it isn't necessary -- if the page works without it -- no need to allow. Those that have "ad" or "ads" in the name are rarely necessary.

What's the difference between Frame and iFrame?

Nothing that affects your decision-making. Not being condescending; just trying not to get too technical in the reply.
Something is either trustworthy or it isn't, no matter what kind of code, script or object.

More info is available, should you like.

when would I forbid one but not the other?

As said, I block them all by default, then enable those that are necessary at sites that I trust and from sources that I trust.

Thanks

You're very welcome.
If you have specific examples -- URLs and what objects are trying to run, or what's not working on the page -- feel free to post them.

Also, as you become more comfortable with this powerful protection, try unchecking "Scripts globally allowed".
It isn't really all that hard to get used to creating a whitelist or temp-allowing sites, and there are plenty of resources to help you: the NoScript Quick Start Guide, NoScript FAQ, searching this forum, and, if those don't answer your questions -- us.

Because of this I now block the iframe attribute. More smart, more secure.

therube wrote:Difference Between FRAME and IFRAME

Thank you for that!

General rule of thumb, a FRAME can be used to create a nearly 0 px hidden area where things can happen without user knowledge and better programmers will avoid them, so a good practice to block them. IFRAME is even more wild and can cause a much wider attack vector by basically implementing a complete cross site or outside resource inside the page you are using which can be benign (as how FB uses it to serve their APPS) or malicious to serve content, for best security practices, block IFRAME as well and allow only as needed and vetted. Personally I block them BOTH and have never looked back and never seen an issue that warranted a change in behavior on that. However, ultimately, it comes down to the users' needs and choices, a generalized rule wouldn't be wise. But on a personal note, blocking them both would be a wise choice IMHO.

Thanks for the tip; thou shalt follow suit. If need be I can try to create an ABE rule for certain things [e.g. showing the iframe on eBay sites due to the seller's description being in an iframe].

GµårÐïåñ wrote:General rule of thumb, a FRAME can be used to create a nearly 0 px hidden area where things can happen without user knowledge and better programmers will avoid them, so a good practice to block them. IFRAME is even more wild and can cause a much wider attack vector by basically implementing a complete cross site or outside resource inside the page you are using which can be benign (as how FB uses it to serve their APPS) or malicious to serve content, for best security practices, block IFRAME as well and allow only as needed and vetted. Personally I block them BOTH and have never looked back and never seen an issue that warranted a change in behavior on that. However, ultimately, it comes down to the users' needs and choices, a generalized rule wouldn't be wise. But on a personal note, blocking them both would be a wise choice IMHO.

No offense intended, but why are we making this so complicated? You agreed that both can cause mischief. (As can everything else that NoScript can affect, or it wouldn't be there.)

Tom T. wrote:Something is either trustworthy or it isn't, no matter what kind of code, script or object.
As said, I block them all by default, then enable those that are necessary at sites that I trust and from sources that I trust.

Simple.

Those who want to acquire the knowledge behind it can find plenty on the Web. I found Wikipedia articles; therube found another source. (This is why there are search engines. ) But too many users are intimidated by tech details already.

OP asked, should I block them? Unanimous answer: Yes.

@Tom, I am sorry, I wasn't trying to make it more complicated, just giving a bit of perspective on the subtle differences and why they should both be blocked which was my final assessment, but you are right I should have just said yes and left it at that. Just didn't want the OP saying, why? and THEN having to explain.

I benefited from it, thanks. Because of that I block both.

Identities Infinite wrote:I benefited from it, thanks. Because of that I block both.

Glad to hear it, you are welcome. As Tom pointed out there are tons of technical difference specs out there but I find many getting confused by some of the ironically subtle differences not the major ones and that's why I usually elaborate on just THOSE subtle ones. Either way, glad you found it useful.

A slight OT as a concept example, most services providing HOPS, meaning say www.hopservice.com/tome which points to say www.mydomainissodarnlongandugly.com will use zero size or flat header FRAMEs to keep the URL looking like the hop service short, while loading your longer ugly one inside the lower frame that is maximized so as to "hide" the ugly path, so to speak. This is benign for the most part but still why risk it, you don't know what else they might load in that tiny sliver that might be harmful or tracking or whatever. So block it, so it forces the real domain to show. IFRAME would be if you want to embed or use external service like www.some-poll-provider.com/your.username within your www.domain.com/feedback so you create an IFRAME to embed it and make it "look" singular, but can also expose the user to whatever that thirdparty serves, so at least blocking it, you KNOW they are doing it and can CHOOSE to allow it or not. Sorry, I promise, last word on this.

Not to harp on the subject but are frames usually for visual styling anyway? If so they have no use for me in that regard. I comprehend your point though.

Identities Infinite wrote:Not to harp on the subject but are frames usually for visual styling anyway? If so they have no use for me in that regard. I comprehend your point though.

Used to be for that purpose in the beginning but as with anything else has evolved to be pretty useless in designing and mostly for lazy or malicious use now. Although has some legitimate purposes still. using styling, you can make them virtually invisible.

Identities Infinite wrote:Not to harp on the subject but are frames usually for visual styling anyway? If so they have no use for me in that regard. I comprehend your point though.

To quote from the article linked by therube:

A web page may be divided into several blocks using Frames for displaying multiple scrollable files like documents and/or graphic images etc., at once in independent windows or sub windows.

The graphic images don't matter to you, but the documents, scrollable or otherwise, do. So at a given trusted site, it is possible that allowing FRAME may be required. However, empirically I don't run into them very often. IFRAME is much more common, whether used by that site or a third-party site.

Another merit of Iframes is its ability of displaying other website contents flawlessly in one user’s window

Which may be legitimate, or it may be advertising junk, even possibly malicious.

So we come back to the same old, same old. Sorry to repeat myself, but:
Default-block all, and triage permissions in this order:

1) NECESSITY. If the function you want works without a particular permission, why have unnecessary code running, consuming bandwidth, memory, CPU time, etc., as well as the slight risk that it may be malicious or compromised? Even if something else on the site breaks, so long as you get what you need, who cares? Mostly what "breaks" is ads .... [grin]

2) Trustworthiness of the site you are on

3) Trustworthiness of the content provider that you are considering allowing.

Is this not common sense?