You may be remember me saying that javascript was still working in some sites after disabling javascript, and it was so annoying.

The other day I spent a little of time because I had a suspect and I found that this happens when the site creates even listeners (and it is getting popular as more dynamic pages are comming).

Even listeners are javascript commands attached to elements "on the fly", this is, that aren't created for elements with the attribute onclick/onload/onmouseover/...

Here you have an html page where you can test, that I did for my own tests, when you click on the text.

If you load the page with javascript disabled, nothing works. Obviously

If you load the page with javascript enabled you'll have two alerts.

If you load the page with javascript enabled and disable it after load, you'll have only the even listener alert, that, regardless of javascript settings, isn't being blocked.

See the code and you'll understand.

I find happening this to the newer Gecko engines, "starting" with our GRE24 in K-meleon 24 (I don't know if earlier) and Firefox as well as other Mozilla releases.

This didn't happen in our earlier 1.6 (sorry, Siria, you won't be able to test )

I found this annoying and a security flaw as some javascript, combined with XML, aka AJAX, could monitor as in a website (yeah, yeah, and other Mozilla products, but who cares them ).

And it is funny because, as you may remember in the development thread for 74GRE31, Dorian told that Mozilla introduced a block of Javascript, but looks they forgot an essential Javascript to block... And, in fact, in Firefox 31 it gets worst, as doesn't block on or other way...

I didn't find this in the bug tracker of Mozilla, but if you have an account, can you post it as a bug? Maybe I'd post by myself, but, Dorian, I guess you have an account there, so, if you can, post it

At least, test it by yourselves to confirm I'm not the only one, even I confirmed myself.

Note: I post this as off-topic as I don't consider related or to discuss with K-meleon, as it is a GRE issue bug. Move if you consider it is the wrong place.



Edited 3 time(s). Last edit at 11/24/2014 09:33PM by JohnHell.

The prob is that nearly no one is reading here in the offtopic section. It's for "All which isn't K-Meleon related", like seasons greetings, freeware tips etc.
That bug may not be "caused" by KM, but it still happens when it is "used" and it's dangerous, so of course I consider it "related".

Oh well. Can't remember if Dorian mentioned Mozilla had introduced new JS blocks. But I do remember very well that they removed the checkbox in the pref sheets to switch it off. And do remember very well, that in 74g31 javascript still works fully when a page was (accidentally) loaded with it, and JS only blocked afterwards. So wouldn't be surprised at all if this "bug" were intentional too :cool:

PS: if you do window.stop(), does that stop this thing?
In KM1.6 that does neat things like stopping meta-refresh or wild animations ;-)
PS2: am now quite happy being stuck with good-old 1.6, LOL!



Edited 1 time(s). Last edit at 11/24/2014 09:47PM by siria.

Quote
siria
That bug may not be "caused" by KM, but it still happens when it is "used" and it's dangerous, so of course I consider it "related".

I assume that the bug is inherited from Firefox which acts the same. Probably all Firefox based browsers (maybe Chrome too?) will act the same.
Opera Presto doesn't have this bug.

Correct me please if I'm wrong but I wouldn't consider this bug to represent much of a threat.
Once you have loaded nasty scripts from a site, disabling JS for the same site won't help anymore. The damage was already done.
However, you still can disable JS for it by refreshing the site.

@Siria:

http://www.w3schools.com/jsref/met_win_stop.asp

That only prevents the load of a window, doesn't prevent the run of scripts

Quote
Yogi

Quote
siria
That bug may not be "caused" by KM, but it still happens when it is "used" and it's dangerous, so of course I consider it "related".

I assume that the bug is inherited from Firefox which acts the same. Probably all Firefox based browsers (maybe Chrome too?) will act the same.
Opera Presto doesn't have this bug.

Correct me please if I'm wrong but I wouldn't consider this bug to represent much of a threat.
Once you have loaded nasty scripts from a site, disabling JS for the same site won't help anymore. The damage was already done.
However, you still can disable JS for it by refreshing the site.

It is a threat as functions already loaded can be called and executed with the remaining active script calls after javascript disabled: the event calls.

So, you can run code without knowledge of user, simple as catching mouse movements.

Yes, you can reload with javascript disabled, but that "doesn't fix" the problem.

Quote
JohnHell

It is a threat as functions already loaded can be called and executed with the remaining active script calls after javascript disabled: the event calls.

So, you can run code without knowledge of user, simple as catching mouse movements.

Yes, you can reload with javascript disabled, but that "doesn't fix" the problem.

If one was to clear the cache, disable javascript, and then reload the page prior to clicking on anything, would that help?

Quote
JohnHell
http://www.w3schools.com/jsref/met_win_stop.asp
That only prevents the load of a window, doesn't prevent the run of scripts

