Add $network basic rules modifier to solve the issue with loading ads through WebRTC #1297

Closed
ameshkov opened this Issue Sep 17, 2016 · 15 comments

Projects

None yet

4 participants

@ameshkov ameshkov added this to the 6.1 R2 milestone Sep 17, 2016
@ameshkov
Member
@ameshkov ameshkov modified the milestone: 6.2, 6.1 R2 Sep 29, 2016
@ameshkov
Member

1755001826 is another way of writing 104.155.51.226

it receives an IP address from the STUN server that doesn't belong to the client - and it uses this IP address to build the pop-up address

@ameshkov ameshkov modified the milestone: 6.1 R3, 6.2 Jan 15, 2017
@ameshkov
Member
ameshkov commented Jan 15, 2017 edited

Here is what I propose.

For standalone programs (including Android and Mac), we can implement a new basic rule modifier, which will block access to a specified ip:port pair.

I suggest to name it network, to emphasize, that it blocks network access to the specified endpoint entirely.

Examples:
174.129.166.49:3478^$network
[2001:4860:4860::8888]:443$network
174.129.166.49$network -- completely blocks access to the specified IP

This is relatively easy to do in standalone programs. However, this is absolutely impossible in case of the browser extensions. We should come up with another solution in their case. I guess we can override RTC-* objects as a temporary solution.

@adbuker
adbuker commented Jan 24, 2017

ADWIN-CR-115

@adbuker adbuker closed this Jan 26, 2017
@ameshkov
Member

I don't like how it works for TCP protocol.

Instead of immediately closing the affected connection, it is stuck forever.

@ameshkov ameshkov reopened this Jan 27, 2017
@ameshkov
Member

@adbuker don't forget to create the same tasks in Android and Mac repos.

@ameshkov ameshkov changed the title from STUN is used to load ads through WebRTC to Add $network basic rules modifier to solve the issue with loading ads through WebRTC Jan 27, 2017
@ameshkov
Member

We should also cover all UDP ports in order for this to work properly.

@ameshkov
Member

One more question: what exact rules are used when you check IPv6 address?
Do you collapse IPv6 using ::?

@adbuker
adbuker commented Jan 30, 2017 edited

@ameshkov if you use rules, contains ipv6, you should use "collapsed" syntax, e.g. use rule [2001:4860:4860::8888]$network instead of [2001:4860:4860:0:0:0:0:8888]$network

@adbuker
adbuker commented Jan 30, 2017 edited

to taking into account the issue with "home media server filtering" we need to create driver - filtering rule to allow the activity without filtering transmitted packets for specified udp-ports, used in home media server.
ProtocolFiltersLog.txt

@ameshkov
Member

Nothing about UDP in that file. You should analyze driver's log. @suhan3z can teach you how to use traceview utility and read that log.

@adbuker
adbuker commented Jan 30, 2017 edited

in the end, it turned out that we shouldn't add to any udp-ports to exceptions

@adbuker adbuker closed this Jan 30, 2017
@ameshkov
Member
ameshkov commented Feb 1, 2017

@ameshkov if you use rules, contains ipv6, you should use "collapsed" syntax, e.g. use rule [2001:4860:4860::8888]$network instead of [2001:4860:4860:0:0:0:0:8888]$network

@adbuker there should be a unit test checking it.

@ameshkov ameshkov reopened this Feb 1, 2017
@adbuker
adbuker commented Feb 1, 2017

add unit test for it in ADWIN-CR-115.

@adbuker adbuker closed this Feb 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment