15 ms·

IMO the genius of uMatrix was that Raymond realized that an in-browser requests firewall should have two dimensions, instead of one: (1) the (sub-)domains that

IMO the genius of uMatrix was that Raymond realized that an in-browser requests firewall should have two dimensions, instead of one: (1) the (sub-)domains that the requests pointed at, and (2) the type of request (i.e. cookie, image, XHR, etc). Now, obviously you could always write an ABP compatible filter that could block any combination of these two, but that's hard. What uMatrix did is present the underlying complexity in a way that's easy to intuit for a power user, giving you point-and-click request filtering power over both domains simultaneously. For that reason, I'm skeptical that uMatrix can be replaced with a traditional blocker, not even one with an advanced mode like uBo, because it simply doesn't allow the specificity that a two-dimensional model like uMatrix did. That makes uMatrix's being archived incredibly tragic and a great loss for the web. I hope someone as trustworthy and competent as Raymond will pick it up in the future, and I thank him for all his work on it up to this point.

aembleton 6y ago
> you could always write an ABP compatible filter that could block any combination of these two I don't think you can for cookies. You can block cookies in the browser, but I'd like a filter list so that it is possible to change across all my browsers by subscribing to the same filter list.
deleted 6y ago
[deleted]
cookiengineer 6y ago
This is so true, the two dimensions allow such a nice simplification of what should be rendered even in UX terms. What I personally didn't like about it though are the tech specific parts (e.g. xhr and other both require script anyways, as not a single website will work with xhr disabled). So for my browser project [1] I decided to split it up into "text", "image", "audio", "video" and "other" which I hope will make more sense for most people. Back in February when the debate about the manifest and requests api started, I started my own semantic browser project which aims to filter out all UX-interfering CSS and HTML and probably won't allow JS anyhow. It tries to focus on the automation and caching parts that are broken in current web browsers, so that everything is peer to peer, and that other trusted peers can be used to share bandwidth, content, or metadata with each other and that each one has a 100% persistent local cache that only gets refreshed once the user tells the browser to. If there'll be a need to support webapps later, they will probably be sandboxed in a new window that represents a temporary cache located in /tmp/... in order to prevent abuse of local storage and cookies. I've learned to not trust any site these days, even my bank's website uses foreign overseas-located trackers, which is technically a GDPR violation. [1] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth
- liability 6y ago
  > not a single website will work with xhr disabled That's total nonsense. I browse with uMatrix blocking everything by default and I rarely need to enable xhr to make a site work. Most of the time it's only used to bloat a site, not deliver the actual content. The same is mostly true of javascript as well. This is particularly true on newspaper websites. A great many news sites are reasonable with everything disabled but utter cancer by (typical) default.
  - cookiengineer 6y ago
    > That's total nonsense. Well, maybe we have a different pool of websites we visit. But usually, in my case, pretty much all websites built with vue.js, react, angular and others usually don't have server side rendering implemented correctly. Just as an example, what I visited just yesterday: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472 https://portal.msrc.microsoft.com/en-US/security-guidance/ad... Doesn't contain content, it's just a blank page without the XHR request. And all webapps I've seen so far basically just scaffold all polyfills and stuff, without any kind of content being delivered (or serialized) inside the HTML. Additionally, all newspaper websites that I've seen in my country blank out everything with white-on-white if you don't allow JS with XHR. Either that or the article teaser is faded out with an overlayed blur image. Well, that is at least when you don't set the user-agent to Googlebot :)
    - liability 6y ago
      Yeah man I'm talking about really obscure websites like The New York Times which works great without any javascript enabled. https://0x0.st/ilMO.png https://0x0.st/ilMO.png
      - Cyphase 6y ago
        It looks a lot better if you allow CSS and images from *.nyt.com. A bunch of images still won't load, but the layout and some images are there.
    - 6y ago
