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.
Important: The per-site switches are independent from the matrix filtering switch, meaning that if you turn off matrix filtering in one scope, the per-site switches which are toggled on will still apply. For example, one could turn off matrix filtering while keeping the ability to enforce strict HTTPS.
User agent spoofing has been transformed from a 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 (*). Since narrower scopes will inherit the switch state from a broader scope, this means the global scope switch still act as a global setting, difference being that now the switch state can be overridden in a narrower scope.
Similarly, referrer spoofing has been transformed from a 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 (*). Since narrower scopes will inherit the switch state from a broader scope, this means the global scope switch still act as a global setting, difference being that now the switch state can be overridden in a narrower 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.
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.
Chromium/Firefox forbid some 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. However, as investigated by a user, this does not apply to image, video and audio resources.
With uMatrix 0.9.0.0, unsecure network requests are blocked directly by uMatrix, rather than by the browser through a CSP directive. This means if a page is mixed content, your browser will notify you about the mixed content on that page, though the connections were blocked by uMatrix (use the logger to see for yourself).