Fix #1674 m.stripe.com

[IceCodeNew]

Creating the pull request

Please include a summary of the change and which issue is fixed\ If the related issue does not exist in our repository, please create it before making pull request\ It is highly recommended to use our Web Reporting Tool instead of creating an issue on GitHub directly\ Please note, that we verify every pull request manually, so it may take time to apply it

Prerequisites

To avoid invalid pull requests, please check and confirm following terms

• [x] This is not an ad/bug report
• [x] My code follows syntax of this project
• [x] I have performed a self-review of my own changes
• [x] My changes do not break web sites, apps and files structure

What problem does the pull request fix?

If the problem does not fall under any category that is listed here, please write a comment below in corresponding section

• [ ] Missed ads
• [x] Website or app doesn't work properly
• [ ] Missed analytics or tracker
• [ ] Filters maintenance

What issue is being fixed?

Enter the issue address

https://github.com/AdguardTeam/AdGuardSDNSFilter/issues/1674

Add your comment and screenshots

If possible, a screenshot of a page or application should not be cropped too much. Otherwise, it is not always clear where the element is located

rule ||m.stripe.com^ is a false alarm, refer to https://support.stripe.com/questions/privacy-and-security-of-stripe-js?locale=en-US, here is the description:

While you might see Stripe in a tracker list, we’re not building an individual > tracking profile on you. Stripe doesn’t—and won’t—share or sell this data to > advertisers. This data is securely exchanged between the following > Stripe-controlled hosts:

js.stripe.com

m.stripe.network

m.stripe.com

q.stripe.com

The data collected by these endpoints is designed to be secure and to not leave Stripe infrastructure. Access to this data is tightly controlled, and restricted to a small number of Stripe employees working on fraud prevention and security (and permissions are regularly reviewed)

This rule is included by the following configuration: https://github.com/AdguardTeam/AdGuardSDNSFilter/blob/820536f8aedde543a9d9504676cfbfe4281d3166/configuration.json#L100-L104 And the origin source is not proper proceeded:

||m.stripe.com^$third-party,domain=~stripe.network

https://raw.githubusercontent.com/easylist/easylist/3cd177207a7d717e282699c0d33f76406dda4dd4/easyprivacy/easyprivacy_thirdparty.txt

Terms

• [x] By submitting this issue, I agree that pull request does not contain private info and all conditions are met

[BlazDT]

Not blocked anymore.

[IceCodeNew]

Not blocked anymore.

@BlazDT I am curious how it was fixed. Would you mind sharing some knowledge with me? I have proposed a fix that could prevent similar problems, and I would love to know if there is a better way to do that.

[BlazDT]

Blocking rule got removed.

[IceCodeNew]

Blocking rule got removed.

So it might be re-introduced again?

[BlazDT]

In theory yes, but very unlikely.

[IceCodeNew]

In theory yes, but very unlikely.

I would like to request this PR be re-opened and merged. I believe in the Murphy's law ;-)

[BlazDT]

Usually we only unblock items if there is an existing rule blocking it. But I can see your point due to business and credit cards.

@Alex-302 for your decision.

[Alex-302]

How it prevents scam, if it can be blocked?

[IceCodeNew]

How it prevents scam, if it can be blocked?

I do not seem to understand how it is related to the current discussion. If you are writing down those words in a hurry, please feel free to take time while responding.

The current discussion is about should a further fix be done to prevent similar problems from happening. IMO, this project had incorrectly processed an upstream source. Fixing that bug may affect many other aspects, and there is no guarantee that a similar problem will not happen again. Given the GRAVITY of the outcome (should those domains be introduced again), I would like to urge this PR to be merged.

I do not think it is necessary to re-evaluate whether or not those domains are safe to block. But we certainly can discuss whether or not a contribution to this project is welcomed.

[Alex-302]

@IceCodeNew I'm interested in the technical side. If a scammer has blocked your domains and tries to make a payment, what will be the result?

For example, perimeterX shows captcha when there is suspicious activity (probably in the absence of a verified fingerprint), and if you block their domain you won't be able to pass the captcha.