derefr 6y ago
How do you feel about a model like NoScript’s, where origins are labelled with tags (trusted/untrusted/default, but in theory you could have arbitrary tags), and then request rules are applied to the tags, rather than to origins directly?
- bscphil 6y ago
  I have to admit I haven't used NoScript since well before the version 10 UI changes. Prior to that it was definitely "one-dimensional" and didn't really offer the features of uMatrix. Now, I'd say (just judging by screenshots and the user guide) that it's about half way there, allowing you to look at a list of subdomains and set each one to a category. (The guides don't seem to clearly state that this only affects your current site, allowing you to have different source<->host combinations be allowed or disallowed, but I assume this is the case.) However, the tagging model seems so limited compared to what uMatrix can do. uMatrix has 8 different requests types, so you'd need 2^8=256 different tags to cover every combination of requests to a subdomain. And that's if NoScript can block cookie requests at all: 90% of even the domains I fully trust have cookies blocked in uMatrix, simply because the sites don't actually need cookies to function. Maybe I would need yet another extension for that. Also, however, part of what I wanted to get at in talking about the brilliance of uMatrix was the way the interface made very precise controls easy, just a point and click operation. Maybe it's possible to get a similar amount of power with a tool like NoScript, but as far as I can tell the usability of the interface just doesn't come close.
- deleted 6y ago
  [deleted]
daveFNbuck 6y ago
It's actually 3 dimensions, as any selections you make in that UI only apply to the site you're currently visiting.
- cookiengineer 6y ago
  > It's actually 3 dimensions, as any selections you make in that UI only apply to the site you're currently visiting. Well, technically that is only partially true as the third dimension is the (sub-) domain scope or "*" which can be reflected behind the scenes with the first-party settings for the origin's domain for each request type because it has the identical effect.
  - Drdrdrq 6y ago
    It's still a third dimension, it just doesn't have that many values.
  - daveFNbuck 6y ago
    That's not how it works for me. When I enable ajax for one site, it doesn't enable for other sites. I guess I have an option checked somewhere.
  - tremon 6y ago
    No, it's a full dimension. That you can't see it in the GUI is because the GUI is already scoped to the currently-active url, and you can only control the specificity of the rules, as you say. But if you view the rules, you'll see its three dimensions spelled out: * * * block * * script block * 1st-party * allow stackexchange.com sstatic.net * allow stackexchange.com cdn.sstatic.net script allow This is full [source domain] [target domain] [request type] flexibility. The GUI will only show the stackexchange rules above when you're actually visiting that site; it doesn't mean the third dimension is fake.
- bscphil 6y ago
  Maybe its most useful to think of this as sort of an "isometric" 3D rendering, because this extra dimension is usually only exposed to the user modally: the third dimension is whatever site you happen to be visiting at the present time. By 2D I was mostly referring to the interface, which is a "matrix", and commenting on how that particular metaphor makes managing a complex request blocker a much better experience.
parsimo2010 6y ago
It definitely can’t be replaced by a traditional blacker. All the blockers for Safari are one step above worthless, and have been since they changed their plugin architecture.
- acdha 6y ago
  It’s interesting that you make this claim when the hostname & type scheme described above is what Safari uses. Can you explain what’s different?
  - parsimo2010 6y ago
    Disclaimer: I don't develop ad blockers or any other plugins, and the change I'm actually the maddest about is that uBlock Origin stopped working when Apple stopped supporting WebExtensions. I may be less mad about uMatrix simply because it wasn't on Safari in the first place. I'm not 100% sure on the reason why uMatrix wasn't available on Safari, but I think it's because content blockers aren't allowed to see any user data. Ad blocking plugins just send a list of content to block to the content blocking API, and Safari does all the blocking and doesn't send any data to the plugin. So uMatrix's intuitive UI that GP was talking about isn't possible. Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. In typical Apple fashion, they decided what was best for me when (AFAIK) I've never had a problem with an untrustworthy plugin stealing my information. It might technically be possible to functionally implement uMatrix with multiple plugins (one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API) but all the plugins I've seen don't do it. Maybe it's not possible, maybe the extra development effort isn't worth it to support a single browser that has fairly low usage.
    - acdha 6y ago
      > Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. I’m not sure I’ve seen that - the number of Safari users had been pretty constant on my sites, and the main pressure seem to be the Chrome pushes on Google sites. I think the UI challenges of Safari’s approach are a big problem but on the other hand there were years of people blaming browsers for ABP’s bad performance and users privacy was definitely sold out by unethical developers. As a user it definitely is easier to trust one over the other.
deleted 6y ago
[deleted]

aembleton 6y ago

> you could always write an ABP compatible filter that could block any combination of these two I don't think you can for cookies. You can block cookies in the browser, but I'd like a filter list so that it is possible to change across all my browsers by subscribing to the same filter list.

deleted 6y ago

[deleted]

cookiengineer 6y ago

This is so true, the two dimensions allow such a nice simplification of what should be rendered even in UX terms. What I personally didn't like about it though are the tech specific parts (e.g. xhr and other both require script anyways, as not a single website will work with xhr disabled). So for my browser project [1] I decided to split it up into "text", "image", "audio", "video" and "other" which I hope will make more sense for most people. Back in February when the debate about the manifest and requests api started, I started my own semantic browser project which aims to filter out all UX-interfering CSS and HTML and probably won't allow JS anyhow. It tries to focus on the automation and caching parts that are broken in current web browsers, so that everything is peer to peer, and that other trusted peers can be used to share bandwidth, content, or metadata with each other and that each one has a 100% persistent local cache that only gets refreshed once the user tells the browser to. If there'll be a need to support webapps later, they will probably be sandboxed in a new window that represents a temporary cache located in /tmp/... in order to prevent abuse of local storage and cookies. I've learned to not trust any site these days, even my bank's website uses foreign overseas-located trackers, which is technically a GDPR violation. [1] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth

liability 6y ago
> not a single website will work with xhr disabled That's total nonsense. I browse with uMatrix blocking everything by default and I rarely need to enable xhr to make a site work. Most of the time it's only used to bloat a site, not deliver the actual content. The same is mostly true of javascript as well. This is particularly true on newspaper websites. A great many news sites are reasonable with everything disabled but utter cancer by (typical) default.
- cookiengineer 6y ago
  > That's total nonsense. Well, maybe we have a different pool of websites we visit. But usually, in my case, pretty much all websites built with vue.js, react, angular and others usually don't have server side rendering implemented correctly. Just as an example, what I visited just yesterday: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472 https://portal.msrc.microsoft.com/en-US/security-guidance/ad... Doesn't contain content, it's just a blank page without the XHR request. And all webapps I've seen so far basically just scaffold all polyfills and stuff, without any kind of content being delivered (or serialized) inside the HTML. Additionally, all newspaper websites that I've seen in my country blank out everything with white-on-white if you don't allow JS with XHR. Either that or the article teaser is faded out with an overlayed blur image. Well, that is at least when you don't set the user-agent to Googlebot :)
  - liability 6y ago
    Yeah man I'm talking about really obscure websites like The New York Times which works great without any javascript enabled. https://0x0.st/ilMO.png https://0x0.st/ilMO.png
    - Cyphase 6y ago
      It looks a lot better if you allow CSS and images from *.nyt.com. A bunch of images still won't load, but the layout and some images are there.
  - 6y ago

derefr 6y ago

How do you feel about a model like NoScript’s, where origins are labelled with tags (trusted/untrusted/default, but in theory you could have arbitrary tags), and then request rules are applied to the tags, rather than to origins directly?

bscphil 6y ago
I have to admit I haven't used NoScript since well before the version 10 UI changes. Prior to that it was definitely "one-dimensional" and didn't really offer the features of uMatrix. Now, I'd say (just judging by screenshots and the user guide) that it's about half way there, allowing you to look at a list of subdomains and set each one to a category. (The guides don't seem to clearly state that this only affects your current site, allowing you to have different source<->host combinations be allowed or disallowed, but I assume this is the case.) However, the tagging model seems so limited compared to what uMatrix can do. uMatrix has 8 different requests types, so you'd need 2^8=256 different tags to cover every combination of requests to a subdomain. And that's if NoScript can block cookie requests at all: 90% of even the domains I fully trust have cookies blocked in uMatrix, simply because the sites don't actually need cookies to function. Maybe I would need yet another extension for that. Also, however, part of what I wanted to get at in talking about the brilliance of uMatrix was the way the interface made very precise controls easy, just a point and click operation. Maybe it's possible to get a similar amount of power with a tool like NoScript, but as far as I can tell the usability of the interface just doesn't come close.
deleted 6y ago
[deleted]

daveFNbuck 6y ago

It's actually 3 dimensions, as any selections you make in that UI only apply to the site you're currently visiting.

cookiengineer 6y ago
> It's actually 3 dimensions, as any selections you make in that UI only apply to the site you're currently visiting. Well, technically that is only partially true as the third dimension is the (sub-) domain scope or "*" which can be reflected behind the scenes with the first-party settings for the origin's domain for each request type because it has the identical effect.
- Drdrdrq 6y ago
  It's still a third dimension, it just doesn't have that many values.
- daveFNbuck 6y ago
  That's not how it works for me. When I enable ajax for one site, it doesn't enable for other sites. I guess I have an option checked somewhere.
- tremon 6y ago
  No, it's a full dimension. That you can't see it in the GUI is because the GUI is already scoped to the currently-active url, and you can only control the specificity of the rules, as you say. But if you view the rules, you'll see its three dimensions spelled out: * * * block * * script block * 1st-party * allow stackexchange.com sstatic.net * allow stackexchange.com cdn.sstatic.net script allow This is full [source domain] [target domain] [request type] flexibility. The GUI will only show the stackexchange rules above when you're actually visiting that site; it doesn't mean the third dimension is fake.
bscphil 6y ago
Maybe its most useful to think of this as sort of an "isometric" 3D rendering, because this extra dimension is usually only exposed to the user modally: the third dimension is whatever site you happen to be visiting at the present time. By 2D I was mostly referring to the interface, which is a "matrix", and commenting on how that particular metaphor makes managing a complex request blocker a much better experience.

parsimo2010 6y ago

It definitely can’t be replaced by a traditional blacker. All the blockers for Safari are one step above worthless, and have been since they changed their plugin architecture.

acdha 6y ago
It’s interesting that you make this claim when the hostname & type scheme described above is what Safari uses. Can you explain what’s different?
- parsimo2010 6y ago
  Disclaimer: I don't develop ad blockers or any other plugins, and the change I'm actually the maddest about is that uBlock Origin stopped working when Apple stopped supporting WebExtensions. I may be less mad about uMatrix simply because it wasn't on Safari in the first place. I'm not 100% sure on the reason why uMatrix wasn't available on Safari, but I think it's because content blockers aren't allowed to see any user data. Ad blocking plugins just send a list of content to block to the content blocking API, and Safari does all the blocking and doesn't send any data to the plugin. So uMatrix's intuitive UI that GP was talking about isn't possible. Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. In typical Apple fashion, they decided what was best for me when (AFAIK) I've never had a problem with an untrustworthy plugin stealing my information. It might technically be possible to functionally implement uMatrix with multiple plugins (one to interact with the DOM to figure out what to block, then generate the blocking list, and one to deal with the content blocking API) but all the plugins I've seen don't do it. Maybe it's not possible, maybe the extra development effort isn't worth it to support a single browser that has fairly low usage.
  - acdha 6y ago
    > Apple claimed that they stopped supporting WebExtensions and made the content blocking API in the interest of user privacy, but all it really did was drive users to other browsers. I’m not sure I’ve seen that - the number of Safari users had been pretty constant on my sites, and the main pressure seem to be the Chrome pushes on Google sites. I think the UI challenges of Safari’s approach are a big problem but on the other hand there were years of people blaming browsers for ABP’s bad performance and users privacy was definitely sold out by unethical developers. As a user it definitely is easier to trust one over the other.

deleted 6y ago

[deleted]