fx2 ebay nested iframe unclickable and no tooltip

[al_9x]

NS 1.9.9.27
1) forbid iframes on trusted, allow ebay.com, ebaystatic.com
2) go here
3) activate the description iframe placeholder (vi.ebaydesc.com), the description is not always in an iframe, reload the page until it is.
4) in that iframe there's another iframe placeholder (cgi.ebay.com)

The first issue (applies both to fx35 and fx2) is, should this nested iframe be blocked? Currently iframe context is checked against the parent. But perhaps it should also be checked against the root. If the root context check passes, it's a 1st party request (Fx concurs, it sends cookies) so there is no need to block it.

The second issue (fx2 only) is that the nested iframe placeholder has no tooltip and can't be clicked.

[Giorgio Maone]

The first issue (applies both to fx35 and fx2) is, should this nested iframe be blocked? Currently iframe context is checked against the parent. But perhaps it should also be checked against the root. If the root context check passes, it's a 1st party request (Fx concurs, it sends cookies) so there is no need to block it.

The parent check is the correct one.
Suppose an attacker on evil.com wants to frame good.com to exploit the parent-child relationship in some way.
Suppose good.com has an open framing redirection feature (like on Facebook links on Google Images).
evil.com can use the open redirection to get framed by good.com, and include a frame pointing to good.com.
Current policy will block both the frames, while your suggested policy will make the evil framing attempt to succeed without a warning.

[al_9x]

The first issue (applies both to fx35 and fx2) is, should this nested iframe be blocked? Currently iframe context is checked against the parent. But perhaps it should also be checked against the root. If the root context check passes, it's a 1st party request (Fx concurs, it sends cookies) so there is no need to block it.

The parent check is the correct one.
Suppose an attacker on evil.com wants to frame good.com to exploit the parent-child relationship in some way.
Suppose good.com has an open framing redirection feature (like on Facebook links on Google Images).
evil.com can use the open redirection to get framed by good.com, and include a frame pointing to good.com.
Current policy will block both the frames, while your suggested policy will make the evil framing attempt to succeed without a warning.

I didn't fully understand your scenario and what the protection is. Is it evil(root)->good(frame)->evil(frame)? Or good(root)->evil(frame)->good(frame)?

In the first case after you activate the good(frame) what is gained by blocking evil(frame) since you are already on evil(root)?

In the second case, what is gained by blocking good(frame) after you've already loaded evil(frame)?

[Giorgio Maone]

Is it evil(root)->good(frame)->evil(frame)? Or good(root)->evil(frame)->good(frame)?

The latter.

In the second case, what is gained by blocking good(frame) after you've already loaded evil(frame)?

For instance, before ClearClick, this was exactly the NoScript feature which protected you against clickjacking (preventing an evil page from framing a "good" one).