You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2017. It is now read-only.
µBlock for mainstream protection (pattern-based filtering, cosmetic filtering, i.e. ABP-like)
µMatrix for advanced protection (i.e. RequestPolicy/NoScript-like) and more advanced privacy features
Remove all pattern-based and cosmetic filtering
Remove associated code
Remove associated assets
Rewrite matrix filtering engine
Support global scope rules as finer-grained ubiquitous rules
Huge amount of work: easier said than done
Convert all dependent code to new scoping mechanism
Remove settings:
"Copy all rules from global scope into newly created local scopes"
"Auto create temporary {domain|site}-level scope"
"Auto delete unused temporary scopes"
Remove "Ad blocker-like" from preset setups
Implement same mechanism as µBlock to fetch remote lists of blocked hosts
Rewrite popup.js without jQuery (because mem footprint of popup)
The more we bring the popup, the more base memory footprint grows. I suspect this will help improve that, if not fix it.
Create a Crowdin project for µMatrix
Meanwhile, what is best to do IMO:
Go to HTTPSB's "Ubiquitous rules" in the dashboard:
Uncheck "Parse and enforce Adblock+ complex filters"
Uncheck "Parse and enforce Adblock+ element hiding filters"
Uncheck all lists of ABP-compatible filters:
EasyList
EasyPrivacy
All lists from Spam404 and below
Click "Apply changes"
Install µBlock
From now on, let µBlock deals with the pattern-based filtering
It's better optimized and has many features not available in HTTPSB:
Element hiding helper
Collapse blocked elements
Can subscribe to external lists
You will find that HTTPSB runs pretty lean with ABP-filtering disabled
You may want to disable "Malware domains" lists in µBlock and rather let HTTPSB deals with these.
HTTPSB is much more strict when it comes to blocking, i.e. it will block all requests to blacklisted hostnames, while µBlock never block net requests for the root documents (in line with ABP's semantic).
i like uMatrix name, and it seems to be a more streamlined version and designed to work inconjunction with ublock, i would definitely use it.
And it would reduce the tinkering of which lists to enable/disable when ublock is installed :)
The main feature currently i am looking in uMatrix is HTTPSB's privacy feature set, which i miss in uBlock.
Why do you want to remove the "Auto create temporary {domain|site}-level scope"
Generally: at some point, too many settings is more confusing than not. Many new users end up not having an idea how to best use the extension. I need to enforce a preferred way to use it. The less settings the less worries about how to use the extension optimally.
Specifically: I was using HTTPSB, err... uMatrix with the auto-creation enabled. If uMatrix is going to support global rules as ubiquitous rules, enabling auto-creation will get in the way, it will become annoying, because it will get in the way of creating global rules when landing on a new page. I vist new page, I see linkedin.com in the matrix, I want to blacklist this tracker one globally, but with a scope auto-created, I need to switch back to global, than back again to scope. It's annoying.
The "normal" way of using uMatrix in block-all/allow-ex approach will be to always browse in global scope, and exceptionally users can create a scope for when it's a web site they visit often. Given scopes are exceptions, there shouldn't be a setting to auto create every single time. Out of the box a user will end up creating a lot of scopes, but once his environment is setup in uMatrix, browsing in global scope becomes optimal.
I consider now scope creation to be an exception, and having one created each time a new web site is visited doesn't make much sense. It also clutters the memory, it forced me to put in there yet another option to garbage collect unused scopes.
I didn't say scopes are going away, I said there just won't be a setting to have them auto-created each time a user land on a page with a new domain for which a scope doesn't exist.
exactly means
The option "Copy all rules from global scope into newly created local scopes." will become unnecessary: all rules in global scope will be seen by narrower scopes without the need to copy them internally.
Thing is, I have to look at the big picture, i.e. what is best in my opinion for a majority of users. I just wish we all have this bigger picture in mind when requesting features. I do go once in a while on a google search to find out the unformal feedback about the extension. And one thing that sticks out in my mind is people aren't too sure how to use it optimally. To fix that is to avoid having so many settings that users end up uneasy about whether they are using it properly or not. I am trying to figure how to fix that.
In block-all/allow-ex mode, scopes are exceptions, so the exceptional step is to click to create one. In allow-all/block-ex mode, scopes are irrelevant.
If ever a user want to whitelist a whole page, which is the typical case of having a scope when working in block-all/allow-ex mode, that would be ctrl-A, which will always create a scope in such case if none exists (I could add an icon button for this one since the ABP icon is gone).
So normally no need to explicitly blacklist that kind of domains
Disagreed. There is css/img, and if whitelisting the all cell, happy to have it blacklisted expressly.
I guess it's a matter of taste
I decided to address things this way now: there is a scale: sites broken = less users, sites not broken = more users. So I am addressing things from that perspective. uBlock breaks less than uMatrix allow-all/block-ex which breaks less than uMatrix block-all/allow-ex. To not overcomplicate for the majority of users, in order to not discourage but rather nurture good privacy/security habits.
uMatrix will never become less powerful, I just want to make it more accessible to more. Too many settings which are meaningful to only one end of the scale. Auto-scope creation is useful only to block-all/allow-ex, and only a portion of those users of that mode, and even for those users, it can get in the way sometimes.
Currently working on this. uMatrix won't come out without this. It's a huge amount of code to rewrite, but it's the aspect of HTTPSb which bothers me the most. It will be definitely fixed, I can't tell how long it will take.
I have extensively customized and then ditched HTTPSB several times. I've decided the only way I can use it and be happy is to block-all/allow-ex and then auto-create & auto-whitelist the page domain for JS/XHR. This lets me browse 95% of pages without errors and only edit the matrix when I need cookies or shopping carts, while still blocking all the third-party junk.
Will losing "Auto create temporary {domain|site}-level scope" mean we lose auto-whitelisting of the page domain?
And while I have often had to do the annoying changing-scopes dance you describe above to allow or block something globally, I far more often want to edit the matrix for the page domain that I am browsing, and having the matrix display the page domain by default makes for the easiest & quickest use, and is more likely to encourage correct usage by new users than default global scope.
I still believe a layered, inheriting matrix is needed for this software to work most powerfully and understandably (see #227).
I far more often want to edit the matrix for the page domain that I am browsing
I currently use the matrix in allow-all/block-ex, except I blacklist cookie, XHR and frame in global scope. Whenever I land on a site which I want to unbreak for good, it is quite trivial to:
while in global, first blacklist all that deserve it that was not done yet
switch to domain-level scope
unblacklist cookie, xhr
save, done
As of now it's really the easiest way I have found to surf with good peace of mind, little breakage, and where breakage exists in need of unbreakage, it is trivial. This is my whole point: I figure this way HTTPSB becomes more within reach of people who are less tolerant of site breakage.
I am trying to lower the annoyance point at which less tolerant users give up on a tool beneficial for them. This is just an undeniable reality: hardcore users who block-all/allow-ex by default have a higher tolerance to security/privacy tool annoyance, I am trying to help the ones who have a lower tolerance so they can benefit from such tool too.
crucial decision phase regarding how µMatrix will look like
Look, all can be changed afterward according to feedback etc. It's a fork, HTTP Switchboard will still be there. I just want to take steps back and focus on people who could probably use it, but got confused by the plethora of choices right off the bat.
They will not benefit from the removal of that setting
They benefit in the way of them not ending wondering whether they should use it or not. One middle way solution would be to have an advanced button which would unveil more settings which would be more suitable to advanced users.
I just want current advanced users to take a more altruistic view and work with me to bring this tool to more people, there is so much to benefit from it. That means forgetting about our own pet habits as advanced users and trying to help those who would like to use it but feel like they need to take a course to use it.
Well, the people who abandoned early because of perceived complexity aren't going to show up here to be counted.
Good point, but that could fly either way. Those who abandon it for lack of configurability / privacy might not show up too. I hope that those who show up, do count :)
@gorhill uMatrix & HTTPSB have some other common subscriptions: malware domains, various hosts lists that have only domains. They are better have enabled only in HTTPSB? Also, in uBlock you can add that Fanboy Annoyances includes Fanboy Social (proof) and BitBlock includes most of Fanboy Annoyances (proof).
I will throw some ideas just for the purpose of keeping track of these for myself, as I tend to forget often when busy with other stuff.
So re. "auto creation of scope":
No more need to create a scope, all scopes exist all the time (virtually).
From the point of view of a user, a user doesn't need to pick which scope is going to be active: the site-level scope always exist, the domain-level scope always exist.
These domain- and site-level scopes just happen to have the same exact rules as the global scope, unless they are tampered with.
A copy-on-write approach will cause a real scope to be instantiated in memory whenever its rules differs from the scope underneath.
A real scope which ends up as having exactly the same rules as the one layered under will be removed from memory.
So the above gets rid of settings for auto-creation and auto-deletion of scopes.
UI-wise, need to come up with some visual for the scope selector which makes it clear that the three scopes always exist (and to be able to glance if there are unpersisted temporary rules in any of them).
Other various ideas re implementation:
Instead of a scope being implemented as three separated set of rules (black, white, gray), it will now be just one set of rules, but each rule can have one of four states: black (-1), gray explicit (0), white (+1), or gray implicit (undefined). (make layering algorithm way easier)
No need to have data structure for the permanent scopes in memory: a simple string which represents the streamed version of a scope can simply be attached to the instantiated scopes.
I'm committing 100% to the idea of layering as was expected in issue #227. Other users also expected layering when using HTTPSB.
It's really what you see is what you get. If you explicitly blacklist a cell in global scope, the rule will be in global scope. Scopes above will see that rule, unless they have their own explicit rules for that cell.
Layering already exists actually, this is how ubiquitous rules are implemented. So whatever issues you may see with what is proposed above, is probably present if you consider existing ubiquitous rules.
In layering, for each cell, the three scopes are visited to determine the state of the cell. Than if after all this the cell is evaluated as gray, the usual matrix-based inheritance algorithm is applied.
Say, I tamper with a site-specific scope - does this mean that the respective global and domain-specific scopes will be deleted
No, the cell which you tampered with will override whatever is in broader scopes for that same cell.
Also by the way, given the way I now plan to implement scopes etc as described above, I have furtehr thought:
The auto-whitelist feature will always apply to the narrowest scope, just like it is currently the case if you whitelist through [Alt-A].
Also, as said, the three scopes always exist at all time, so the scope which will appear when you bring up the matrix will just be the last one which was active last time you accessed the matrix. So if a user tampers mainly with site-level scopes, the automatically selected scope will be site-level.
When (approximately) are you planning to release uMatrix?
Will uMatrix replace HTTPSB?
Will it have its own github?
I think uMatrix is a great idea and name.
as someone who has tried to use HTTPSB and given up multiple time this sounds like an awesome idea; I love the work you're doing here gorhill.
I never noticed you can change to global policies from the popup window, or that you needed to save the temporary policies to make them permanent until after reading the thread and trying uMatrix.
Activity
harshanvn commentedon Jul 21, 2014
i like uMatrix name, and it seems to be a more streamlined version and designed to work inconjunction with ublock, i would definitely use it.
And it would reduce the tinkering of which lists to enable/disable when ublock is installed :)
The main feature currently i am looking in uMatrix is HTTPSB's privacy feature set, which i miss in uBlock.
gorhill commentedon Jul 21, 2014
Generally: at some point, too many settings is more confusing than not. Many new users end up not having an idea how to best use the extension. I need to enforce a preferred way to use it. The less settings the less worries about how to use the extension optimally.
Specifically: I was using HTTPSB, err... uMatrix with the auto-creation enabled. If uMatrix is going to support global rules as ubiquitous rules, enabling auto-creation will get in the way, it will become annoying, because it will get in the way of creating global rules when landing on a new page. I vist new page, I see
linkedin.comin the matrix, I want to blacklist this tracker one globally, but with a scope auto-created, I need to switch back to global, than back again to scope. It's annoying.The "normal" way of using uMatrix in block-all/allow-ex approach will be to always browse in global scope, and exceptionally users can create a scope for when it's a web site they visit often. Given scopes are exceptions, there shouldn't be a setting to auto create every single time. Out of the box a user will end up creating a lot of scopes, but once his environment is setup in uMatrix, browsing in global scope becomes optimal.
I consider now scope creation to be an exception, and having one created each time a new web site is visited doesn't make much sense. It also clutters the memory, it forced me to put in there yet another option to garbage collect unused scopes.
gorhill commentedon Jul 22, 2014
I didn't say scopes are going away, I said there just won't be a setting to have them auto-created each time a user land on a page with a new domain for which a scope doesn't exist.
The option "Copy all rules from global scope into newly created local scopes." will become unnecessary: all rules in global scope will be seen by narrower scopes without the need to copy them internally.
gorhill commentedon Jul 22, 2014
linkedin.comin the matrixlinkedin.comlinkedin.comThat's wasn't convenient.
Thing is, I have to look at the big picture, i.e. what is best in my opinion for a majority of users. I just wish we all have this bigger picture in mind when requesting features. I do go once in a while on a google search to find out the unformal feedback about the extension. And one thing that sticks out in my mind is people aren't too sure how to use it optimally. To fix that is to avoid having so many settings that users end up uneasy about whether they are using it properly or not. I am trying to figure how to fix that.
In block-all/allow-ex mode, scopes are exceptions, so the exceptional step is to click to create one. In allow-all/block-ex mode, scopes are irrelevant.
If ever a user want to whitelist a whole page, which is the typical case of having a scope when working in block-all/allow-ex mode, that would be ctrl-A, which will always create a scope in such case if none exists (I could add an icon button for this one since the ABP icon is gone).
gorhill commentedon Jul 22, 2014
Disagreed. There is
css/img, and if whitelisting theallcell, happy to have it blacklisted expressly.I decided to address things this way now: there is a scale: sites broken = less users, sites not broken = more users. So I am addressing things from that perspective. uBlock breaks less than uMatrix allow-all/block-ex which breaks less than uMatrix block-all/allow-ex. To not overcomplicate for the majority of users, in order to not discourage but rather nurture good privacy/security habits.
uMatrix will never become less powerful, I just want to make it more accessible to more. Too many settings which are meaningful to only one end of the scale. Auto-scope creation is useful only to block-all/allow-ex, and only a portion of those users of that mode, and even for those users, it can get in the way sometimes.
gorhill commentedon Jul 24, 2014
Currently working on this. uMatrix won't come out without this. It's a huge amount of code to rewrite, but it's the aspect of HTTPSb which bothers me the most. It will be definitely fixed, I can't tell how long it will take.
stormy-henderson commentedon Jul 24, 2014
I have extensively customized and then ditched HTTPSB several times. I've decided the only way I can use it and be happy is to block-all/allow-ex and then auto-create & auto-whitelist the page domain for JS/XHR. This lets me browse 95% of pages without errors and only edit the matrix when I need cookies or shopping carts, while still blocking all the third-party junk.
Will losing "Auto create temporary {domain|site}-level scope" mean we lose auto-whitelisting of the page domain?
And while I have often had to do the annoying changing-scopes dance you describe above to allow or block something globally, I far more often want to edit the matrix for the page domain that I am browsing, and having the matrix display the page domain by default makes for the easiest & quickest use, and is more likely to encourage correct usage by new users than default global scope.
I still believe a layered, inheriting matrix is needed for this software to work most powerfully and understandably (see #227).
Thanks for the great extension!
gorhill commentedon Jul 24, 2014
I currently use the matrix in allow-all/block-ex, except I blacklist cookie, XHR and frame in global scope. Whenever I land on a site which I want to unbreak for good, it is quite trivial to:
As of now it's really the easiest way I have found to surf with good peace of mind, little breakage, and where breakage exists in need of unbreakage, it is trivial. This is my whole point: I figure this way HTTPSB becomes more within reach of people who are less tolerant of site breakage.
I am trying to lower the annoyance point at which less tolerant users give up on a tool beneficial for them. This is just an undeniable reality: hardcore users who block-all/allow-ex by default have a higher tolerance to security/privacy tool annoyance, I am trying to help the ones who have a lower tolerance so they can benefit from such tool too.
gorhill commentedon Jul 25, 2014
Look, all can be changed afterward according to feedback etc. It's a fork, HTTP Switchboard will still be there. I just want to take steps back and focus on people who could probably use it, but got confused by the plethora of choices right off the bat.
They benefit in the way of them not ending wondering whether they should use it or not. One middle way solution would be to have an advanced button which would unveil more settings which would be more suitable to advanced users.
I want to provide a basic setup which will not scare away new users. That the extension "takes time to figure" is the most common comment I see. That bothers me because I know it's possible to make it a "work out of the box" extension with little site breakage. (Ex: http://www.nsaneforums.com/topic/224243-list-your-favorite-extensions-and-add-ons/page-2#entry816356)
I just want current advanced users to take a more altruistic view and work with me to bring this tool to more people, there is so much to benefit from it. That means forgetting about our own pet habits as advanced users and trying to help those who would like to use it but feel like they need to take a course to use it.
3 remaining items
gorhill commentedon Jul 26, 2014
Well, the people who abandoned early because of perceived complexity aren't going to show up here to be counted.
hrj commentedon Jul 26, 2014
Good point, but that could fly either way. Those who abandon it for lack of configurability / privacy might not show up too. I hope that those who show up, do count :)
mikhaelkh commentedon Jul 29, 2014
@gorhill uMatrix & HTTPSB have some other common subscriptions: malware domains, various hosts lists that have only domains. They are better have enabled only in HTTPSB? Also, in uBlock you can add that Fanboy Annoyances includes Fanboy Social (proof) and BitBlock includes most of Fanboy Annoyances (proof).
gorhill commentedon Jul 29, 2014
uMatrix will have only hostname-based lists.
mikhaelkh commentedon Jul 30, 2014
@gorhill, in uBlock, of course. Fixed previous comment)
gorhill commentedon Jul 31, 2014
I will throw some ideas just for the purpose of keeping track of these for myself, as I tend to forget often when busy with other stuff.
So re. "auto creation of scope":
gorhill commentedon Aug 1, 2014
I'm committing 100% to the idea of layering as was expected in issue #227. Other users also expected layering when using HTTPSB.
It's really what you see is what you get. If you explicitly blacklist a cell in global scope, the rule will be in global scope. Scopes above will see that rule, unless they have their own explicit rules for that cell.
Layering already exists actually, this is how ubiquitous rules are implemented. So whatever issues you may see with what is proposed above, is probably present if you consider existing ubiquitous rules.
In layering, for each cell, the three scopes are visited to determine the state of the cell. Than if after all this the cell is evaluated as gray, the usual matrix-based inheritance algorithm is applied.
No, the cell which you tampered with will override whatever is in broader scopes for that same cell.
gorhill commentedon Aug 1, 2014
Also by the way, given the way I now plan to implement scopes etc as described above, I have furtehr thought:
The auto-whitelist feature will always apply to the narrowest scope, just like it is currently the case if you whitelist through [Alt-A].
Also, as said, the three scopes always exist at all time, so the scope which will appear when you bring up the matrix will just be the last one which was active last time you accessed the matrix. So if a user tampers mainly with site-level scopes, the automatically selected scope will be site-level.
broomdodger commentedon Aug 20, 2014
When (approximately) are you planning to release uMatrix?
Will uMatrix replace HTTPSB?
Will it have its own github?
I think uMatrix is a great idea and name.
gorhill commentedon Oct 28, 2014
Forgot to update this: µMatrix alpha released.
RandomAcronym commentedon Oct 30, 2014
as someone who has tried to use HTTPSB and given up multiple time this sounds like an awesome idea; I love the work you're doing here gorhill.
I never noticed you can change to global policies from the popup window, or that you needed to save the temporary policies to make them permanent until after reading the thread and trying uMatrix.