Content filtering via subresource filter

[kreativK]

Altough discussions in the discord has deemed it a slightly worse option than Vanadiums approach, Braves adblock-rust https://github.com/brave/adblock-rust/ could be an alternative.

[RKNF404]

If using the DNS route (arguably the most secure), we do have some options. But it would require setting a default DNS provider which may not be ideal?

[RoyalOughtness]

I don't think it makes sense to separate the browser's DNS from the system dns. If the user wants to do DNS filtering, they can do it globally. I'm also skeptical of the effectiveness of dns filtering relative to vanadium's approach.

[RKNF404]

Well, it gives the advantage of ECH, which you cant get in automatic mode. You are right, DNS isnt as strong as local filtering but it can block significantly more domains with little performamce loss or security risk. Prior to the current Vanadium approach, it was the recommened method.

Late edit: also safe browsing, which there currently is nothing in its place, DNS provides way more robust safe browsing aka malware blocking.

[RoyalOughtness]

I agree with the advantages of DNS filtering, I just don't think it should be a browser default for two reasons. One is we'd be circumventing system-level or even network-level DNS configuration. Ideally, the user would be setting DNS for their entire lan, or if they don't have control over that, their entire system. The second reason is that it would require us to set a specific dns provider as default, which means if users want to use their dns provider of choice, they might lose out on filtering.

in short, I think it would be valuable to support filtering without sacrificing the feature that allows the user to set the DNS provider.

[RKNF404]

If we are going for secure and more private by default? I think a browser based DNS would be better, simply because of ECH. You pretty much cannot get that with automatic mode. Not like this would be mandatory, users can disable it or switch to auto, but as a default I think it makes sense. Especially if they do not have a network based DNS filter (my case), or did not setup a system DNS (likely the case of many).

[RoyalOughtness]

Right but if users disable it or choose a different dns, they lose out on filtering.

ECH is good, but I don't see how it relates to content filtering.

[RoyalOughtness]

What I'm saying is: we could even set a default dns provider with dns filtering and ECH, and I would still think we need a content filtering feature

[RoyalOughtness]

also, as far as I know ECH is more of a privacy feature than a security feature, and "more private by default" is out of scope

[RKNF404]

I don't see how it relates to content filtering.

Its just another benefit, on the topic of enabling a default DNS. Just something extra to consider, anyway.

Right but if users disable it or choose a different dns, they lose out on filtering.

If they disable it, its likely because they dont want the filtering or want a system filtering thing. So it would make sense.

we could even set a default dns provider with dns filtering and ECH, and I would still think we need a content filtering feature

Obviously, I was gonna say use both, its the best of both worlds. They are not mutually exclusive, I still agree that the Vanadium approach is best, or something like it, but DNS complements it.

also, ECH is more of a privacy feature than a security feature, and "more private by default" is out of scope

It does prevent some level of network attacks similar to DoH/DoT (just not so significantly to warrant calling it a security feature), but private by default is a benefit. Btf, content filtering is more of a privacy/convenience thing. By private by default I mean using existing tools in the browser, not extending on privacy already offered.

[RoyalOughtness]

I don't see how it relates to content filtering.

Its just another benefit, on the topic of enabling a default DNS. Just something extra to consider, anyway.

Sure, it's just already there.

Right but if users disable it or choose a different dns, they lose out on filtering.

If they disable it, its likely because they dont want the filtering or want a system filtering thing. So it would make sense.

The DNS toggle shouldn't also be a filtering toggle, that's my point.

we could even set a default dns provider with dns filtering and ECH, and I would still think we need a content filtering feature

Obviously, I was gonna say use both, its the best of both worlds. They are not mutually exclusive, I still agree that the Vanadium approach is best, or something like it, but DNS complements it.

Right but the DNS piece is already there. Users who want to set cloudflare and use ECH can do so right now

also, ECH is more of a privacy feature than a security feature, and "more private by default" is out of scope

