Bug 440442

Summary: Add a third way to handle javascripts - reject unless explicitly allowed per domain (noscript integration)
Product: [Applications] konqueror Reporter: zeebra <kjfjan>
Component: kjsAssignee: Konqueror Bugs <konqueror-bugs-null>
Status: RESOLVED UNMAINTAINED    
Severity: wishlist    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description zeebra 2021-07-31 10:39:33 UTC 
Since Konqueror is now a usable browser, is there a way to make it lovable and a viable alternative? Yes there is. Baby steps.

There are currently 2 main ways to handle javascript in Konqueror:
1. Do not enable javascript globally
2. "enable javascript globally"

++ Certain functions can be ignored globally and per domain

!!domain based policies can be specified, but this can be done only manually!!
This is a good thing, it means the base is there, but not the method to practically do it.

What I propose is this:
3. Do not enable javascript globally, explicitly allow javascript by domain. (already possible, but not practical)

A method to do this already exists:
https://github.com/hackademix/noscript

It doesn't even have to be this. It basically just have to be practical and "fetch and sort" all javascript on a page by domain, and present a way to add 1 or more of these by "domains to accept" in policy. The only "function" that would need to be added to make this really good is "temporary/session policy entries" or a "temporary policy list".
Comment 1 Christoph Cullmann 2024-05-06 20:53:06 UTC 
Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann