is this meant to be a blocker?

[jawz101]

It doesn't seem to have an easy way to set a default-deny policy and no way to view saved blocks. No way to edit a site's rules without visiting the page, nor a reset button.

[Atavic]

Is this meant to be a blocker?

Yes.

It is different from - let's say - uMatrix: it uses jquery library to counteract JS Events.

As triggered and attached events may vary, instead of rules you have a grid where you see what happens in JS code.

[jawz101]

So I cannot necessarily set deny rules that apply to all sites? It just seems like it wouldn't really offer protection if it allows things to occur at least once. For example, if there was a way to block mouseup events from firing on all sites then it would be useful. As is, every site can do what they want until I block and reload the web page and at that point the damage is done.

[Atavic]

Whne it is active, it blocks the events that appear on page. Predetermined rules do not apply here, as this tool reads the JS Objects an provides an interactiv GUI to inspect and enable them.

[gbaptista]

@jawz101 This is a great point. As @Atavic said, you can block some code after it is identified in the popup. Once blocked, when reloading the page, it will not run again.

Version 0.0.7 includes considerable improvements, you can better see and understand what was saved on the settings page (see #25).

It's still not possible to define a default-deny policy or to edit in an advanced way what has already been blocked. I believe that such features are very important and I will have news soon about this.

Thank you for opening the issue and raising these questions!

[jawz101]

Thank you both for the response. I figured it had to be asked and I'm glad you all are thinking about it :)

[gbaptista]

@jawz101 Update: It is now possible to set default-deny policy. Feature is available in version 0.0.10. See Introducing Default Rules #32 for more details.

If you have any questions or suggestions about it, let me know! :)

[jawz101]

Would it be possible to collect additional events based on what has been recognized from visited websites? That is, if I visit github.com and addEventListener facebox:afterClose was recognized but it's not listed on the Default Rule page, it would go ahead and prepopulate it with a default of allow. Then I can globally deny it if I choose to do so.

That way events don't need to be predefined and users don't have to enter a bunch of new entries. I don't know if that makes sense:/ Like, the default rule could also collect potential rules from your visited websites.

[jawz101]

... also, I'm not a fan of the website rules tab automatically throwing an entry in simply by visiting a web page. Should only be if I make a custom rule.

[gbaptista]

@jawz101:

not a fan of the website rules tab automatically throwing an entry in simply by visiting a web page

Trying here during a day of navigation, I also did not like the result...

Would it be possible to collect additional events based on what has been recognized from...

Yes, I believe it is possible. I have the idea of allowing the choice of what should be created automatically, see: Automatic Settings Options #39.

Why all events and common events? Well, if we're going to really add any detected event, we can have endless of them... YouTube, for example, has more than 70 yt- events:

yt-action yt-add-element-to-app yt-autonav-pause-blur yt-autonav-pause-focus
yt-autonav-pause-guide-closed yt-autonav-pause-guide-opened yt-autonav-pause-player
yt-autonav-pause-player-ended yt-autonav-pause-scroll yt-autoplay-on-changed
yt-close-tou-form yt-consent-bump-display-changed yt-focus-searchbox
yt-get-context-provider yt-guide-close yt-guide-hover yt-guide-toggle
yt-history-load yt-history-pop yt-load-invalidation-continuation
yt-load-next-continuation yt-load-reload-continuation yt-load-tou-form
yt-masthead-height-changed yt-navigate yt-navigate-cache yt-navigate-error
yt-navigate-finish yt-navigate-redirect yt-navigate-set-page-offset
yt-navigate-start yt-next-continuation-data-updated yt-open-hotkey-dialog
yt-open-tou-form-loading-state yt-page-data-fetched yt-page-data-updated
yt-page-data-will-update yt-page-manager-navigate-start yt-page-navigate-start
yt-page-type-changed yt-player-attached yt-player-detached yt-player-released
yt-player-requested yt-player-updated yt-popup-canceled yt-popup-closed
yt-popup-opened yt-preconnect-urls yt-register-action yt-report-form-closed
yt-report-form-opened yt-request-panel-mode-change yt-retrieve-location
yt-service-request-completed yt-service-request-error yt-service-request-sent
yt-set-theater-mode-enabled yt-show-survey yt-subscription-changed
yt-swatch-changed yt-theater-mode-allowed yt-unregister-action yt-update-title
yt-update-unseen-notification-count yt-viewport-scanned yt-visibility-refresh

So, common events try to identify only "common events" (excluding random internal crazy events like yt-).

Thoughts?

[jawz101]

I noticed that with YouTube as well. Today I was trying to pick apart what to allow on a YouTube page manually and it was crazy how many events they make for themselves.

Hm... Maybe it may not be a great idea. I really don't know anything about the concepts behind javascripts to have a productive ideas :/

The only thing I can think of is

a) going ahead and collecting them. Just because they were unique shouldn't make a big difference unless having a bunch affects performance.
b) collect them and track their usage. Have a cleanup button or something to remove any that aren't used on more than one site.
c) Keep it the way it is. A user can manually add events themselves as global default rules.
d) have a button next to events that are collected on the per-site listing. A user can opt to promote site-collected event to be a global event rule.

Do any of those sound appealing?

This is a very interesting add-on. As an aside, have you taken a look at Web API Manager?
https://github.com/snyderp/web-api-manager

You and @snyderp & @Gitoffthelawn, @Thorin-Oakenpants, @gorhill, @andryou, @cooperq, @ghostwords, @cowlicks, @Synzvato, @diegocr might enjoy a conversation. I'm surprised I haven't seen any of them commenting on here yet :)