It does prevent some level of network attacks similar to DoH/DoT (just not so significantly to warrant calling it a security feature), but private by default is a benefit. Btf, content filtering is more of a privacy/convenience thing. By private by default I mean using existing tools in the browser, not extending on privacy already offered.

The advantage of built-in content filtering is to eliminate the need for extensions and ultimately remove support for extensions by default, which is ultimately a security feature

[RoyalOughtness]

speaking of privacy, if we ended up choosing a dns provider it would open up a can of worms about researching which dns provider is best and all that stuff. I don't think we want to be in the business of making those decisions for users.

[RKNF404]

The DNS toggle shouldn't also be a filtering toggle, that's my point.

Fair, but it is more configurable, or we could just set one that blocks only malware as a safe browsing alternative so that it isn't a filtering toggle (for ads that is).

Right but the DNS piece is already there. Users who want to set cloudflare and use ECH can do so right now

Not sure I understand the point. Are you saying we dont need the default because the user can do that already?

The advantage of built-in content filtering is to eliminate the need for extensions and ultimately remove support for extensions by default, which is ultimately a security feature

Fair, the advantage of a default DNS is similar (to lesser degree), except that it also adds any advantage of secure DNS.

speaking of privacy, if we ended up choosing a dns provider it would open up a can of worms about researching which dns provider is best and all that stuff.

we can keep it to recongized DNS providers (Mullvad, Controld, Cloudflare, Quad9, etc.).

I don't think we want to be in the business of making those decisions for users.

fair, ultimately your call. I did do a lot of research into this already for my own purposes. Besides, DNS is mandatory, so by choosing a notable provider it helps users who are potentially unaware.

[RoyalOughtness]

Also of note is that as far as I know, Vanadium didn't consider DNS filtering, probably for similar reasons. GOS also doesn't ship a default DNS provider and neither does secureblue

[RKNF404]

Also fair. Could do it temporarily, as an extension alternative?

And while Vanadium didnt do it, they did recommend it. Also they do prefer to use Cloudflare where they can iirc.

[RoyalOughtness]

The DNS toggle shouldn't also be a filtering toggle, that's my point.

Fair, but it is more configurable, or we could just set one that blocks only malware as a safe browsing alternative so that it isn't a filtering toggle (for ads that is).

What I'm saying is that if the user selects a custom DNS without filtering, they will lose out on content filtering. So in practice the DNS toggle would also be a filtering toggle

Right but the DNS piece is already there. Users who want to set cloudflare and use ECH can do so right now

Not sure I understand the point. Are you saying we dont need the default because the user can do that already?

I'm saying they are orthogonal design decisions

The advantage of built-in content filtering is to eliminate the need for extensions and ultimately remove support for extensions by default, which is ultimately a security feature

Fair, the advantage of a default DNS is similar (to lesser degree), except that it also adds any advantage of secure DNS.

Let me restate what I was trying to get at. Ultimately, we're trying to secure the browser. I put "Any novel functionality that is unrelated to security" as out of scope so that the scope doesn't creep away from us.

So then the question that follows from that is, why is this issue even open since this is novel functionality that's ostensibly unrelated to security? The answer is that it's open purely because doing so enables us to remove extension support by default. So when you're talking about other advantages that don't get us closer to that goal, you lose me.

speaking of privacy, if we ended up choosing a dns provider it would open up a can of worms about researching which dns provider is best and all that stuff.

we can keep it to recongized DNS providers (Mullvad, Controld, Cloudflare, Quad9, etc.).

I don't think we want to be in the business of making those decisions for users.

fair, ultimately your call. I did do a lot of research into this already for my own purposes. Besides, DNS is mandatory, so by choosing a notable provider it helps users who are potentially unaware.

I believe that you've done a lot of research on it, but eventually other people who claim the same will come and insist that their research points to a different provider being a preferred default.

Litigating a DNS debate, all because we wanted to remove extension support by default, sounds like a nightmare

[RoyalOughtness]

Also they do prefer to use Cloudflare where they can iirc.

Where did you see that?

GOS defers to the DHCP provided server as does vanadium.

