Rules with modifier like for example $media shouldn't be applied to apps with disabled HTTPS filtering

[AdamWr]

It seems that now in apps with disabled HTTPS filtering adding rule like this:
*.*$media,important
causes that requests are not blocked.

Steps to reproduce

1. Add this rule:
   *.*$media,important
   or
   *.*$subdocument,important
2. Open any app with disabled HTTPS filtering

Expected behavior

These kind of rules shouldn't be applied to apps with disabled HTTPS filtering, and ad/tracker etc. requests should be blocked.

Actual behavior

All request are passed and not blocked.

Your environment

• AdGuard for Android nightly v3.2.118(CL 1.4.120)

[AdamWr]

By the way, it seems that $empty modifier doesn't work in apps with disabled HTTPS filtering too.

Steps to reproduce

1. Install this app - https://play.google.com/store/apps/details?id=com.mobilefootie.wc2010
2. Add this rule - ||images.fotmob.com^$empty

Expected behavior

Images in app shouldn't load.

Actual behavior

Images load.

[ameshkov]

In fact, that's intended. $emtpy implies that the requests aren't blocked, they are modified. We can't modify responses without https filtering so that's why it shouldn't do anything.

@sxgunchenko what bothers me is why $media -- I don't understand how this rule matched the request in the first place. Internally, HTTPS tunnel request is processed as if it has "DOCUMENT" content type so I can understand how $subdocument matched it, but not $media.

[sxgunchenko]

what bothers me is why $media -- I don't understand how this rule matched the request in the first place.

It matches because we pass any-content-type in matching procedure. So we should pass some set of content types which are applicable for https tunnel requests.

[ameshkov]

It matches because we pass any-content-type in matching procedure. So we should pass some set of content types which are applicable for https tunnel requests.

Yes, we should pass DOCUMENT and then filter our $subdocument and cosmetic modifiers like $elemhide, $content, etc, etc

[sxgunchenko]

core/pull-requests/1435

[AdamWr]

In fact, that's intended. $emtpy implies that the requests aren't blocked, they are modified. We can't modify responses without https filtering so that's why it shouldn't do anything.

One question about that. For example, we have this rule with $empty modifier in Base filter:
||adnxs.com^$empty
If I understand correctly, it means that in app which https filtering is disabled this requests will be not blocked even if we have a blocking rule too ||adnxs.com^ (in Mobile ads filter).
Shouldn't it be somehow checked that if $empty/redirect rule can't be applied in situation like this then apply blocking rule?

Steps to reproduce:

1. Add these rules:

|http$redirect=nooptext,app=APP_NAME
|http$app=APP_NAME

or just

|http$redirect=nooptext
|http

2. Open "APP_NAME"

It will causes that all requests will be not blocked.

[ameshkov]

If I understand correctly, it means that in app which https filtering is disabled this requests will be not blocked even if we have a blocking rule too ||adnxs.com^ (in Mobile ads filter).

No, it should be blocked actually

[ameshkov]

@sxgunchenko could you please check this case?