ABE seems to be broken since the latest release [2.9.5.1]

[Giorgio Maone]

Something very odd I just noticed

What you're seeing is an artifact of NoScript replacing with that URI (which has the actual format of an URI and therefore doesn't break any code expecting an URI) any principal (such as "[System]") which designates a privileged origin. It's the constant BROWSER_URI, which on Seamonkey is, as you noticed, just a placeholder.

[barbaz]

Thanks Giorgio for the explanation.

[johnscript]

Accept from chrome: eventually reduce security?

No it doesn't: you should get that origin only if you initiate the load from the navigation bar or some add-on.

OK, thanks.

There may be yet another side effect of this: if I set up a dedicated profile just for online banking, and after putting in place all the necessary rules for it to work, then end my rules appending this line

Code: Select all

Site .*
Deny

in order to block all other websites , it again breaks everything.
As far as I can tell, that wasn't the case before.

Something like that, to be clear

Code: Select all

Site .mybank.com
Accept ALL from Self++ moz-nullprincipal:
Deny

Site .*
Deny

[barbaz]

First off, the SELF keywords are case-sensitive and in all caps. Also it's best practice to use Site ALL to match all sites. You can use a regex if you want, but you need to include the starting anchor for ABE to recognise it as such. So .* should be written as ^.*


With that out of the way, are you saying that the following ruleset does not work...

Code: Select all

Site .mybank.com
Accept ALL from SELF++ moz-nullprincipal: chrome:
Deny

Site ALL
Deny

... but this does? -

Code: Select all

Site .mybank.com
Accept ALL from SELF++ moz-nullprincipal:
Deny

Please check the Browser Console (Ctrl-Shift-J) when this issue happens and post here any messages related to NoScript.
(related messages usually start with either "[NoScript" or "[ABE]"; if you don't know what's related, turn off CSS warnings and post everything else you see)

[johnscript]

First off, the SELF keywords are case-sensitive and in all caps. Also it's best practice to use Site ALL to match all sites. You can use a regex if you want, but you need to include the starting anchor for ABE to recognise it as such. So .* should be written as ^.*

My bad about the Self instead of SELF, that was a typo : I've checked and I'm actually using the correct one, i.e. SELF in caps.
The expression was actually wrong, as I didn't start with the anchor - I've now fixed that, thanks.

Having said that, looks like something wrong is still happening: using the same sample rules we've used earlier on

Code: Select all

Site .informaction.com
Accept from chrome:
Anon INC (IMAGE,CSS) from SELF .noscript.net  moz-nullprincipal:
Deny INC SUB
Accept from SELF .noscript.net  moz-nullprincipal:
Deny

and then appending one of

Code: Select all

Site ^.*
Deny

or

Code: Select all

Site ALL
Deny

a blocking apparently still occurs if the url is called directly from the address bar using the Firefox url dropdown - I've checked and the same url with the same rules in place will be opened from bookmarks/history.

Even worse, it appears to be not consistent at all: after a few times, everything seems back to normal again and ABE is no longer blocking what it shouldn't have been blocking in the first place - whilst still blocking correctly what it should.

I may be wrong, but that's what it looks like so far : as of now, I don't have any messages from the console to post, I'll try later on.

[barbaz]

a blocking apparently still occurs if the url is called directly from the address bar using the Firefox url dropdown -

What url? "https://forums.informaction.com/"?

[johnscript]

Actually, no : with the aforementioned rules in place, if I add (on a separate line)

Code: Select all

Site ^.*
Deny

or

Code: Select all

Site ALL
Deny

at the end of the ABE rules, everything seems to work as expected, until I try to recall some threads from this board from the URL bar - if for instance I bookmark this very thread, it will of course be stored in the places database and therefore will also appear in the URL bar if I focus it and start typing informaction... .

The interesting bit is that whilst I will have no issues opening it from bookmarks (as Giorgio pointed out earlier on), if I try to open the same link directly from the URL bar it will work in this first form viewtopic.php?f=10&t=22314
but not in this second one viewtopic.php?f=10&t=22314&start=15 - as long as that general Deny rule is in place.

The actual url in the second case will be

viewtopic.php?f=10&t=22314&sid=dd57c8a2 ... 5&start=15

but this form will trim it automatically.

The bookmark I've used as example is actually stored in the library in this longer format that I've posted above, I shortened it by trial and error and noted that once trimmed down to just viewtopic.php?f=10&t=22314 it can be recalled from the URL bar without triggering the general blocking rule

Code: Select all

Site ^.*
Deny

But once the page has been loaded several times one way or the other, this weird issue stops altogether and (without any modification whatsoever to ABE rules) there are no more errors until Firefox is restarted.

Time to test in a clean profile with just NoScript installed, maybe?

[barbaz]

Not seeing that here.

Before trying a clean profile, does it help to add moz-nullprincipal: to the first Accept line?

[johnscript]

Sorry for the late reply: yes, as far as I can see adding moz-nullprincipal: to the first Accept line does solve the issue.

So our "test case" looks like that at the moment:

Code: Select all

Site .informaction.com
Accept from chrome: moz-nullprincipal:
Anon INC (CSS,IMAGE) from SELF moz-nullprincipal:
Deny INC SUB
Accept from SELF moz-nullprincipal:
Deny

with this, that last generic "Site ALL Deny" rule appended at the very end of ABE (USER) rules doesn't seem to break anything.

[anuswara]

I am activating the notification about this bug that affects me too. (2.9.5.3!).

[barbaz]

Per viewtopic.php?f=23&t=22479 it looks like there maybe another effect of this bug - some top-level loads are incorrectly seen as INCLUSION.