That much for theory :cool:
Still my experience is that it does stop some things long after a page has finished loading. No idea what exactly and what not, but am using it regularly to stop meta-refreshs (reloads defined in the page header), and it also stops gif animations. Wouldn't be surprised if it also kills timed scripts like this thing here, rather surprised if not, but you'll only know after a little test.

(And if it weren't for this gecko bug since 1.6 that browser commands (buttons, accels) don't seem to get through while scripts are running, it could perhaps stop those too, but not sure)

Quote
JamesD

Quote
JohnHell

It is a threat as functions already loaded can be called and executed with the remaining active script calls after javascript disabled: the event calls.

So, you can run code without knowledge of user, simple as catching mouse movements.

Yes, you can reload with javascript disabled, but that "doesn't fix" the problem.

If one was to clear the cache, disable javascript, and then reload the page prior to clicking on anything, would that help?

I don't understand your reply, or you didn't understand mine.

I meant that if you have to reload with javascript disabled, what kind of fix is that?

By "doesn't fix" I meant that the bug still exists you only go around it by loading the page without javascript


@Siria, no, it doesn't do that, in fact, since the beginnings of my use of K-meleon (one my first posts at this forum) I asked for a way to stop GIFs and, since then, I use this for the VK_ESCAPE key:

ESC_stop{
id(ID_NAV_STOP);

$JSdoit="stop();";

&hndlDocs;
}

Note: JS_hndlDocs instead hndlDocs and JS_doit instead JSdoit for newer versions, as I was using this from the beginning of K-meleon

That macro stops the page load with id(ID_NAV_STOP) and any GIF animation and PNG animations with stop(), the short form of window.stop().

So, long story short, no, doesn't stop scripts as it is easy for me to test it, as the function belongs to the escape key in my config.



Edited 2 time(s). Last edit at 11/25/2014 07:04PM by JohnHell.

Okay, thanks! Nothing like a little test to clear things up, was worth trying.

And am glad you figured out the solution with the second popup-pref, and even already delivered an easy fix for it! Great job!

But the popup is not related to this, just to clear it.

Is just something annoying I was having this long afternoon browsing and I'm suffering since long time ago, to be fair. And today I said, no more. A quick search gave that pref, I tested and I told to the thread to implement by Dorian, if possible.

But I found a little problem with that block. The buttons that open to browse a local file now are commanded by an onclick almost on any site and you have to toggle the popup blocker because with that string the preference block the click event and the system explorer "popup" window :/

It's not a big deal, but if implemented by Dorian someone might complain

I'll edit and post in the 75b1 thread to warn.

EDIT 2014-11-27: looks like it's not javascript only. Look like GRE considers and event click to open a windows explorer window to browse for files...



Edited 2 time(s). Last edit at 11/27/2014 05:34PM by JohnHell.

Update 2015-01-03:

They suggested me to report after they checked in the support forum, so I'll report as bug.

And a note I want to add, K-meleon 75, this is GRE 31 DOESN'T BLOCK ANY JAVASCRIPT EXECUTION after toggle the preference.

Test in the same page I posted with any version of K-meleon (and, therefore GRE version) and you'll see:

http://www.geocities.ws/jothache/event_listener.html

Even AJAX works, send to and receive data from the server:
http://www.w3schools.com/xml/xml_http.asp

Quite a huge security issue.

I filled the bug yesterday night:
https://bugzilla.mozilla.org/show_bug.cgi?id=1122310

They marked today as duplicate of this one that it is open since April 2014:
https://bugzilla.mozilla.org/show_bug.cgi?id=998456

And reading the comments, looks like it isn't to be fixed soon. Are the same type of comments I received in the support pages (link in my bug), that they recommend to use external add-ons such noscript for a feature that was available ever on Firefox.

As a workaround they recomend to run in the console the command "gBrowser.docShell.allowJavascript = false" what is funny as hell.

At least I placed my vote for a fix :/

Let's hope they fix with the 31 ESR branch and therefore could be included in K-meleon 75.



Edited 1 time(s). Last edit at 01/16/2015 04:58PM by JohnHell.