Which frankly is the right decision so as to not avoid the anti-pattern of having individual machines or even worse, individual applications, decide which dns to use.

[RKNF404]

What I'm saying is that if the user selects a custom DNS without filtering, they will lose out on content filtering. So in practice the DNS toggle would also be a filtering toggle

A, I see, yeah that would be a limitation, I agree. I still think it is better than extensions though.

Let me restate what I was trying to get at. Ultimately, we're trying to secure the browser. I put "Any novel functionality that is unrelated to security" as out of scope so that the scope doesn't creep away from us. So then the question that follows from that is, why is this issue even open since this is novel functionality that's ostensibly unrelated to security? The answer is that it's open purely because doing so enables us to remove extension support by default. So when you're talking about other advantages that don't get us closer to that goal, you lose me.

I see. I was just stating extra reasons to consider it. I will try to remain in scope in this regard from now on, ie about content filtering and security. Some are arguments in favor of setting a default DNS, I would say they are important to consider as well. But I will refrain from further reference to them.

Then I would say using a default DNS is better anyway, since it is infinitely more secure than any content filtering option (as it doesn't reduce security at all or offer any risk, since DNS is mandatory anyway, you are just shifting trust and adding filtering). While it breaks impartiality by setting a browser level preference for a specific service you can make a similar argument for filter lists (not to the same level, but still to a point). If we are talking pure security though, DNS is little loss for similar gain.

I believe that you've done a lot of research on it, but eventually other people who claim the same will come and insist that their research points to a different provider being a preferred default. Litigating a DNS debate, all because we wanted to remove extension support by default, sounds like a nightmare

By deciding to disable extensions, you litigate another debate. Similarly, by opting for whatever filter lists another debate is raised. I think these come with territory. And, my research is just a basis to work from plus I may have bias, it would be better to get multiple opinions on that kind of thing.

Where did you see that?

"GrapheneOS replaces Google Public DNS with Cloudflare DNS for the fallback DNS servers due to the superior privacy policy and widespread usage including as the fallback DNS servers in other Android-based operating systems." https://grapheneos.org/faq#default-dns Should've been more clear, I am aware they do not set a default DNS, just prefer Cloudflare where it is needed.

[RoyalOughtness]

But I will refrain from further reference to them.

I'm not saying not to reference it :smile: it's just orthogonal to this issue.

since it is infinitely more secure than any content filtering option

I don't see why this would be the case. It's not like we're adding a content filtering engine, we'd for example be using the built-in one.

it doesn't reduce security at all or offer any risk,

We'd be introducing an anti-pattern by default and circumventing DHCP-defined dns.

By deciding to disable extensions, you litigate another debate.

Not at all similar. Disabling extensions is an objective security benefit. Preferred DNS provider is highly subjective and based on second hand information about the practices of a third party. They couldn't be more different.

Similarly, by opting for whatever filter lists another debate is raised.

Not if we use brave's adblock-rust, for example

Should've been more clear, I am aware they do not set a default DNS, just prefer Cloudflare where it is needed.

Yeah, overriding a fallback and setting a default dns are entirely different.

[RKNF404]

I'm not saying not to reference it

Still, it bloats the discussion.

I don't see why this would be the case. It's not like we're adding a content filtering engine, we'd for example be using the built-in one.

We add filter lists, from whatever sources. Arguably attack surface, not alot but not zero.

We'd be introducing an anti-pattern by default and circumventing DHCP-defined dns.

What is the security risk? DHCP defined dns typically lacks DNSSEC validation (at least in my region).

Not at all similar. Disabling extensions is an objective security benefit. Preferred DNS provider is highly subjective and based on second hand information about the practices of a third party. They couldn't be more different.

Not entirely the same, my point is it still adds people who want their own ideas pushed. I doubt zero people will complain about no extensions. Thats the only point, I still think it should be done but it shouldnt be deterant just because of people trying to one-guy, or sparking discussions.

Not if we use brave's adblock-rust, for example

True, but that introduces security risk. Even still, there would be requests to add more lists, or remove lists, or configure this that way, etc. This isn't a binary decision either, it is complex is my point.

Yeah, overriding a fallback and setting a default dns are entirely different.

My bad. You are right. But it breaks impartiality, I doubt no one asked for whatever other DNS to get added in Cloudflare's place.

[RoyalOughtness]

We add filter lists, from whatever sources. Arguably attack surface, not alot but not zero.

Perhaps ironically, I made this same point to GOS folks about their configuration app when they were developing it and they made a compelling case as to why it wasn't a source of attack surface. I can dig it up.

What is the security risk? DHCP defined dns typically lacks DNSSEC validation (at least in my region).

It's an anti-pattern not a security risk. DNS overrides should be set at the highest level possible. Ideally, on LAN DHCP.

I doubt zero people will complain about no extensions.

Right but the reason for maintaining a clear scope declaration is so that complaints like this can be addressed clearly and objectively. "Hey I don't like this change!" can be addressed with "It's clearly in scope and can still be overriden". Being in the business of choosing a default dns is far more nebulous and subjective

True, but that introduces security risk. Even still, there would be requests to add more lists, or remove lists, or configure this that way, etc. This isn't a binary decision either, it is complex is my point.

Agreed, that makes me want to just defer to UBO-Lite though :smile: Is there a way we can build it into the browser itself and then block remote extension installation? :smile:

[RoyalOughtness]

I was partially joking but it looks like it is possible :open_mouth:

https://stackoverflow.com/questions/50125821/standard-way-to-build-a-chrome-extension-into-chromium

[RKNF404]

Perhaps ironically, I made this same point to GOS folks about their configuration app when they were developing it and they made a compelling case as to why it wasn't a source of attack surface. I can dig it up.

I would be very interested in that. Why would it not be?

It's an anti-pattern not a security risk. DNS overrides should be set at the highest level possible. Ideally, on LAN DHCP.

Sure, but that isn't common. And again, you lose certain features only the browser offers. It also loses on convenient configurability. If users have a DNS preference, they can set it themselves.

Right but the reason for maintaining a clear scope declaration is so that complaints like this can be addressed clearly and objectively. "Hey I don't like this change!" can be addressed with "It's clearly in scope and can still be overriden". Being in the business of choosing a default dns is far more nebulous and subjective

I mean, you can define scope based on privacy policy, filtering ability, and connection security, none of which are subjective. But I see the point, it would require adding more scope just for what makes a good DNS provider. I can definitely write that, but again to avoid bias that would not be ideal.

Agreed, that makes me want to just defer to UBO-Lite though 😄 Is there a way we can build it into the browser itself and then block remote extension installation? 😄

Ehhhhhhh

I was partially joking but it looks like it is possible 😮

Ehhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

I would prefer the Vanadium way. Also, that requires maintaining the version of uBOL, and that still adds some attack surface since it is still an extension, and also how update? It adds too much extra stuff. Braves abr, Vanadium's integrated filtering, and DNS are all much simpler imo.

[RoyalOughtness]

I would be very interested in that. Why would it not be?

https://github.com/GrapheneOS/Vanadium/pull/453#discussion_r1493285868

define scope based on privacy policy, filtering ability, and connection security,

Other way around. I'm talking about the scope for this project, not DNS. To write parameters about what DNS to use is to expand the scope of this project.

Ehhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh I would prefer the Vanadium way.

I do too, hence I was half joking :smile:

[RKNF404]

https://github.com/GrapheneOS/Vanadium/pull/453#discussion_r1493285868

I see.

Other way around. I'm talking about the scope for this project, not DNS. To write parameters about what DNS to use is to expand the scope of this project.

I undertand. Could stay on scope by defining security and filtering boundaries.

[RoyalOughtness]

It might be worthwhile to see if GOS folks can elaborate on their rationale for going the route that they did. If they're willing to, since they're busy.

I suspect their reasons are similar to the ones I've elaborated above, but I'm not certain.

Regardless, I think we should sleep on this for awhile since it's not urgent and UBO-lite suffices in the meantime, while we gather additional input from GOS folks.

[RKNF404]

Sure, I just dont want to keep jumping to them for stuff like this. Feels like that happens a lot lol.

Also yeah, none of this is like tomorrow urgent.

[RoyalOughtness]

Sure, I just dont want to keep jumping to them for stuff like this. Feels like that happens a lot lol.

What do you mean? I'm inclined to go with their approach regardless.

[RKNF404]

Of course, nevermind. Wrong mindset.

[RoyalOughtness]

Of course, nevermind. Wrong mindset.

What? :smile:

[RKNF404]

I'm terrible at communicating thoughts. My bad.

Just dont mind me... or my last few comments.

[RoyalOughtness]

No worries, I just wasn't sure what you meant. At least in secureblue we rarely if ever ask GOS folks for a consult, but occasionally they will chime in on issues of their own accord.

Maybe you meant other projects ask them for consults frequently? I wasn't sure but maybe you're more involved with GOS than me.

[RKNF404]

Ok, to be fair, I have been contributing here for a short period of time (like 2 weeks, maybe 3). Since that point, there has been like 3 situation where Vanadium/GOS was used for consult. It just feels frequent. I won't further elaborate here, since this is pretty off topic, but I hope that makes sense.

[idnovic]

Hi,

I would just like to add my view.

Ad block extension is okay with me but I do not use one. I prefer the DNS option to block domains.

I think this should be communicated. Default could be DHCP DNS and it is a sane default config. Let the user decide. Offer a predefined list of options. User can choose the DNS service from the list or add own config.

Only a few DNS providers offer malware protection. I suggest to only offer the once that do as option. And only those with global multicast. I can only see Quad9 and DNS0.eu as real contenders. Optionally nextdns if the user wants more control over the blocklist. I am using nextdns.

I think the secureblue system should be forced to use the set up DNS. I do not aupport a different DNS endpoint for chromium and system. A port 53 firewall rewrite to the local resolver could force every non DoT or DoH request to be encrypted by default on the system via the system DNS resolver.

System DNS resolver could be set up to use DHCP DNS or from the predefined list.

[RoyalOughtness]

@idnovic That's a great idea, we could even incorporate it into yafti directly so that on first install, users are prompted to optionally select their dns provider.

That way, the whole system will use that including chromium and will benefit from dns filtering if the user selects a provider that filters.

And then we can potentially do vanadium-style content filtering as well on top of that

@idnovic Do you mind opening an issue on secureblue for this? I think it would be a value add. Something like "User-configurable DNS via yafti on first rebase"?

[RKNF404]

I suggest to only offer the once that do as option. And only those with global multicast. I can only see Quad9 and DNS0.eu as real contenders.

Controld, Mullvad, Cleanbrowsing, Cloudflare, and many others have safe browsing options, Quad9 and DNS0 arent the only ones neither the best options.

I do not aupport a different DNS endpoint for chromium and system.

Why so?

[idnovic]

Yes. I can open an issue tomorrow.

@idnovic That's a great idea, we could even incorporate it into yafti directly so that on first install, users are prompted to optionally select their dns provider.

That way, the whole system will use that including chromium and will benefit from dns filtering if the user selects a provider that filters.

And then we can potentially do vanadium-style content filtering as well on top of that

@idnovic Do you mind opening an issue on secureblue for this? I think it would be a value add. Something like "User-configurable DNS via yafti on first rebase"?

[idnovic]

I suggest to only offer the once that do as option. And only those with global multicast. I can only see Quad9 and DNS0.eu as real contenders.

Controld, Mullvad, Cleanbrowsing, Cloudflare, and many others have safe browsing options, Quad9 and DNS0 arent the only ones neither the best options.

I do not aupport a different DNS endpoint for chromium and system.

Why so?

That is true. It really depends on the end users opinion. I just prefer these 3 DNS services.

Because now you need to trust two different DNS providers. It is also more complex. And opens the possibility of misconfiguration. Browser blocks ads. User thinks everything is protected but the system itself uses the garbage DNS resolver from ISP.

It is simpler if everything is forced to use one DNS. User can optionally use the chromium settings to choose an other DNS provider if they choose to do so.

[RKNF404]

That is true. It really depends on the end users opinion. I just prefer these 3 DNS services.

Fair enough.

Because now you need to trust two different DNS providers.

Sure, but if we are discussing security of adblocking solutions, this would be the way. You still use your ISP for DNS lookups, for your current DNS hostname. That is also not necessarily the case if you use the same provider for system and browser (like I do).

It is also more complex. And opens the possibility of misconfiguration.

It is exactly one extra variable, complex how? Misconfigure what? Setting a DNS for the system by force is harder to undo, and even more so for a network-wide DNS. Browser level is the simplest. Making that choice for the user is the easiest at the browser level.

Browser blocks ads. User thinks everything is protected but the system itself uses the garbage DNS resolver from ISP.

Most of the risk of insecure DNS revolves around the browser, when talking about adblocking. Again, you still use your ISP for some limited lookups.

It is simpler if everything is forced to use one DNS.

Not by a lot, in my opinion. And even then, you can use one provider. To be fair, in my setup I use 2 different configurations for system and browser but both from Controld.

[RoyalOughtness]

@RKNF404 I've been thinking about this some more and have the following proposal. Let me know what you think:

1. We will repurpose the first run view to display a "choose your DNS provider" dropdown. This dropdown will have selected by default a DNS provider that supports every security mechanism a DNS provider can (DNSSEC, DoT, ECH). It will make clear in the list of providers which ones support which mechanisms. It will also leave "OS provided DNS" as an option. This forces the user to acknowledge the behavior at first run and override it if they choose, so users aren't blindsided by their browser DNS suddenly changing

2. We will also implement a Vanadium-style subresource filter, with a global and per-site "Block Ads" toggle

3. In secureblue, we will add an DNS picker similar to 1. but for the entire OS.

This will be more work but I think it "covers all the bases" best.

[RKNF404]

@qoijjj

1. We will repurpose the first run view to display a "choose your DNS provider" dropdown. This dropdown will have selected by default a DNS provider that supports every security mechanism a DNS provider can (DNSSEC, DoT, ECH). It will make clear in the list of providers which ones support which mechanisms. It will also leave "OS provided DNS" as an option. This forces the user to acknowledge the behavior at first run and override it if they choose, so users aren't blindsided by their browser DNS suddenly changing

Definitely for the best, I agree. Thinking about it a more, a universal default DNS would be a hassle, even as a short term solution.

2. We will also implement a Vanadium-style subresource filter, with a global and per-site "Block Ads" toggle

No doubt. There is already an Ads site toggle. Vanadium repurposes it for their own content filtering, we can do the same.

3. In secureblue, we will add an DNS picker similar to 1. but for the entire OS.

Makes sense. This could be integrated with 1. where it will optionally set a browser policy with said DNS provider (if they support both DoH for the browser and DoT for the system). Just as an extra suggestion.

This will be more work but I think it "covers all the bases" best.

Sounds good, 100% on board.

[RoyalOughtness]

This could be integrated with 1. where it will optionally set a browser policy with said DNS provider (if they support both DoH for the browser and DoT for the system). Just as an extra suggestion.

Agreed, and I'm not sure exactly what the details would look like in terms of how the relationship would be between the OS dns and the browser dns. As in, when setting the OS DNS, we might also want to override chromium to use the OS DNS option at that time.

But those are details we can get to later

For now I'll open new issues for each of the above three

[RoyalOughtness]

https://github.com/secureblue/hardened-chromium/issues/64 https://github.com/secureblue/hardened-chromium/issues/64

[RKNF404]

As in, when setting the OS DNS, we might also want to override chromium to use the OS DNS option at that time.

I was thinking user's choice, and if the user chooses to override the browser it sets the policy. Otherwise browser's choice. But yeah, finer details.