If you use Chrome daily, do these 9 settings right now (it takes 10 minutes).

[Bot]

@Bot

I am interested in knowing whether both are redundant or not.

They’re not strictly redundant, but they overlap and in practice the “block HTTP JavaScript” rule is usually low value if you already run HTTPS-First.

HTTPS-First / Always use secure connections

• Goal: avoid HTTP entirely by upgrading to HTTPS when possible (and optionally warning/blocking when a site can’t do HTTPS).
• Security impact: high. It prevents the whole class of “someone tampered with my HTTP session” problems for sites that support HTTPS.
• Breakage: usually low to moderate (mainly old sites, captive portals, LAN device UIs).

Block JavaScript on `http://*`

• Goal: reduce script execution specifically on HTTP pages.
• Security impact: limited, because on HTTP an attacker can tamper with the HTML itself, links, forms, and downloads—not just JS. So “no JS” doesn’t make HTTP “safe.”
• Breakage: can be significant for any HTTP-only site/device UI that relies on JS.

So are they redundant?

• If HTTPS-First is enabled in a “strict” way (warn/block when HTTPS isn’t available), then blocking JS on HTTP becomes mostly redundant because you’re rarely (or never) loading HTTP pages.
• If HTTPS-First is in a more “fallback” mode (it tries HTTPS but still allows HTTP without a hard stop), then blocking JS on HTTP is not redundant—but it still doesn’t address the core insecurity of HTTP, and it can cause annoying breakage.

Recommended approach

• Use HTTPS-First as the primary control.
• If you want extra hardening, consider blocking high-abuse permissions globally (Notifications, popups/redirects, automatic downloads), rather than targeting JS on HTTP.
• Only add “block JS on `http://*`” if you have a specific environment where you frequently hit HTTP pages and you accept the usability cost.

 

[Sampei.Nihira]

@Bot

Yes, that's why I only visit one HTTP web page, so I have to bypass the HTTPS-only block.

 

[Bot]

@Bot

Yes, that's why I only visit one HTTP web page, so I have to bypass the HTTPS-only block.

If you only ever visit one specific HTTP site and you already run HTTPS‑Only, then the clean setup is:

Keep HTTPS‑Only enabled
That remains your primary protection for the rest of the web.

Handle the one HTTP site as a narrow exception (not `http://*`)
Using a global `http://*` rule is overkill when you have a single target.

• Allow/bypass HTTPS‑Only only for that one hostname (however your browser implements it).
• Optionally set JavaScript = Block for that specific site (e.g., `Example Domain`) rather than for all HTTP sites.

Is “block JS on that one HTTP site” redundant in your case?

• It’s not redundant in the strict sense: HTTPS‑Only controls transport security; JS blocking controls active content execution.
• But it’s also not a complete mitigation for HTTP. Even with JS blocked, an attacker on the network can still tamper with the HTML, links, and downloads on an HTTP page.

What I’d recommend for your specific scenario

• Use a separate browser profile (or a separate browser) only for that HTTP site.
• In that profile, set tight site permissions (block notifications, popups/redirects, automatic downloads).
• If the site still works, set JavaScript = Block for that one site; if it breaks, you’ll have to allow JS and rely on isolation (separate profile) instead.
• Avoid logging into anything sensitive or reusing passwords on that HTTP page.

Net: keep HTTPS‑Only, whitelist the single HTTP site, and if you want extra hardening do JS blocking only for that site, not `http://*`.

 

[TairikuOkami]

Security systems frequently block state-sponsored media links

Well, I have never seen them to block CNN or Euronews, thus I disable all those "security protections" like SmartScreen, I prefer an unfiltered world.