NoScript, Live.com & Hotmail

[therube]

I don't understand it?
The page "refreshes" (if you will) many times. (Perhaps that's AJAX or something?)
Sometimes blocked objects show, but after all the refreshes, the Blocked Objects menu item disappears.
Allowing All does not work, & the icon does not display as an Allow All icon (instead displays as shown [though I have not Allowed All in the shot]).
The blocked object NoScript indicators do show on the page.
Only way I can see to get live.com do work, is to individually click on each indicator & Allow.
The topmost indicator seems to have no object attached?
I see no change in behavior with whatever version of NoScript I had before & the current #dev, 2.1.1.2rc4.

[therube]

Seems this only occurs when you have Apply these restrictions to whitelisted sites too enabled.

[al_9x]

http://forums.informaction.com/viewtopi ... =10&t=5374

It looks they are using <object> to prefetch and cache JS. I believe this particular use of <object> can be reliably detected, in which case NS should hide such placeholders and perhaps even have an option to not block them as they don't actually execute anything merely display the textual content, which is why they are used for prefetching and caching.

[Giorgio Maone]

I believe this particular use of <object> can be reliably detected

How would you suggest to do that?

[al_9x]

I believe this particular use of <object> can be reliably detected

How would you suggest to do that?

spec:
http://dev.w3.org/html5/spec/the-iframe ... ct-element

If the resource type is an XML MIME type, or if the resource type does not start with "image/"

The object element must be associated with a newly created nested browsing context, if it does not already have one.

If the URL of the given resource is not about:blank, the element's nested browsing context must then be navigated to that resource, with replacement enabled, and with the object element's document's browsing context as the source browsing context. (The data attribute of the object element doesn't get updated if the browsing context gets further navigated to other locations.)

So, a 0 size typeless object with a data url with a javascript mime will be loaded as an iframe. I don't know where the the relevant rules are but empirically it looks like javascript loaded as document is rendered by Fx as plain text, which is what those using this technique are depending on. Do you not think this is fixed, dependable behavior?

If it is, then can you not detect this scenario? You sniff the mime and know it's JS, also you can check the size. So at least hiding these prefetch object placeholders should be doable.

[Giorgio Maone]

So, a 0 size typeless object with a data url with a javascript mime will be loaded as an iframe.

In fact, NoScript trEats it as such: therube's issue happens only if Forbid iframes is checked.

However, for <OBJECT> loads I could hardcode a check for non-XML text/* mime types (e.g. text/javascript, text/css or text/x-c, like in this case) and try to verify also that no plugin has been associated to them: in that case, I would let the content load.

[al_9x]

So, a 0 size typeless object with a data url with a javascript mime will be loaded as an iframe.

In fact, NoScript trEats it as such: therube's issue happens only if Forbid iframes is checked.

However, for <OBJECT> loads I could hardcode a check for non-XML text/* mime types (e.g. text/javascript, text/css or text/x-c, like in this case) and try to verify also that no plugin has been associated to them: in that case, I would let the content load.

I think this also applies to "application/javascript"

A few wishes:

1) Hiding them is the real feature, because there could be lots of them and they could cover the whole screen. Please implement that.
2) auto allowing should be optional, since that's only a performance optimization, there is no pressing need for that. Allowing may be a reasonable default, but I would like to be able to keep them blocked, just in case, but hidden of course.
3) if auto allowed and is a script it should only load if the domain is script allowed, there is no point in prefetching a script that will not execute, that will actually reduce the NS performance gains resulting from not fetching non allowed scripts.
4) I don't think there is a reason to do this for anything other than css and javascript, is there?

[Giorgio Maone]

Please check latest development build.

[al_9x]

Fixed. Something I didn't notice before, which makes this fix more urgent than I thought: if the caching objects are blocked, whether by allowCachingObjects=false in rc5 or previous builds, hotmail doesn't work at all, clicks on folders or messages don't register. It's odd that there would be this kind of dependency on caching objects' successful loading, I'll try to figure it out.

Also, what about:

3) if auto allowed and is a script it should only load if the domain is script allowed, there is no point in prefetching a script that will not execute, that will actually reduce the NS performance gains resulting from not fetching non allowed scripts.

I meant the domain of the script, it looks like you're only checking the origin (page), which is also a good idea, but it's worth checking the script domain as well.

[Giorgio Maone]

I meant the domain of the script, it looks like you're only checking the origin (page), which is also a good idea, but it's worth checking the script domain as well.

The script domain is checked anyway, because I turn the type into "script" or "css" depending on the mime and from then on the rule for these types apply (so CSS usually passes, and JS passes only if whitelisted).
The parent domain needed to be checked because otherwise script sources which are whitelisted would be fetched even though they would never be used as scripts (script loading doesn't happen on script-disabled pages, even if the external source is whitelisted).

[therube]

(Live.com now working without issues.)

[al_9x]

The script domain is checked anyway, because I turn the type into "script" or "css" depending on the mime and from then on the rule for these types apply

I guess this explains the following:

test page from one domain, scripts from another

Code: Select all

<object width="0" height="0" data="http://different_domain/script1.js"></object>
<object data="http://different_domain/script2.js"></object>

When the page is allowed but the script domain is not, both objects are allowed (there is no blocked objects menu) but the content is not loaded.

Two issues:

1) The visible size>0 object probably should no be classified as a caching object, it's just an iframe showing content, so should follow the normal rules.
2) The concept of the object being allowed but it's data not, is kind of confusing and misleading (UI lies), it would be better, if in the above scenario, the caching object remained blocked and in the blocked objects menu, and the menu didn't indicate a non existent blocked script

[al_9x]

UI lies

it shows a blocked script and no blocked objects, but it's not a script, it's an object that remains effectively blocked.

[al_9x]

Looks like rc6 takes care of 1) and 2).

A question popped into my head, could an allowed caching object be repurposed/mutated through scripting, thereby bypassing normal object blocking? Looks like the answer is no, changing it's type to flash blocks it, how does that work? Are there any other tricks that could be played on an allowed object?

About the hotmail caching object dependency, it seems they may be doing something significant in the caching object's onload or onerror, neither of which fire when blocked.

[Giorgio Maone]

Looks like rc6 takes care of 1) and 2).

A question popped into my head, could an allowed caching object be repurposed/mutated through scripting, thereby bypassing normal object blocking?

Looks like the answer is no, changing it's type to flash blocks it, how does that work?[/quote]
Whenever either type or data (src, in embed and iframe element) is changed, a new ContentPolicy.shouldLoad() call is issued, where NoScript can reevaluate its decisions and block as needed.