Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's horrible that the Internet is slowly becoming a locked-down ecosystem. Everyone should turn off HTTP/3 in protest of this.

https://news.ycombinator.com/item?id=43329320



What exactly are sites supposed to do to prevent being the targets of DDoS, spam, fraud, aggressive bots, and other abuse? And it's not "locked down", it's usually just a CAPTCHA as long as you're not coming from an abusive IP range like might happen with a VPN.

Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.


The normalization of CAPTCHAs for simply reading what ought to be public information strikes me as very alarming, as does characterizing essential privacy and anti-censorship measures like VPNs as "abusive".

Something like 1% of HTTP hits pose some risk of spam or fraud, those where somebody is trying to post a message or a transaction or something. The other 99% are just requesting a static HTML document or JPEG (or its moral equivalent with unwarranted and untrustworthy dynamic content injected). Static file serving is very difficult to DDoS, even without a caching CDN like Fastly. There is still a potentially large bandwidth cost, but generally the DoS actor has to pay more than the victim website, making it relatively unappealing.

Should web sites really be weighing "a thousand signals" to decide which version of the truth to present a given user with? That sounds dystopian to me.


Of course it's alarming. But what's the alternative?

> Something like 1% of HTTP hits pose some risk of spam or fraud

It doesn't matter if it's a tiny percentage of requests that are spam/fraud. The only thing that matters is the absolute amount, and that's massive.

> Static file serving is very difficult to DDoS

No it's not, and most pages aren't particularly static. They're hitting all sorts of databases and caches and stores.

> generally the DoS actor has to pay more than the victim website

No, generally the DDoS actor pays very little, because they're using bots infecting other people's devices. The bandwidth is free because it's stolen.

> be weighing "a thousand signals" to decide which version of the truth

Nobody said anything about "truth". You're either blocked or you're not. Page content isn't changing.

Yes, spam and fraud and abuse prevention does require weighing a thousand signals. It always has. It sucks, but the world is an adversarial place, and the internet wasn't designed with that in mind.


This is also my experience. If you are dealing with clients that can pay to have their content cached, and not hit the originating server, that's great. To me, that sounds like what Cloudflare offers. Unless you have the ability to push an entire website into a CDN, there are things like query (GET) parameters on a URL that will bypass the cache and hit the server. This means that only using file caching is not viable unless you are running a completely static website. Most websites allow the client to make changes to the content through some web based GUI, and you have things like pagination where the maximum page number may not be known ahead of time for your CDN.

I have dealt with DDoS attacks with and without a service like Cloudflare, and without something like Cloudflare, the costs are extremely high. These are not clients pulling in millions of dollars of sales, even per year. There are IP blocks, but sometimes those bots are running on networks shared with the client's customers. Most clients I deal with couldn't fathom dealing with a static website, even if I could give them a hidden backend that pushed all files to a CDN for caching. I have enough trouble explaining why a page isn't showing recent changes, even with a big button stating to press it if your page changes do not display (integration with the Cloudflare caching API).

Bots, human fraud, it's all a balancing act while trying to give your clients the easiest solution possible for them to run their business online. Without a massive hosting budget, it's not feasible to provide for an easily maintainable client solution, that is also easy on their clients, and prevents abuse from bots and those that would cause fraud or damage.


Can you explain more specifically the threats faced by your website? Please help us understand what attacks you are currently facing. Are you currently getting DDoSed? Did the DDoSer stop DDoSing when you blocked HTTP 1.1? Did your credit card chargebacks drop by 50%?

---

According to other commenters the main use case for HTTP/3 is ads serving. Should I assume your project is an ad server? I could disable HTTP/3 in my browser to block ads. You see that this is a bit silly, right?


I'm sorry, are you really questioning whether these threats exist? Or whether not using HTTP/3 is one potential signal of being a bot (out of many), since tools like cURL don't support HTTP/3?

The two other commenters are wrong, ads are not the main use case at all. And disabling HTTP/3 won't block ads, not even the tiniest bit. It appears you are getting a lot of misinformation.


I would like you to explain specifically and concretely why you need this, without using any broad abstract ideas like "bots" or "fraud".

For example: "We were receiving 1000 spam and 100 legitimate comments per day even though we used hCaptcha on the comment form. When we disabled HTTP 1.1 on the comment endpoint, the spam stopped entirely, and we still received 95 legitimate comments per day." (in this scenario, I don't think it's necessary to further elaborate what counts as a "spam comment" if it's the usual type. If it's not the usual type then you will have to elaborate it.)


Sorry, but you seem to be continuing to misunderstand how this works. Disabling a version of HTTP on its own is not going to stop spam. You seem to be confused about how something can be one factor out of many in a statistical model.

If you don't want to talk about basic concepts like bots or fraud, and don't understand how and why detection mechanisms for them exist, I suggest you do your own research. There are lots of explanations out there. An HN comment isn't a place where I can help you with that, sorry.


It sounds like you are advocating a policy to solve hypothetical problems or problems you have vaguely heard that somebody had once, not real-life problems where you are familiar with the tradeoffs.


I would say absolutely not, for something that is actually run as static. How many websites could run as static, versus the clients that pay for those websites that believe they need to make a change at any time without going back to their web developers? In my experience, most clients rarely change their websites, and often request changes from my employer after having paid for a solution that allows them to have control should they want or need it. Due to this, I still need to run a dynamic website for truly static content.

A large part of this issue is web development being totally foreign to most users, and clients being burned by past developers that disappeared when needed the most, or hit with a large charge for an update that seems to be "simple". This pushes clients to want a solution where they can make the changes, and that leads to a dynamic website for static content. If you were to stop taking this type of business to further privacy, there are probably tens or hundreds of other companies in your own city that will gladly take on the work.

This absolutely is dystopian, but also current reality. Unless you are able to run completely privately online, the Internet as a whole has become dystopian because shutting down bad actors has been thrown into the hands of individuals instead of part of the backbone to how the Internet functions. Just my two cents, as a developer that needs to use these resources, but also runs a VPN on my phone and desktop nearly all the time for privacy (as well as some speed benefits, depending on the VPN provider).


It's not "just a CAPTCHA", it's a monstrosity involving tons of invasive JS that requires the latest Big Browser and attempts to identify you.


When it comes specifically to Cloudflare, it does not have to be this way. A site operator can choose to set their own rules for triggering CAPTCHAs, it's just that most don't actually bother to learn about the product they're using.

I use Cloudflare through my employer because I deal with clients that aren't willing to spend a few hundred dollars a month on hosting. In order to keep up with sales of new websites for these clients (where the real money lies), I need to keep hosting costs down, while also providing high-availability and security. Bot traffic is a real problem, and while I would love to not require using Cloudflare in favor of other technologies to keep a site running quickly and securely, I just can't find another solution near a similar price point. I've already tweaked the CMS I use to actually run with less than the minimum recommended requirements, so would have to take a more hostile action towards my clients to keep them at the same cost (such as using a less powerful CMS, or setting expiration headers far in the future - which doesn't help with bots).

If anyone has suggestions, I'd be open to them, but working for a small business I don't have the luxury to not run with Cloudflare (or a similar service if one exists). I have worked with this CMS since 2013, and have gone into the internals of the code to try and find every way to reduce memory and CPU usage so I don't need to depend on other services, but I don't see too many returns anymore.

I am all for internet privacy, and don't like where things are going, but also do work for lots of small businesses including charities and "mom and pop" shops that can't afford extra server resources. In no way do I use Cloudflare to erode user privacy or trust, but can understand others looking at it that way. If I had the option to pick my clients and their budgets, it wouldn't be an issue.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: