Add description in the strict-blocking page

[Yuki2718]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

I found Brave's strict-blocking page (only on Aggressive mode) has a characteristic that uBO should probably follow.

Although it's not necessarily tracking, they explain what had happened. There are only three patterns to trigger strict-blocking:

1. malicious site
2. click-through tracker or advertiser's site
3. false positive

Let's ignore the last case and advertiser's sites as are rare. I believe uBO can and should add explanation of what happened, which is most likely to be either malicious site or tracker - then let user to decide which it is. This partly solves #1195 and is much easier to implement. The current blocking page consists of only facts is too unfriendly to average Joe to whom "EasyList" is just mumbo jumbo. After I started Twitter I occasinally see user get confused by the blocking page; e.g. https://twitter.com/_1__1_/status/1615997416976834565, and this has long been my concern. This suggestion should be a step ahead for uBO to rally be install-and-forget.

A specific URL where the issue occurs.

https://www.profitablegatetocontent.com/e51xmfb9?key=6cf0bf53774e52ec9e3ca94803f48b06

Steps to Reproduce

1. Visit the page and strict-blocking will be triggered by EL
2. See how much it explains to average Joe

Expected behavior

Written

Actual behavior

Written

uBO version

1.46.0

Browser name and version

Firefox 109.0.1

Operating System and version

Windows 10

[Yuki2718]

Duplicate of

How it is?

uBO can and should add explanation of what happened, which is most likely to be either malicious site or tracker - then let user to decide which it is.

The proposal here is that uBO should add an explanation universal to all the strict-blocking pages regardless of the list or rule causing it.

[gothic-bum]

The proposal here is that uBO should add an explanation universal to all the strict-blocking pages regardless of the list or rule causing it.

How can there be a universal explanation when uBO has no way of determining for certain why a page is strict blocked?

For example:
If a filter list - or a custom filter added by a user - contains ||example-site.com^, how could uBO possibly determine the reason(s) why it was included?

It could have been added for a variety of reasons, and I personally have hundreds of custom strict block filters that uBO has no way of knowing why I added them or what category they are (e.g. tracker, malicious site, advertiser, annoyance).

So an "explanation" would be nothing more than a guess and most likely incorrect - which could be actually be more confusing to the user than what is shown with the current message on the strict block page.

[Yuki2718]

We don't need to care about non-default settings, those who configure settings should have better understanding. For default lists, only covering bad sites and tracker is 99% accurate. The more context of this is that it appears user tend to not be aware of the possibility of click-through tracking when confronted with the page.

[gothic-bum]

For default lists, only covering bad sites and tracker is 99% accurate.

EasyList is a default list. It currently has 19857 entries that are strict blocked and are not categorized as trackers or bad sites.

Peter Lowe's list is also a default list. It currently has 2614 entries (71% out of 3667) that are strict blocked and are not categorized as trackers.

[Yuki2718]

I mean those actually causing strict-blocking in real world are mostly either one. The example here www.profitablegatetocontent.com is an adserver but is perfectly fine to be classified to both as it tracks and also leads to bad sites with very high certainty. And we can use some "vague" words as Brave used "may", that's fine.

[Yuki2718]

Anyway my point is similar to those issues @garry-ut99 linked, the current page is way too unfrinedly and is actually confusing user, I'm not talking about a theoretical scenario.

[krystian3w]

You can write database to dynamic classify as ad server, tracking server, malware server.

[gorhill]

The example you provide is a Tweet of a user who observes that uBO blocked the navigation. He isn't saying he is confused. uBO already clearly states on that page that the page was blocked as a result of a filter and offers course of action to the user. What's the point of telling them there is no worry and just click proceed when the whole goal is to make them aware and let them decide for themselves what is best?

[krystian3w]

Apparently so, but when my mother browses through the shops she is constantly annoyed at the strict blockers and I usually have to unblock or explain to her that she is opening a fake online shop.

[Yuki2718]

I was forced to link that tweet as another one I tried to example was already deleted by the author, but the context of the tweet is he's applying an online seminer and there's no other choice than proceeding. If I had a fault, that would be not explained it's possible to use the loope icon to show a link without tracking.

[gorhill]

I really think a generic message downplaying what may be occurring is not the way to go if we want to provide more information about what is going on, consider:

[Yuki2718]

A question is how many ppl understand, or even can read (as written in English) Online Malicious URL Blocklist. And why it's downplaying if explained with "most likely bad sites or tracker"?

[gorhill]

Well maybe a more descriptive message depending on the group in which a list is categorized would be the way, but it would never be as specific as making the assumption it's merely a cookie tracking instance.

[Yuki2718]

That was kinda declinded as @garry-ut99 linked, but happy if you reconsider.

[gorhill]

By the way, when I proceeded with your example link, https://www.profitablegatetocontent.com/e51xmfb9?key=6cf0bf53774e52ec9e3ca94803f48b06, I hit again another strict-blocked page as a result of the filter /?pl=*&sm=$document in uBlock filters – Badware risks, and then again with another filter in uBlock filters – Badware risks, and then again uBlock filters – Badware risks. I stopped clicking Proceed at this point. This shows a generic message about cookie definitely is not the way to go.

[Yuki2718]

