Hacker News Reader

Comment by tomp | Hacker News Reader

> This work, frankly, upsets some of our customers or potential customers (like Archive.is).

That's a bit unfair, don't you think?

From what I remember of the saga, the original reason for Archive.is's block is that they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with.

edit: found source https://twitter.com/archiveis/status/1018691421182791680

So the alternative viewpoint is, that Cloudflare is being anti-competitive by technically preventing other CDN providers from working.

Disclosure: I'm a happy Cloudflare user, but all in all I think Archive.is service is far more fundamental for the internet (especially as it's 100% free!). So I would really appreciate if you could figure out a way of working together. Until then, 8.8.8.8 it is!

View on HN

> they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with.

I feel like the more reasonable answer here is to just let the user take the latency hit. Surely requests being somewhat slower is preferable to requests being outright bitbucketed, right?

Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare.

CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there).

> Right but then working slow looks like archive.is issue but is ultimately caused by cloudflare.

Whereas not loading at all looks like archive.is issue but is ultimately caused by archive.is.

> CF is bascically saying "we can know your IP but not the site you are trying to resolve" (that will know your IP anyway once you navigate there).

Not necessarily. For example, the DNS query could go straight to CF while the eventual request to archive.is goes through a proxy or VPN.

Ok, really? Who is using a proxy for HTTP but not DNS in 2023?

The current situation seems to be that for these users it's not working at all (either timeout or infinite captch loop), and it looks like an archive.is issue, no explanation is given. So avoiding service disruption looking like an archive.is issue does not seem to be the goal.

Forgive my naivety, but can you not just ping several servers and return the best? Could you not even guess first and then asynchronously perform this and then re-route or do so on the next user click? I am not an internet person so this may be a very dumb question.

For a site with longer-lived sessions (e.g. video on demand, gaming etc.) which tolerate a bit of startup delay/inefficiency that can definitely be done.

But for a site that essentially tries to serve you static content as quickly as possible and mostly all at once, that would probably introduce more overhead than it's worth.

In the latter case, that seems like it just wouldn't be such a big deal, right? Since the hit would only happen user side and be a small percentage of the user's time on the site?

I get that they don't want to "take the blame" but it seems like both parties are performing reasonable actions that butt heads but that one party resolves that by just not performing the service. To me that feels like a worse outcome than slow service, as it just looks like the site is down.

The next naive question I have is about the response of truncation. I understand Cloudflare is preserving privacy. Archive says that privacy is preserved because they truncate the PII. Is this truncation verifiable in the request from Cloudflare? If not, then this seems like an unreasonable expectation ("just trust me bro"). Again, personally I'd rather have the latency hit and I'm not sure I'm seeing a good argument against this.

> In the latter case, that seems like it just wouldn't be such a big deal, right? Since the hit would only happen user side and be a small percentage of the user's time on the site?

True, but it's still the difference between being able to load all embedded resources from a server close to the user or potentially having to haul all of that across an ocean, considering TCP congestion window scaling (which is sensitive to round trip times) etc.

All that said, based on a purported comment by the maintainer of archive.is, the aim of their CDN is actually not improving responsivity, but delaying legal/law enforcement responses: https://news.ycombinator.com/item?id=36971650

> Archive says that privacy is preserved because they truncate the PII.

Personally, I don't have a lot of sympathy for either party here:

I think, especially given the comment linked above, Archive's latency/efficiency concerns are just pretext for quite different concerns of their own (having to deal with law enforcement).

And on the other hand, while Cloudflare's EDNS subnet truncation might help user privacy in a few edge cases (as many have said here, the visited site will get the user's IP as soon as they connect to their servers!), it also makes it that much harder for CDNs other than Cloudflare to efficiently serve content using DNS-based routing and forces them to also use Anycast, which is much harder to do.

You shouldn't assume the origin server is setup for direct traffic - either in terms of load management or security (access to origin might only be available to CDN IPs on their ACL)

> You shouldn't assume the origin server is setup for direct traffic

You don't need to make any such assumption; the above point stands even in the case of simply hitting the "wrong" (i.e. geographically suboptimal) CDN endpoint.

So how do other companies cope with 1.1.1.1, that run their own CDN? E.g. Facebook? Google?

They have own Autonomous Systems with own anycast IP addresses.

It is quite expensive for an indie project. Not to mention legal support for compliance in every country of presence. To block 0.x% of visitors coming from CloudFlare is much cheaper for a small project than to go this road.

> They have own Autonomous Systems with own anycast IP addresses.

> It is quite expensive for an indie project. Not to mention legal support for compliance in every country of presence. To block 0.x% of visitors coming from CloudFlare is much cheaper for a small project than to go this road.

I don't buy this. I'm running my own AS and anycast services for £10pm (my ISP are sponsoring my allocations from RIPE).

Also, it feels like Cloudflare's DNS service is more than just 0.x% of the internet....?

£10 GBP a month for a AS with an IPv4+IPv6 subnet + worldwide POPs that allow you to advertise your subnets over BGP? How did you pull that off? I've researched this a while ago and just the IPv4 subnet alone was at least 10x that amount if you are OK with leasing it from less reputable sources.

I didn't say IPv4 :p

You're right, if you've got a legacy internet requirement then that adds another grand a year to your costs. But I disagree that it's "quite expensive for an indie project", especially one that's so popular it needs to run it's own CDN.

Reply on news.ycombinator.com