uMatrix

[The-Compiler]

There should be something like RequestPolicy.

This will be a lot easier with per-domain settings.

[lamarpavel]

I am very interested in this feature as it is the main reason for me not to replace Firefox with qutebrowser entirely, how is the status on this?

Same goes for per-domain javascript restrictions.

[lamarpavel]

I am very interested in this feature as it is the main reason for me not to replace Firefox with qutebrowser entirely, how is the status on this?

Same goes for per-domain javascript restrictions.

[The-Compiler]

I'm currently working on internal refactorings and tests and expect to be busy for that for the coming few weeks - after that, it's either of these:

• The QtWebEngine/Chromium backend (#666)
• Config migrations (#499 and the issues linked there), then per-domain settings (#27)

I'm not sure which I'll work on first, as I really want both as well 😉

[The-Compiler]

I'm currently working on internal refactorings and tests and expect to be busy for that for the coming few weeks - after that, it's either of these:

• The QtWebEngine/Chromium backend (#666)
• Config migrations (#499 and the issues linked there), then per-domain settings (#27)

I'm not sure which I'll work on first, as I really want both as well 😉

[lamarpavel]

Has some work been done on per-domain settings? If so, it might be possible to "quickly" enhance the userscript interface with hooks such that a script can be automatically executed with each dns prefetch or page load. Something like Request-policy could then be solved as userscript by someone who has a bit of free time on their hands. Ideally that feature would be integrated into qutebrowser later on as it is rather essential imho, but until then a userscript would suffice.

I would like to help, but I have no experience with python (and while I am intigued enough to get intimate with it, it will take some time to feel comfortable with it. I also doubt you would want a complete python-beginner to dig so deep in your code base). If such a feature could be added via userscript however...

If not, I'll just stop bothering you with this and let you do your thing (:

[lamarpavel]

Has some work been done on per-domain settings? If so, it might be possible to "quickly" enhance the userscript interface with hooks such that a script can be automatically executed with each dns prefetch or page load. Something like Request-policy could then be solved as userscript by someone who has a bit of free time on their hands. Ideally that feature would be integrated into qutebrowser later on as it is rather essential imho, but until then a userscript would suffice.

I would like to help, but I have no experience with python (and while I am intigued enough to get intimate with it, it will take some time to feel comfortable with it. I also doubt you would want a complete python-beginner to dig so deep in your code base). If such a feature could be added via userscript however...

If not, I'll just stop bothering you with this and let you do your thing (:

[The-Compiler]

No, I didn't look into per-domain settings at all so far.

Regarding userscript hooks, see #35. But for that as well I want to put some thought into it first - for example the same kind of hooks should be used when "real" plugins are implemented (#30) later. I agree in general it can be tempting to do things quickly and then revise them later (and believe me, there are many features I'd love to see right now myself), but it pays back to put some more time into details, so I prefer going that route.

I can't see how you'd implement request policy in an userscript however. This is definitely something which is easier when it's done in the core (or as a "real" plugin).

If you feel like contributing to qutebrowser even with little Python experience, please feel free! I mostly learned C by contributing to herbstluftwm myself, and I'm happy to mentor and help where I can with Python. There's also a list of easy issues.

[The-Compiler]

No, I didn't look into per-domain settings at all so far.

Regarding userscript hooks, see #35. But for that as well I want to put some thought into it first - for example the same kind of hooks should be used when "real" plugins are implemented (#30) later. I agree in general it can be tempting to do things quickly and then revise them later (and believe me, there are many features I'd love to see right now myself), but it pays back to put some more time into details, so I prefer going that route.

I can't see how you'd implement request policy in an userscript however. This is definitely something which is easier when it's done in the core (or as a "real" plugin).

If you feel like contributing to qutebrowser even with little Python experience, please feel free! I mostly learned C by contributing to herbstluftwm myself, and I'm happy to mentor and help where I can with Python. There's also a list of easy issues.

[lamarpavel]

Got it, thanks for the quick reply. I'm in total agreement on planning things carefully (learnt the hard way), with "quickly" I meant that it might be easier and take less time than the other big things you are working on.

I'll take a look at the list of easy issues, but I'd rather not make promises right now as to when I might be able to contribute.

[lamarpavel]

Got it, thanks for the quick reply. I'm in total agreement on planning things carefully (learnt the hard way), with "quickly" I meant that it might be easier and take less time than the other big things you are working on.

I'll take a look at the list of easy issues, but I'd rather not make promises right now as to when I might be able to contribute.

[The-Compiler]

I'm repurposing this issue for something uMatrix-like, which is basically a superset of requestpolicy. Also, QtWebEngine has a nice API to do this. Still not sure if it'll happen before the plugin API though.

[The-Compiler]

I'm repurposing this issue for something uMatrix-like, which is basically a superset of requestpolicy. Also, QtWebEngine has a nice API to do this. Still not sure if it'll happen before the plugin API though.

[The-Compiler]

I just opened #2626 which is a lightweight version of this - essentially uMatrix without the GUI - and is much more likely to happen in the near future.

[The-Compiler]

I just opened #2626 which is a lightweight version of this - essentially uMatrix without the GUI - and is much more likely to happen in the near future.

[The-Compiler]

So per-domain settings (#27) are merged, and I'll probably look at #2626 soon as it should be quite straightforward now.

However, what's still missing for uMatrix-like functionality is the possibility to specify a second URL (from_pattern='...' or whatever). I'm going to track this in this issue, since I'm also sceptical how many people would find this useful without an uMatrix-like UI.

[The-Compiler]

So per-domain settings (#27) are merged, and I'll probably look at #2626 soon as it should be quite straightforward now.

However, what's still missing for uMatrix-like functionality is the possibility to specify a second URL (from_pattern='...' or whatever). I'm going to track this in this issue, since I'm also sceptical how many people would find this useful without an uMatrix-like UI.

[Ongy]

The first thing I would like to see from this is a:

• from_pattern http://* content.javascript.enable false, since I may trust a site, but not my network.
• block that one silly script that disables right click on images

[Ongy]

The first thing I would like to see from this is a:

• from_pattern http://* content.javascript.enable false, since I may trust a site, but not my network.
• block that one silly script that disables right click on images

[MichaelMackus]

Yes, I definitely would find this useful, even without a uMatrix GUI and with a pattern specified like @Ongy's comment above. So far, I'm very satisfied with the implementation of #27 and I see no reason why it would be more work for the end user than, for example, configuring per-domain noscript (which currently works great).

[MichaelMackus]

Yes, I definitely would find this useful, even without a uMatrix GUI and with a pattern specified like @Ongy's comment above. So far, I'm very satisfied with the implementation of #27 and I see no reason why it would be more work for the end user than, for example, configuring per-domain noscript (which currently works great).