Support more per-domain settings #3636

Open
The-Compiler opened this Issue Feb 25, 2018 · 7 comments

Comments

Projects
None yet
5 participants
Collaborator

The-Compiler commented Feb 25, 2018

Split off from #27 - settings which would be useful per-domain:


Some more musings about what code this is going to affect how, what's possible to set, and what kind of URLs should be affected, prompted by this IRC conversation:

2017-10-10 16:29:18     jkamat  also, re: domain matching. If I style 'a.com' and it has an iframe or external resources linking to b.com, will those get the per-domain settings of a.com (since that's the original page)
2017-10-10 16:31:22     hola1_  no
2017-10-10 16:31:28     hola1_  cause it's not the same domain
2017-10-10 16:33:21     jkamat  that could be annoying, imo. I guess it's possible to go through and add rules for the iframe domains as well...
2017-10-10 16:42:21     hola1_  that's the intension behind per-_domain_ settings... every domain which is called, get's it's own settings no matter if in an iframe or as page (except it's done like in uMatrix where in a.com containing b.com, b.com can have other settings for b.com than c.com containing b.com)
2017-10-10 16:44:10     jkamat  I think that from a high level (ignoring requests and all) per-domain settings make it possible to "go to something.com" and have "settings apply on that website", which wouldn't be the case if something.com was implemented with a ton of iframes or similar
2017-10-10 16:51:45     The-Compiler    jkamat: so many unsolved questions...
2017-10-10 16:52:12     The-Compiler    but yeah, I also tend to think that it wouldn't affect frames from a different origin
2017-10-10 16:53:19     The-Compiler    let's say you have stylesheets for blog.example.com, and that has an iframe from youtube.com or whatever - I don't think the styling rules for blog.example.com should be applied to YouTube
2017-10-10 16:56:25     gilbertw1       I agree with that, iframes generally should be treated as a completely separate entity (which they are)
2017-10-10 17:05:29     jkamat  hmm, I guess that's true. I'm more worried about externally hosted javascript as well (suppose a script linked from a different domain exists, it won't run on a site with javascript disabled, right?)
2017-10-10 17:09:08     gilbertw1       You mean that if you block all javascript on any pages from Domain X using per-domain settings, you don't want it loading and running scripts from Domain Y when you access a page on Domain X
2017-10-10 17:09:39     jkamat  yes, that's a clearer explanation of what I want :P
2017-10-10 17:11:07     gilbertw1       Hah, that's a good point that I don't know the answer to. It's definitely a valid use case I'd assume many would want
2017-10-10 17:13:08     hola1_  if i understand you right, you explaining the same what i've tryed and what uMatrix ( https://github.com/gorhill/uMatrix ) does

We basically have three kind of URLs:

  • The current page qutebrowser is on. I'm calling this "top-level URL" here.
  • The URL a resource is loaded from. I'm calling this "resource URL" here.
  • The URL of a frame/iframe. I'm calling this "frame URL" here.

User stylesheets

QtWebKit

We can use QWebSettings::setUserStyleSheetUrl based on the top-level URL.

QtWebEngine

Since we use JavaScript to apply the stylesheet, it's probably easy to get the frame URL, and I think it's better to use that for the stylesheet. In other words, if you're on www.example.com and that has an iframe for www.youtube.com, the stylesheet for example.com doesn't apply in the YouTube frame.

We could also format the top-level URL into JavaScript from Python (or get it in JS directly? Probably not?) - but I think we don't need it at all.

Cookies

  • Use case: Accepting cookies selectively

QtWebKit

In QNetworkCookieJar::insertCookie we should be able get the resource URL (?) via QNetworkCookie::domain. I'm not sure whether we can get the top-level URL in any way...

QtWebEngine

There's no cookie filter API yet (WIP Qt 5.11 change). We could probably watch QWebEngineCookieStore::cookieAdded and call deleteCookie right away.

Looks like there's no way to get the top-level URL here either?

User agent

  • Use case: Workarounds for sites relying on UA checking

QtWebKit

Override QWebEnginePage::userAgentForUrl. We can probably get both the top-level URL (from the page) and the request URL.

QtWebEngine

We have the user agent set via QWebEngineProfile::setHttpUserAgent and that's global. However, at least for headers (but not window.navigator.userAgent) we can use QWebEngineUrlRequestInterceptor to return an user agent based on the top-level and request URL.

Other headers

  • Use case: ?

QtWebKit

We can set those in createRequest based on the resource URL.

QtWebEngine

We can set those with a QWebEngineUrlRequestInterceptor based on the resource and top-level URL.

Requests

  • Use case: uMatrix-like functionality, not loading JS/images/... at all where it's not allowed.

QtWebKit

With QNetworkAccessManager::createRequest we can get the QNetworkRequest. However, we can't really get much information from there (e.g. the type of the request).

QtWebEngine

With a QWebEngineUrlRequestInterceptor we can get some infos about requests, allowing for something uMatrix-like. See #2626, #28.

Bindings

  • Use case: Unbinding conflicting bindings where the website has nicer ones; binding utility commands for a given page

Haven't looked into that yet, but the code handling the bindings can probably just look at the current URL. This one should be backend independent.

In addition to adding new bindings, it should be possible to selectively unbind bindings for a page.

Permissions

  • Use case: e.g. automatically allow geolocation for OpenStreetMap

QtWebKit

QWebPage::featurePermissionRequested gives us the QWebFrame (and thus frame URL), we can get the top-level URL from the page.

QtWebEngine

QWebEnginePage::featurePermissionRequested gives us the securityOrigin (frame URL?) and we can get the top-level URL from the page.

Proxy

  • Use case: Preventing proxy usage for some pages

QtWebKit

TODO

QtWebEngine

TODO

Other

  • Use case: ?

Some other settings which could apply per-domain based on the current URL, but where it's questionable whether there's an use-case:

  • aliases
  • ignore_case
  • content.host_blocking.enabled (to selectively turn off adblocking)
  • content.host_blocking.whitelist (could be merged into .enabled with top-level/origin URL?)
  • content.javascript.alert / .log / .prompt
  • downloads.location.*
  • hints settings? Probably hints.*_regexes at least.
  • input settings (forward_unbound_keys, etc.)
  • zoom.default
  • colors/fonts?

This was referenced Feb 25, 2018

This comment has been minimized.

Show comment Hide comment
@Waples

Waples Mar 6, 2018

Would like to see per-domain 'auto accept permissions for audio/video', for example Slack Calls from a trusted domain.

Don't know how I can help, but if I can, tell me ^^

Waples commented Mar 6, 2018

Would like to see per-domain 'auto accept permissions for audio/video', for example Slack Calls from a trusted domain.

Don't know how I can help, but if I can, tell me ^^

This comment has been minimized.

Show comment Hide comment
@The-Compiler

The-Compiler Mar 6, 2018

Collaborator

@Waples Already mentioned as "Permissions" above (also, yay, my name is Florian too 😉)

Collaborator

The-Compiler commented Mar 6, 2018

@Waples Already mentioned as "Permissions" above (also, yay, my name is Florian too 😉)

This comment has been minimized.

Show comment Hide comment
@Waples

Waples Mar 6, 2018

Yeah saw it just now, sorry for the bump. (also, small world cause my last name also starts with a B :') )

Waples commented Mar 6, 2018

Yeah saw it just now, sorry for the bump. (also, small world cause my last name also starts with a B :') )

This comment has been minimized.

Show comment Hide comment
@m-j-r

m-j-r Mar 10, 2018

I like the idea of downloads.location.* being site specific - allows me to not have to fiddle around when e.g. saving bank statements into 'statement folder' and then remembering to change it back to downloads next time.

m-j-r commented Mar 10, 2018

I like the idea of downloads.location.* being site specific - allows me to not have to fiddle around when e.g. saving bank statements into 'statement folder' and then remembering to change it back to downloads next time.

This comment has been minimized.

Show comment Hide comment
@Zekario

Zekario Mar 18, 2018

I'd like per-domain fonts. I prefer my built in fonts for most websites, but if I disable remote fonts globally a few sites I use a lot are missing icons.

Zekario commented Mar 18, 2018

I'd like per-domain fonts. I prefer my built in fonts for most websites, but if I disable remote fonts globally a few sites I use a lot are missing icons.

This comment has been minimized.

Show comment Hide comment
@Ambrevar

Ambrevar Mar 19, 2018

If I understand this correctly, Qutebrowser 1.2.1 does not allow for per-domain stylesheets yet?

If I understand this correctly, Qutebrowser 1.2.1 does not allow for per-domain stylesheets yet?

This comment has been minimized.

Show comment Hide comment
@The-Compiler

The-Compiler Mar 19, 2018

Collaborator

@Ambrevar Correct.

Collaborator

The-Compiler commented Mar 19, 2018

@Ambrevar Correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment