Bad Actor Identification

[webdevelopers-eu]

In our current setup, we rely on Intrusion Detection Systems (IDS) and firewalls to identify and block malicious IP addresses temporarily to mitigate pending attacks. These systems are crucial for protecting our networks and are extremely effective against various bots and script kiddies...

However, if attackers use hidden and/or shared IP addresses with legitimate users, our traditional approach to blocking these IPs could become ineffective. How will these security measures adapt to ensure they can still protect against threats without inadvertently affecting legitimate users who might be sharing the same IP for anonymity purposes?

[iam-py-test]

Disclaimer: I am not affiliated with Google.
IP protection does not apply to first party requests: #31 (comment)
Though, frankly, even script kiddies can download a VPN or residential proxy, meaning you can not block the attacking IP. IP based blocklisting will always be prone to false negatives and false positives.
Thanks

[brgoldstein]

At this time we have no plans to proxy first party requests. We also understand the importance of anti fraud use cases and will share more information at a later date.

[webdevelopers-eu]

@brgoldstein At this time we have no plans to proxy first party requests. We also understand the importance of anti fraud use cases and will share more information at a later date.

Can a bad actor exploit this mechanism to access free proxies? For example, could they trick Chrome into treating every request as a third party? I can see how free scan/DoS tools could route their traffic through Google’s proxy servers, which would put a strain on site owners by making it harder to block attackers, as they’d have easy and standardized proxy routes to targeted sites.

@iam-py-test Although, even script kiddies can download a VPN or use residential proxies, making it difficult to block the attacking IP.

You’re right, but based on our analysis, most attackers don’t go that route. Simply blocking their IPs temporarily often ends their efforts, and they usually give up. From a security standpoint, even mitigating those script kiddies helps reduce the risk of accidental vulnerability discovery, which is a significant benefit.

[josephrocca]

At this time we have no plans to proxy first party requests.

I'm not sure that this is sufficient to solve the core issue here (but I could be wrong, of course).

For example, consider a comments iframe embed https://my-blog-comments.com, embedded within https://my-blog.com/post. I'm guessing under the current model, the iframe would be loaded via a proxy IP. Then subsequent request within that iframe - e.g. to https://my-blog-comments.com/api/foo would be made via that same proxy IP?

There are many web applications (mine included) which have abuse-detection signals based on different IPs making requests for different resources on the same page - including resources at different subdomains/origins (e.g. CDN vs main server origin).

Fundamentally, it has been assumed for decades now that a user's IP will only change every so often, and so requests for resources will tend to be made via the same IP for any given user. If the user has requested https://my-blog-comments.com several hundred times, but hasn't ever requested https://my-blog.com/post, then this is suspicious, and so the user may eventually get blocked. But with this proposal, innocent users would get blocked because they are making requests to different resources with different IPs, since those resources are at different origins.

(BTW, I really like this proposal with my "internet user" hat on. I just hope that it doesn't get pushed through without solving core issues like the ones mentioned in this thread.)