heads up: Luminous: JavaScript events blocker

[atomGit]

thought somebody would have noticed this by now, but i guess not :)

dunno if this is of any use to you guys, but it looks interesting...

Luminous: JavaScript events blocker

Luminous - github

[atomGit]

hopefully it will not clash with uBO, uM, Decentraleyes, etc

it looks like it's actually designed to essentially accentuate those, not interfere

[GitCurious]

This looks like a potentially very important addon for extra privacy, or at least preventing websites from gathering data that is wholly unecessary for the actual functioning of the site...

if I`m understanding it correctly ?

I have no clue unfortunately which JS functions can and can not be disabled globally.

[atomGit]

i'm in much the same boat - that's the problem with these types of add-ons; they could be useful to us uneducated pee-ons who want to reduce the threats to our privacy, but most of us aren't going to know what the hell to do with the thing :) same with the WebAPI extension thingy - it's a nice add-on, but i don't understand many of its options and it just became a hassle for me - yet another layer in addition to uBlock, uMatrix, etc., that i had to deal with when trying to figure out what was responsible for breaking something

[Atavic]

handleEvent is a JS object that passes an HTML event to the appropriate handler for this function. Some handleEvent examples are onload, onclick, onclose...
https://www.w3schools.com/js/js_events.asp

addEventListener is a method to call JS objects when an EventTarget is triggered.
http://www.findmeat.org/tutorials/javascript/x947393.htm

HTML events are caused by the user who clicks on images or closes windows without knowing what handles that action or what target is instantiated next... is it the popunder window that steals the focus of your cursor or the ad page loaded after you close a page?

👍 @gbaptista extension for greatly empowering possible webfiltering options, as we had only options like this that works on all sites.

A very minor issue:

Não interceptamos codigos inline ()

Inline JS objects aren't filtered yet.

[gbaptista]

Hi! Nice discussion going on here!

Some thoughts:

it looks like it's actually designed to essentially accentuate those, not interfere

This is exactly the idea, to accentuate, not to replace or interfere.

that's the problem with these types of add-ons; they could be useful to us uneducated pee-ons who want to reduce the threats to our privacy, but most of us aren't going to know what the hell to do with the thing

This is a very important point and a current concern. I believe that creating two user interfaces could help with this: An advanced one (same as the current) and another simplified/for dummies. Example:

Advanced:

• Block mousemove handleEvent calls.
• Block mouseover handleEvent calls.
• Block onblur addEventListener calls.

Simplified:

• Stop watching my mouse move:
  • This is used to create heat maps (read more).
• Stop watching everything I type:
  • This can be used to steal your email (read more).

I'd love to hear your thoughts about. If you need some help to understand something or do some experimenting, I could help!

[atomGit]

This is a very important point and a current concern. I believe that creating two user interfaces could help with this: An advanced one (same as the current) and another simplified/for dummies.

did somebody ping me? LOL

but yeah, 2 UIs might be a good idea

This is exactly the idea, to accentuate, not to replace or interfere.

why not replace? you implemented blocking, so let's take NoScript for example - couldn't Luminous essentially replace NS? it can't replace uMatrix obviously, but even in that case, what would happen if one white-listed JS globally in uM and then rained it back in again with Luminous?

my personal issue ... shutup Pants ... is having too many layers - when stuff breaks, i have uBO, uM, Load From Cache, Local CDN, Skip Redirect, etc. to fiddle with (most of the time i know where to start looking, but not always) and so i dislike the idea of adding yet another layer - so Luminous isn't an optimal solution for me personally with my config, but IF it can replace something like NS, then maybe others would be more willing to try it and control JS on a more granular level than just block/allow

[GitCurious]

I would find a short, plain language description of each function useful.

Whether in a pop up balloon/bubble or optionally shown underneath each cell to describe exactly what each item does.

Whether disabling an option is likely to break a lot of sites....or not.

For example, I just searched online for "mouseout" event and now I basically know what it does, I don't know if it`s necessary for most websites or if it MAY break some other sites...and whether I really should leave it alone....

..or, maybe it`s useless and will never really break anything !

To know this information would be useful for the end user who does not understand or use programming languages and therefore does not know what functions are "needed", "good", "bad" or "uneccessary".

I could spend hours or days blindly testing each individual option on multiple sites - but that`s not likely to happen ;)

Question 1: How do I block an item for all sites ?
Question 2: Where are settings stored ?

Suggestion: Implement a "Reset to Default Settings" option

[Atavic]

How do I block an item for all sites?

2415b: limit events that can cause a popup

Luminous looks into the code of the single visited pages and reads the JS Events, see the GUI.

[gbaptista]

@atomGit:

why not replace? you implemented blocking, so let's take NoScript for example - couldn't Luminous essentially replace NS?

NoScript, ScriptSafe, and others are well-advanced and consolidated projects and would be a big challenge to do something with the quality they have. There is a big gap in JavaScript granular blocking today and because of this there is a lot of work to be done and lessons to be learned that will probably take a lot of time. But yeah, this is something that could happen in the future, but I do not think it will happen in a short time.

is having too many layers - when stuff breaks...

I know that feeling, this can be really annoying! haha

then maybe others would be more willing to try it and control JS on a more granular level than just block/allow

I totally agree.

@Thorin-Oakenpants:

which would use most of this stuff, that a "for dummies" one would be ineffectual

This makes sense, it's a major concern. Thanks for sharing the Privacy Settings Breakage Study, it is amazing, helped me a lot to have better insights.

This is why it is important for extensions to indicate via badges that have blocked

True! This is a challenge in Luminous, since blocking at the granular level requires interception, which can also break something in some cases. I started with the idea of first see what is happening, only after that do the blocking. So the badge currently shows what was allowed, not blocked. I honestly do not know what the best approach in this case, what I did today was to create options for each one to be able to choose what they want to see:

This is actually a bit confusing yet, I need to think how to explain it better.

@GitCurious:

I would find a short, plain language description of each function useful.

This really could help!

what functions are "needed", "good", "bad" or "uneccessary".

I loved the idea.

Question 1: How do I block an item for all sites ?

it is not possible yet, more people raised this question (like gbaptista/luminous#18), I believe it is something very important, I am working on it!

Question 2: Where are settings stored ?

Disabled site settings and blocked codes are stored with storage.sync.

Data about everything that has been executed and blocked on each tab is stored with storage.local.

Suggestion: Implement a "Reset to Default Settings" option

Would be helpful, nice suggestion!

[gbaptista]

Oh, I forgot to answer that:

what would happen if one white-listed JS globally in uM and then rained it back in again with Luminous?

Luminous acts as a final layer looking only at what survived the other blockers and was able to run, anything that has been prevented from running by any other tool will never be executed by any Luminous rule. So if Umatrix blocked something, it will never run regardless of whether Luminous is installed or not.

By default everything is allowed on Luminous, but if something is in the Umatrix whitelist and blocked at Luminous or the opposite, it will not run. You will need to put in the whitelist of the two tools to be able to run. Yeah, more tools = more work, more configurations, more time spent, not the best solution.