Sorry, but knowing google, the hope is zero: am convinced the removal is fully intentional :-(

First they removed the user setting for javascript from the Firefox Settings Tabs with ridiculous excuses, despite protests, while claiming that expert users would still be able to block JS in about:config!

And now the next step is only logical, even the hidden pref is disabled completely.

In the same line, the CAPS exceptions were recently abolished, in order that users have no chance anymore to set domain exceptions for javascript etc. All doors for spyware and malware must always remain WIDE open. And if the corporate users had not protested so loudly, it would also have stayed impossible to inject scripts from the local disk at all, without exceptions.

The same philosophy BTW in Android, regarding app permissions.
In earlier android versions, when installing a new app, the permissions were shown in detail. Meanwhile google has changed the system in a way that new app permissions are shown only fuzzy, group related, not detailed, and once an app is installed now, it's automatically allowed to secretly grab yet more permissions any time, simply by updating its version. Again, the doors for spyware and malware must stay WIDE open.

And Google really does everything to FORCE users to have their trojan apps running at android startup, and to prevent any tools that would allow users to block some startup apps, or would allow them to set single permissions for their apps. Half of which obviously unnecessary and very private. In android any permission manager apps can only work if they are already built into the firmware by the manufacturer. User-installed apps cannot prevent the google apps and other spyware from starting. The only chance for a phone owner to control permissions would be to "root" his phone, which is first highly complicated and second destroys the warranty. But of course, the doors for spyware and malware must stay WIDE open.

Next step, in android4.3 a hidden permission manager created by google itself was found by someone, and clever programmers created apps to make it accessible to normal users. It was first assumed to be half-finished only and it would be fully implemented in the next version, but google declared it was never intended to be revealed to users, of course they had hidden it fully intentionally. And as expected in android4.4 they tried to hide it even deeper in the system, and people first thought it was removed completely. Am not sure how fully third party apps can still (ab)use that new version now. Makes one really wonder for which purposes google hides an app permission manager deep in the system, which is meant for their own remote use only, and strictly hidden from users... Again, the doors must...

And the most insidious thing which really got me triple MAD, google could even FORBID foreign phone manufacturers to include other permission managers in the firmware!! At least for outside-china phones. Hua-wei for example did have a great own permission app build into their firmware, which silently vanished some day, and when people complained they explained that google had forced them to remove it. They can do it with license tricks, despite open-source, grrr. But perhaps this time they went too far and may get trouble for monopolism, there was some rumour about it, and meanwhile Hu-awei is daring to include its own permission manager again in new firmwares.

And of course, google does also everything to abolish SD-cards in phones, forcing users to upload as much of their private stuff as possible to web servers. Where of course it's much easer accessible for spying out. There were huge problems everwhere because of this, but so far didn't help. From (german) wikipedia history:
Since a4.4.0 google had forbidden user apps to write onto the SC-card into any places other than their own folders. Which made it impossible for example to edit some text file anywhere on the card with an editor app.
In a4.4.2 next step: now google has user apps completely forbidden to write anything to the SD-card at all! Only firmware apps (like spying google and FB apps etc) can still do everything they want on the card. Google Law§1, the doors for spyware and malware must stay WIDE open, and user rights must stay as restricted as any possible.
To hide those new insidious card tricks a bit longer from clueless users, the system still shows a fake path to the sd-card, when a user moves an app there etc. While in reality those paths are secretly redirected to the internal storage, which fills up quickly.
I find it really funny that the english wikipedia doesn't even mention the SD-card/server stuff in the android history (no more?), alongside all the other tiny little history details! The above stuff is from the german wikipedia. Have also seen complaints in various forums too, there ARE huge problems due to the missing sd-card permissions.

Sorry, had to vent!! Expecting google to "fix" a javascript blocker, when breaking it fits so perfectly to their philosophy, ha ha...
In the contrary, google's only goal is to restrict user rights to nearly zero.

Quote
JohnHell

As a workaround they recomend to run in the console the command "gBrowser.docShell.allowJavascript = false" what is funny as hell.

I can make a new command from this. Something like pageEnableJS / pageDisableJS
EDIT: I could also do it globally if needed



Edited 1 time(s). Last edit at 01/16/2015 11:25PM by Dorian.

@Dorian, that would be really great. Both options would be great. Just awesome.

As I couldn't input that command in Firefox (the consoles don't let it :-?) I thought it couldn't be used.

Quote
siria
Sorry, had to vent!! Expecting google to "fix" a javascript blocker, when breaking it fits so perfectly to their philosophy, ha ha...
In the contrary, google's only goal is to restrict user rights to nearly zero.

Don't worry. I appreciate it because I don't have good eyes for Android and I didn't know these things, what don't make me look it better.

But Google doesn't command Mozilla (with money) anymore. Maybe their engineers don't help either.

But it is not only an Android thing. I have a Nokia with S40 OS and as it wouldn't be enough to be a very poor OS, it restricts a lot. I tried to tame it and I corrupted it . Now I only can restore it with Windows 7 and 2GB of free space, what I don't have right now.

NOTE to the forum: I literally broke my monitor when I was fixing it so I could be some days without log-in or commenting just when I can from another PC. (I'll be unlogged (I don't know my own password (quite hard)))

Bugs! Always bugs!

---

Hey scommetix,

Do You really think that You can post/hide a link to a sports betting side inside Your trivial posts without being detected eventually? guenter



Edited 1 time(s). Last edit at 01/27/2015 07:06AM by guenter.

Quote
Dorian
I can make a new command from this. Something like pageEnableJS / pageDisableJS
EDIT: I could also do it globally if needed

Make it please! This will be very useful option for our really light browser!

Quote
Dorian

I can make a new command from this. Something like pageEnableJS / pageDisableJS
EDIT: I could also do it globally if needed

This would be great!