Per scope switches
Per-scope switches, introduced in version 0.8.1.0, allow a user to customize various settings for a specific scope.
The state of a per-scope switch in a broad scope will be inherited by narrower scopes, unless a more specific rule override the broader rule.
For example, setting the per-scope switch "User agent spoofing" in the global (*) scope will cause the user agent information to be spoofed everywhere. However, user agent spoofing could cause a site to not work properly (example: crowdin.com), and it is thus possible to override the global state of the "User agent spoofing" switch by disabling the switch just for the scope where it causes problem.
The per-scope switches layer just like matrix rules layer.
User agent spoofing has been transformed from global setting into a per-scope setting, so that you can now disable/enable it specifically on a per-scope basis. The setting in the Privacy tab is still there, and its purpose is to control user agent spoofing for the global scope (*).
Similarly, referrer spoofing has been transformed from global setting into a per-scope setting, so that you can now disable/enable it specifically on a per-scope basis. The setting in the Privacy tab is still there, and its purpose is to control referrer spoofing for the global scope (*).
The logic behind referrer spoofing is simpler now: it's whether the switch referrer spoofing is turned on, and whether the domain of the referrer URL is third-party to the domain of the request URL. Whether the domain of the URL of a request is whitelisted is now irrelevant.
Also, notice that now I use the term "spoofing". Whereas before the referrer string was blanked, the referrer information will now be foiled using the root URL derived from the URL of the request. For example, if the URL of a request is http://www.example.com/blahblahblah/boring.html and the referrer is http://google.com, the referrer will be spoofed using the http://www.example.com/ string.
Edit 2014-11-21: After I updated to Chromium 38 yesterday, I just found out that now apparently Chromium forbids mixed content by default. When there is mixed content on a web page, a little shield icon will appear in the address bar, and a user may click on it to load the content which was forbidden from loading natively by the browser. This is great, and this kind of render the new "Strict HTTPS" switch here useless. I still have to see if does this completely for all types of requests, but I expect it to be the case (tell me if you find out it still can happen). Given this, I may remove the "Strict HTTPS" switch before release if it ends up not having a purpose anymore.
First, if you are not familiar with what is "mixed content", here are some places to learn more about it:
- Mozilla Developer Network: Mixed Content
- Qualys Blog: HTTPS Mixed Content: Still the Easiest Way to Break SSL
- W3C: Mixed Content
When the "Strict HTTPS" switch is turned on, mixed content will be forbidden.
"Strict HTTPS" is more then to just protect MITM attack. Without "Strict HTTPS", data-mining by 3rd-parties can still occur, as evil ISPs like Verizon et al. could still inject tagging information in the HTTP headers of outgoing net requests which are not done through encrypted connections.
To witness "Strict HTTPS" at work, visit the encrypted version of Wired's Threat Post, which suffers (at time of writing, 2014-11) from mixed content:
When "Strict HTTPS" is turned on, you can see in the above example the browser refusing to process all non-HTTPS connections -- to kasperskyhub.staging.wpengine.com in the above case.
Since the unencrypted connection is not even attempted by the browser, this prevents µMatrix to account for these skipped connections, and thus they won't be reported in the matrix. But you can see them using the developer console.