The link 99% leads to bad sites. So I'm saying in "A or B" manner. I commented to Brave that they should include the notion of bad sites.

[krystian3w]

Perhaps scam blockers are added too quickly based on URL parameters.

[gorhill]

That was kinda declinded as @garry-ut99 linked

Yes, and today I read again the issue and I think it was reasonable request. This was years ago and I admittedly sometimes go through periods where I feel the burden of this project more than usual and when this happens I will more eagerly dismiss issues.

[Yuki2718]

it's possible to use the loope icon to show a link without tracking.

BTW why it's hidden by default?

[Yuki2718]

Once the idea of trusted list comes true and if once-declined $queryjump was implemented in future, these can be solved without compromising privacy or user experience.

[Yuki2718]

To say the least, most user can't think of the possibility of tracking link:

https://twitter.com/Kota_pclive/status/1642870419408699394
https://twitter.com/metalch/status/1643951418884378624

and given most of those are by PL list and it's under Multipurpose, showing catogory won't help much. I wonder if there's a safe way to imply the blocking may be due to tracking link to user (with localizable way).

[gorhill]

We could have a set of build-in reason identifiers re. strict-blocking, which are used in assets.json as a strictBlockingReason, and when strict blocking occurs, uBO use the reason identifier to lookup a built-in localized message which would be added as the first line in the strict-blocking page, below the icon. So for example in assets.json this would look like:

"urlhaus-1": {
    "content": "filters",
    "group": "malware",
    "title": "Online Malicious URL Blocklist",
    "strictBlockingReason": "malware",
    "contentURL": [
        "https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt",
        "assets/thirdparties/urlhaus-filter/urlhaus-filter-online.txt"
    ],
    "cdnURLs": [
        "https://curbengh.github.io/malware-filter/urlhaus-filter-online.txt",
        "https://malware-filter.gitlab.io/urlhaus-filter/urlhaus-filter-online.txt",
        "https://malware-filter.pages.dev/urlhaus-filter-online.txt"
    ],
    "supportURL": "https://gitlab.com/malware-filter/urlhaus-filter#malicious-url-blocklist"
},

"plowe-0": {
    "content": "filters",
    "group": "multipurpose",
    "updateAfter": 13,
    "title": "Peter Lowe’s Ad and tracking server list",
    "strictBlockingReason": "tracking",
    "contentURL": [
      "https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext",
      "assets/thirdparties/pgl.yoyo.org/as/serverlist.txt",
      "assets/thirdparties/pgl.yoyo.org/as/serverlist"
    ],
    "supportURL": "https://pgl.yoyo.org/adservers/"
}

malware token would result in looking up the message (or whatever better English):

This site has been reported as serving malware

tracking token would result in looking up the message:

This site may attempt to track you across other sites

If no strictBlockingReason property is present, we keep the current behavior.

[MasterKia]

What about a $reason modifier?
reason = {malware, phishing, scam, tracking}

||example.com^$all,reason=phishing

This way filterlists other than the ones mentioned can also inform the user about the block reason.

For example I block scam and phishing/malware in my list.

[gorhill]

I rather keep it simple if we are going to do something about this, adding per-filter message vastly complicate the filtering engine and completely sabotage all the efficiency work which went into it.

[Yuki2718]

What about a $reason modifier? reason = {malware, phishing, scam, tracking}

Mostly duplicate of #1195

[iam-py-test]

For example I block scam and phishing/malware in my list.

Maybe there could be a more general message (something similar to This website may attempt to infect your device with malicious software, or steal your personal information or money, although I'm sure someone else can come up with a better message).

[Elementari]

Mostly duplicate of #3449, where I pointed out a concrete scenario.

I really think a simple option to assign colors (to the button "proceed") depending on filter (i.e., by filter) and/or blocking reason (i.e., by page) but be of considerable use.

In the case of assinging a color to a whole filter, it would still be about probabilities/heuristics. Just because a filter that's mostly about affiliate links might also help block malware, a dedicated malware filter is much more likely to be of concern and should rightfully be elevated optically as a warning/by using a red interface. Cf. Bayes' theorem, alpha/better error. I think this is a serious issue and possibly a likely cause of malware infection despite the use of uBlock.

Blue could be asigned to "neural" filters that block both malware and mere annoyances, green to those that block exclusively "benign" stuff (as defined by user; users might decide affiliate links are suffiently benign most of the time that tehy would want the green color for these, even if there's a remaining risk), and red to filters/reasons that are associated with high risk of malware.

Like I said I'm not sure if there's a system that will prioritize malign blocking reasons over more benign ones, when both apply.

And I would really like to suggest aligning the "Proceed" button in a way that it is in close proximity to the "Found in" section, so users will better see what they are agreeing to when clicking.
The proceed button at bottom right "invites" clicking both by the bottom right position (like a "NEXT" button) and distracts from the filter listing. I think it should be swapped in position for the Close button.
An additional idea would be that the color of the font/text of the filter listed in "found in" could be defined.

[krystian3w]

I really think a simple option to assign colors

Just how to assign colors so that the computer recognizes it without commenting over the filter (so generate problem for EasyList/EasyPrivacy/Peter Lowe, they project can reject mark stric block filters into categories by comments above).