edit: added more superstars to the list :)

[Gitoffthelawn]

@jawz101 I'm overbooked, but I'll add this to my "to read" list! :) 👍

[jawz101]

The first approach I hope a lot of these sorts of privacy/web technology extensions do is start as a logger. As @Thorin_Oakenpants mentioned, something that can analyze top 500-100 Alexa sites, collect site names, performance metrics, and techniques used, output a flat file and maybe a few pretty graphs to try to answer "this is the state of the web today." Then the next person can determine if new techniques can be implemented to block certain things, browser developers can focus on tuning the browser to address performance hits, or deprecate unpopular techniques or privacy-problems.

Of the extension toolbag this one is the most over my head but I could see approaching it from a logging and analysis engine would reveal actual concerns. Me using this is like "block block block. Whee! Ok why is this button not clicketing?"

TLDR; it's doing something fancy but a tool that logs and makes pretty graphs are probably most beneficial for this sort of tool than launching head first into making it a blocker. Just my thoughts.

[GitCurious]

I feel like I need to block them ALL - but that ends in tears & swearing :)

I can`t seem to find any online resources which make any suggestions which items are unecessary or even purely tracking related that can be blocked globally without worry - the descriptions that I find mean nothing to me so after hitting a brick wall I disabled the addon temporarily.

[jawz101]

Yeah I continue uninstalling it too. Analysis of Top Sites and then use it to base some sort of heuristic blocking but today it gives you with more questions than what to do with it.

[ghostwords]

#41 makes me think of a personal version of https://www.chromestatus.com/metrics/feature/popularity

[jawz101]

The past update is great. @gbaptista you are very talented! That is a great reference. Thanks for mentioning @ghostwords

[gbaptista]

@jawz101:
I did not know the @snyderp project. It's amazing and has incredible code architecture and quality. He went deep in the studies and created an extremely useful reference. Thanks for sharing!

Do any of those sound appealing?

I've created options for each one to choose what they want to create automatically. I believe that in this way we can try to find out what works best. (see Automatic Settings Options #39)

@jawz101 @Thorin-Oakenpants:

collect them and track their usage

I could see approaching it from a logging and analysis engine would reveal actual concerns...

do some sort of analysis on JS events use...

This is an awesome idea, based on it I created a first experiment attempt:

• Reports Guide
• Reports Reports #41
• Reports Filter and Translations Reports Filter and Translations #43

@GitCurious:

I can`t seem to find any online resources which make any suggestions which items are unecessary or even purely tracking related

I believe this is one of the biggest challenges. I'm trying to write small guides that I believe can help in that sense, it's pretty rough yet, but it can be a way:

• mousemove
• Google

@ghostwords:
Very interesting, thanks for sharing!

Overall:

Many great ideas popping up here and lots of relevant discussions. Thanks for everyone's participation!

I will try to organize new discussions on specific topics raised here so that I can delve into them and make them visible to everyone.

[peterwx]

uBlock Origin can block (some?) events, blocking eventlisteners by scriptlet injection. Mentioning it because no previous reference to it seems to have been made.

[jawz101]

At most uBO would block a javascript altogether but it wouldn't block a specific action within a script. If uBlock can get more surgical than DNS blocking, Luminous would be that much more precise.

Example:
pi-Hole could block adserver.com
uBlock Origin could specifically block scripts on adserver.com or even adserver.com/view/adDisplay.js

Luminous could actually go in that
adDisplay.js and block just, say, that script's ability to listen to your mouse movements or keyboard presses if that is something the script did.

It's just something that takes it a step further. I've played with this extension every now and then but it feels more practical to maybe first use it as a research tool. You could open up 1,000 sites and see what sorts of javascript commands are more prevalent in tracking scripts versus non-tracking scripts and try to come up with some sort of heuristic block instead of traditional blocklists. Or try to control javascript commands that hurt performance. Junk like that

[peterwx]

That uBO can block events(created by addEventListener), i am certain of (although not within a script as stated in your post right?).
Just realised that both extensions are only capable of blocking events of a specific type at the global page level not on specific elements. As for Luminous the event blocking ability applies automatically to all scripts and without user control right?

[jawz101]

Unless I am mistaken, in uBlock you can have a rule to block a particular script but you can't specifically allow everything within a particular script to run except for "this one type of code". Right?

Luminous can to per-domain blocking rules as well as global rules.

[peterwx]

I think you're right. I'm more familiar with uBO than Luminous. I interpreted your comment on uBO being about blocking a particular script by name/path or text/code that it contains.

One of the first things i used Luminous for was disabling infinite scrolling on reddit by blocking the scroll event(of which there were 2 types listed).

Blocking one has the intended effect, doing it to the other disables scrolling on the page.
The loading of more posts is triggered by scroll on last post. Scroll is also used to reorder the existing posts in the view.

One could achieve the same effect by blocking the specific XHR request.
It would make it easier if there was a way of blocking an event on a specific DOM element origin.

Also there is this interesting bookmarklet VisualEvent for visualizing events. Perhaps Luminous in the future could have something like this?
I'm not making feature requests. This thread is about the nature of what the Luminous extension blocks by default and although a main use case seems to be about blocking API's for tracking/performance it could also be about blocking for customization/usability.

[gorhill]

blocking the scroll event

Just for technical accuracy, you likely could accomplish the same in uBO using addEventListener-defuser scriptlet.

[peterwx]

I know. I realized the capability existed in uBO and tested the defuser some time after testing that same capability in Luminous.