-
Notifications
You must be signed in to change notification settings - Fork 479
[Chrom*] connections not being blocked after reload #234
Comments
when "Prefetch resources to load pages more quickly" is enabled, it causes the above issue when it is disabled, it behaves as in firefox |
There is so much uMatrix can do with Chrome's prefetch, it's why it's advised to turn that feature off. You should see the requests from prefetch in the behind-the-scene matrix though, and if you want to use pre-fetch, this is where you will have to filter these requests if you want to block them. Please confirm you see them in the behind-the-scene matrix, and if so, then close the issue, there is nothing uMatrix can do, the requests which are behind-the-scene are so because it's not possible for uMatrix to associate them with a specific tab. Browsers' prefetch features are incompatible with privacy minded habits anyways. |
i didn't enable the option and i always have it disabled, it is enabled by default for new users i came across this issue when i ran chrome as a new user, without going to the settings first, i installed and configured umatrix, and i saw that connections to google servers were being opened when reloading when i learned that it was the option that caused the issue, i closed the issue here, but i reopened it because i didn't know if you were aware of the issue and if you were planning to address the issue if it was possible to address it the requests that are sent by the resource prefetcher are not logged |
I am trying to reproduce. First, the setting is: [ ] Predict network actions to improve page load performance Right? Second, you say you see the issue after forcing a refresh of the page? I tried this, and google was reported in the logger and blocked as expected. How did you check for those connections? I want precise and concise step by step on how to reproduce -- I just want to follow them without having to guess anything. Once I reproduce and I confirm that uMatrix/uBlock are not called for these pre-fetched requests, will have to document prominently for users to disable that feature.. |
the setting is when that is enabled, the requests to in the umatrix logger it shows that the request was blocked, but that is false |
Ok, they change the wording in Chrome vs. Chromium. Ok here is what I see using Looking through the Chrome API, I see there is an API to disable that setting. So given the nature of uMatrix/uBlock, I will force this setting to be disabled. |
There has to be a better way to do this -- changing users privacy settings (even for something as trivial as this) should never happen. Perhaps a dialog explaining what to do? |
@dorkbox uBlock/uMatrix's job is to block network requests, and users trust that it does what it says it does. Not disabling pre-fetching betrays that trust [1], as the reality is that most people will install and not care to RTFM. I have users' interests at heart first and foremost, including those who don't RTFM, so this will stay. [1] Just opening a TCP connection causes the remote server to become aware of one's IP address, with no data yet having been transferred. This is not compatible with a privacy-minded extension, for which it is expected the remote server of a blocked network request is completely unaware of your existence. |
@gorhill I appreciate your honesty in this matter, as well as the work you and others have done. Your given points make sense, and I agree. |
@gorhill Perfect. Thank you. |
in Chromium 58.0.3018.0 (Developer Build) (64-bit) |
Yes I've seen this with uBlock Origin too. Not sure what is going on with Chrome's redesigned Settings page. |
According to |
Looks like it's about to get fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=693301#c4 |
going to http://the-witness.net/, gets the doc by opening 2 connections, after reloading, connections are opened to google servers also
no problem in firefox, only 1 connection is opened and the requests to google are blocked
latest stable versions, firefox with 0.9.1.1, chrome with 0.9.1.2-dev.1
the rules
The text was updated successfully, but these errors were encountered: