InformAction Forums

In Options -> Embeddings I forbid any objects via Noscript. In order to tighten security I've added the following rule suggested by Giorgio to ABE -> USER:
I went to http://tools.boerse-go.de/index-tool/ which I've whitelisted in Noscript but for which I did NOT create an exception rule in ABE. But the Java applet on that site is still loaded! How is that possible?

Another example: If I go to http://blog.mozilla.com/blog/2011/03/ there is this message in the Error Console:

[ABE] <*> Deny INCLUSION(OBJ, SUBDOC) on {GET http://www.youtube.com/watch?v=mv_sq5zpN0M <<< http://blog.mozilla.com/blog/2011/03/, http://blog.mozilla.com/blog/2011/03/ - 5}
USER rule:
Site *
Deny INCLUSION(OBJ, SUBDOC)

.. but I can view the video on that site although no exception rule for mozilla.com exists in ABE. I might have a basic misunderstanding how ABE works ...

The video on http://blog.mozilla.com/blog/2011/03/ has a non-Flash fallback, through the HTML 5 <video> element which is currently not covered by the inclusion subtypes dictionary.
In fact, if you use just "INCLUSION" (with no further specification) it does get blocked as expected.
Both <video> and <audio> HTML 5 media elements will be matched by OBJ in next version.

Regarding the Java applet, it seems a genuine regression, probably due to recent changes in the Java plugin or its inter-process wrapper: HTTP observers (like ABE) don't get called for Java requests. Fortunately, as you noticed, content policies (like NoScript) do get called so this doesn't affect NoScript's ability to block Java, but ABE's INCLUSION doesn't affect Java requests because they're not seen at all. I'm trying to implement a work-around to be included in next version, thank you for reporting this.

Fixed in latest development build, thank you.

The latest build works indeed as expected. Thanks a lot, Giorgio!

Giorgio Maone wrote:Both <video> and <audio> HTML 5 media elements will be matched by OBJ in next version.

Hm… Is this really the expected behaviour? Since these are not "plugin objects" (term used in the ABE specification) but are only like what plugins are generally used for, ie. plugin object lookalikes/alternatives/….
But plugins might be also used for displaying images, so using this same argumentation you might also match native IMG elements with this rule which I believe is not what users would generally want (at most maybe as a separate type matcher).
So either change this or update the specification reflecting that OBJ does not just stand for "plugin objects".

Mmm, I'm probably going to add MEDIA and FONT subtypes, rather than coalescing them with OBJ and OTHER respectively.

Giorgio, another thought. One big disadvantage of blocking objects by the mentioned ABE rule is that the usual placeholders are not visible. Is this generally impossible in ABE or isn't it just not implemented? If the latter is the issue, implementing this would be highly appreciated as it would make life a lot easier

tlu wrote:Is this generally impossible in ABE or isn't it just not implemented? If the latter is the issue, implementing this would be highly appreciated as it would make life a lot easier

ABE is designed and implemented to be as decoupled as possible from NoScript and the DOM. Triggering placeholders from it would be quite complicated and would violate this decoupling.

Giorgio Maone wrote:

tlu wrote:Is this generally impossible in ABE or isn't it just not implemented? If the latter is the issue, implementing this would be highly appreciated as it would make life a lot easier

ABE is designed and implemented to be as decoupled as possible from NoScript and the DOM. Triggering placeholders from it would be quite complicated and would violate this decoupling.

Okay, undestood. So we're patiently waiting for E10