Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ban me at the IP level if you don't like me

boston.conman.org

Post reply on HN
Print view View original

361–370 of 516 posts

Re: Ban me at the IP level if you don't like me

#361

Post by Arnavion »

immibis wrote: post #349
Arnavion wrote: post #315

Earlier quoted context omitted.

One of them won't, but enough of them getting blocked would. People do absolutely notice ISP-level blocks when they happen. We're currently seeing it play out in the UK. But my main point was in the second paragraph, that "enough of them would" will never happen anyway when the only ones doing the blocking are small websites.

The end user will find out whether their ISP is blocking them or Netflix is blocking them. Usually by asking one of them or by talking to someone who already knows the situation. They will find out Netflix is blocking them, not their ISP. What, exactly, do you want ISPs to do to police their users from earning $10 of cryptocurrency a month, or even worse, from playing free mobile games? Neither one breaks the law btw…

>The end user will find out whether their ISP is blocking them or Netflix is blocking them. Usually by asking one of them or by talking to someone who already knows the situation. They will find out Netflix is blocking them, not their ISP.

You seem to think I said users will think the block is initiated by the ISP and not the website. I said no such thing so I'm not sure where you got this idea.

>What, exactly, do you want ISPs to do

Respond to abuse reports.

>Neither one is even detectable. (Not even by the target website! They're just guessing too)

TFA has IP addresses.

>Which, on the other hand, means Netflix would ban every ISP and have zero customers left.

It's almost like I already said, twice even, that the plan won't work because the big web properties won't be in on it.

Re: Ban me at the IP level if you don't like me

#362

Post by vultour »

plaguna wrote: post #14
dokyun wrote: post #11

Earlier quoted context omitted.

Who cares?

Same people who care about “master” and “main” for hit branches.

Sometimes I wonder how many lifetimes have been wasted by people all around the world fixing CI because a script expected a branch called master. All for absolutely pointless political correctness theatre.

Re: Ban me at the IP level if you don't like me

#363

Post by closewith »

lxgr wrote: post #352
closewith wrote: post #256

Earlier quoted context omitted.

> Visa and Mastercard aren't even involved in most disputes. Almost all disputes are settled between issuing and acquiring bank, and the networks only step in after some back and forth if the two really can't figure out liability. Yes, the issuing and acquiring banks perform an arbitration process, and it's generally a very fair process. We disputed every chargeback and post PSD2 SCA, we won almost all and had a 90%+…

I think you might be talking about "fraudulent transaction/cardholder does not recognize" disputes. Yes, when using 3DS (which is now much more common at least in Europe, due to often being required by regulation in the EU/EEA), these are much less likely to be won by the issuer. But "merchant does not let me cancel" isn't a fraud dispute (and in fact would probably be lost by the issuing bank if raised as such). Tho…

No, you're just wrong here. Merchant doesn't let me cancel will almost always be won by the vendor when they demonstrate that they do allow cancellations within the bounds of the law and contracts. I've won many of these in the EU, too (we actually never lost a dispute for non-compliance with card network rules, because we were _very_ compliant).

I can only assume you are from the US and are assuming your experience will generalise, but it simply does not. Like night and day. Most EU residents who try using chargebacks for illegitimate dispute resolution learn these lessons quickly, as there are far more card cancellations for "friendly fraud" than merchant account closures for excessive chargebacks in the EU - the polar opposite of the US.

Re: Ban me at the IP level if you don't like me

#364

Post by closewith »

lxgr wrote: post #353
closewith wrote: post #216

Earlier quoted context omitted.

Only via the original method of commerce. An online retailer who geoblocks users does not have to open the geoblock for users who move into the geoblocked regions. I have first-hand experience, as I ran a company that geoblocked US users for legal reasons and successfully defended chargebacks by users who made transactions in the EU and disputed them from the US. Chargebacks outside the US are a true arbitration proc…

> Chargebacks outside the US are a true arbitration process, not the rubberstamped refunds they are there. What's true is that in the US, the cardholder can often just say "I've never heard of that merchant", since 3DS is not really a thing, and generally merchants are relatively unlikely to have compelling evidence to the contrary. But for all non-fraud disputes, they follow the same process.

As commented elsewhere, you're just wrong. It's a significant burden of proof for a cardholder to win a dispute for non-compliance with card network rules and it very rarely happens (outside of actual merchant fraud, which is much rarer in the EU).

Again, you're not aware of the reality outside the US.

Re: Ban me at the IP level if you don't like me

#365

Post by korkybuchek »

sidewndr46 wrote: post #324
bob1029 wrote: post #132

I think a lot of really smart people are letting themselves get taken for a ride by the web scraping thing. Unless the bot activity is legitimately hammering your site and causing issues (not saying this isn't happening in some cases), then this mostly amounts to an ideological game of capture the flag. The difference being that you'll never find their flag. The only thing you win by playing is lost time. The best wa…

I don't think you have any idea how serious the issue is. I was loosely speaking in charge of application-level performance at one job for a web app. I was asked to make the backend as fast as possible at dumping the last byte of HTML back to the user. The problem I ran into was performance was bimodal. We had this one group of users that was lightning fast and the rest were far slower. I chased down a few obvious ou…

> Google's bot was one of the few well behaved ones and would even slow scraping if it saw a spike in the response times.

Google has invested decades of core research with an army of PhDs into its crawler, particularly around figuring out when to recrawl a page. For example (a bit dated, but you can follow the refs if you're interested):

https://www.niss.org/sites/default/files/Tassone_interface6....

Re: Ban me at the IP level if you don't like me

#366

Post by Sesse__ »

diggan wrote: post #319
q3k wrote: post #180

Earlier quoted context omitted.

Serving file content/diff requests from gitea/forgejo is quite expensive computationally. And these bots tend to tarpit themselves when they come across eg. a Linux repo mirror. https://social.hackerspace.pl/@q3k/114358881508370524

> Serving file content/diff requests from gitea/forgejo is quite expensive computationally One time, sure. But unauthenticated requests would surely be cached, authenticated ones skip the cache (just like HN works :) ), as most internet-facing websites end up using this pattern.

There are _lots_ of objects in a large git repository. E.g., I happen to have a fork of VLC lying around. VLC has 70k+ commits (on that version). Each commit has about 10k files. The typical AI crawler wants, for every commit, to download every file (so 700M objects), every tarball (70k+ .tar.gz files), and the blame layer of every file (700M objects, where blame has to look back on average 35k commits). Plus some more.

Saying “just cache this” is not sustainable. And this is only one repository; the only reasonable way to deal with this is some sort of traffic mitigation, you cannot just deal with the traffic as the happy path.

Re: Ban me at the IP level if you don't like me

#367

Post by gspencley »

sdenton4 wrote: post #328
gabeio wrote: post #321

Earlier quoted context omitted.

> It's also a page that's never visited by humans. Never is a strong word. I have definitely visited robots.txt of various websites for a variety of random reasons. - remembering the format - seeing what they might have tried to "hide" - using it like a site's directory - testing if the website is working if their main dashboard/index is offline

Are you sure you are human?

Yes. I have checked many checkboxes that say "Verify You Are a Human" and they have always confirmed that I am.

In fairness, however, my daughters ask me that question all the time and it is possible that the verification checkboxes are lying to me as part of some grand conspiracy to make me think I am a human when I am not.

Re: Ban me at the IP level if you don't like me

#369

Post by Dylan16807 »

SoftTalker wrote: post #322
zeta0134 wrote: post #298

Earlier quoted context omitted.

Just about nobody logs passwords on purpose. But really stupid IoT devices accept credentials as like query strings, or part of the path or something, and it's common to log those. The attacker is sending you passwords meant for a much less secure system.

You probably shouldn't log usernames then, or really any form fields, as users might accidentally enter a password into one of them. Kind of defeats the point of web forms, but safety is important!

Are you using a very weird definition of "logging" to make a joke? Web forms don't need any logging to work.

Re: Ban me at the IP level if you don't like me

#370

Post by ronsor »

8organicbits wrote: post #235

I've been working on a web crawler and have been trying to make it as friendly as possible. Strictly checking robots.txt, crawling slowly, clear identification in the User Agent string, single IP source address. But I've noticed some anti-bot tricks getting applied to the robot.txt file itself. The latest was a slow loris approach where it takes forever for robots.txt to download. I accidentally treated this as a 404…

> The latest was a slow loris approach where it takes forever for robots.txt to download.

I'd treat this in a client the same way as I do in a server application. If the peer is behaving maliciously or improperly, I silently drop the TCP connection without notifying the other party. They can waste their resources by continuing to send bytes for the next few minutes until their own TCP stack realizes what happens.

Post reply on HN