Blocking of stylesheets is silent, confusing

[lxoliva]

If you visit http://verdi.softwarelivre.org/papers_n ... /fast_grid all you get is what appears to be unformatted random words. It was supposed to be the schedule for a big Free Software conference.

NoScript doesn' t report at all that it is blocking the stylesheet where all the code that would turn the unformatted xml into useful and good-looking elements for the browser to display. This is confusing because in every other case of NoScript blocking I'd seen before it said it was blocking something at the bottom of the page, and it was easy to figure out that, if I was missing some functionality, I'd have to unblock something. It puzzled me further that I tried it on IceWeasel (3.5.3-2.2, as in gNewSense 3.0-pre for mipsel) and Firefox (firefox-3.5.10-1.fc12, as in Freed-ora 12 for x86_64), both with NoScript 1.9.9.99, and other browsers (links, Konqueror, epiphany), and the page always displayed the same garbled content; since I didn't have NoScript on the other browsers (AFAIK), it didn't occur to me that it could even be related, and I still don't fully understand why the page didn't display properly on any of them.

Today, it finally occurred to me that it might NoScript be and, indeed, unblocking the page brought in all the niceties that I didn't even know to expect.

Can you please arrange for the regular notification that reports blocking to be displayed when stylesheets are blocked?

Thanks in advance for this fix, and thanks for this great piece of software! Keep up the great work!

[Giorgio Maone]

XSLT document are treated as scripts because they're Turing-complete and already allowed attacks in the past, including scriptless heap spray techniques.
You're correct about XSLT blocking being under-reported, especially if there are no other scripts in the page.
I'll try to correct this in next release, by counting blocked XSLT documents in the <SCRIPT> count.

[Thomas Leske]

I just have hit the same issue with NoScript 2.2.

Isn't there a bug tracker?

[Giorgio Maone]

I just have hit the same issue with NoScript 2.2.

Isn't there a bug tracker?

We use this forum as a "tracker". Website and steps to reproduce?

[Thomas Leske]

If you load
http://fdroid.ssvadmin.alfahosting.org/repo/index.xml
with NoScript enabled for the site, then the page will silently render with the default xslt transformation instead of the of transformation that I have linked from the index.xml file (repo.xsl).

After disabling NoScript for the site my style sheet renders correctly.

(index.xml does not link to any other external files and does not use java script.)

[Giorgio Maone]

After disabling NoScript for the site my style sheet renders correctly.

This is the intended behavior.

[Thomas Leske]

Blocking the XSLT script is not a bug. But doing so silently is.

NoScripts reports blocking JavaScript, though an HTML author can tell the user that the site requires JavaScript.

However as a XML-Author I have no reasonable way to tell the user that the file is meant to be rendered by a different style sheet. And how can a user guess that NoScript is responsible, when he expects NoScript to report blocked content.

[Tom T.]

... However as a XML-Author I have no reasonable way to tell the user that the file is meant to be rendered by a different style sheet. And how can a user guess that NoScript is responsible, when he expects NoScript to report blocked content.

You're correct about XSLT blocking being under-reported, especially if there are no other scripts in the page.
I'll try to correct this in next release, by counting blocked XSLT documents in the <SCRIPT> count.

I *think* that what the two users are asking for is that blocked XSLT documents show up in the NS Menu, with Allow/Temporarily Allow commands available. And if indeed XSLT looks like a duck (script), walks like a script, and quacks like a script, then it seems very reasonable to treat it as one, and so list it in the menu. Then the confused user sees immediately what is necessary for the page to render properly, and knows the source of it, for a "trust" decision.

ETA: Or as "blocked objects", if that's easier to implement, though it requires a second action by the user, and isn't as obvious in the immediate NS menu.

Can you do this, Giorgio?