Out of curiosity - not defending the behavior - what kind of problems could omitting EDNS cause? What is the steelman case for Archive.is here?
The author says Archive.is's claim that it causes problems is "questionable", but he doesn't mention what those purported problems are or address why they're illegitimate, so it's hard to evaluate whether that's accurate.
Archive.is uses ECS (edns client subnet, which sends the client IP's /24 to the authoritative resolver) for geo-based load balancing. The problem is that all IPs in a /24 are highly likely to belong to the same city for residential connections, so plugging it into a geoip service is likely to show the actual city & state that a request originates from (the entire point of ECS).
But when the user goes to use the IP address they got back, even more detailed information is going to be given to the endpoint; I can see this maybe being a benefit for TXT records or something?
Hiding ECS from DNS queries seems to mostly just further create imbalances between companies that can afford routing at the IP level over companies that want to do cheaper routing at the DNS level.
(And like, if you attempt to directly mitigate the final IP problem by using a VPN or CG-NAT or something, that same solution will work for the DNS resolver, so I really am seeing no benefit.)
To add, apparently another reason is that he believes using Cloudflare as your recursive resolver could lead to phishing[0]:
> the same entity which answers your DNS queries is able to issue SSL certs for any domain, so using CloudFlare DNS you never know whether you access the original website or a fishing one
Generally this is protected via certificate transparency+CAA records. If CF's CA were to issue a bad certificate, it'd be blocked by the browser and, should it get out, jeopardize the entire company, likely DigiCert as well given they cross-signed Cloudflare's issuing CA.
I don't fully understand how archive.is operates. They don't remove copyrighted content (which I like, since it provides a useful service), they must have probably terabytes upon terabytes of data in some datacenter somewhere, yet they never seem to be shut down by the govt or their datacenter/cloud provider. Am I just naive to be surprised by this? How does all this work exactly?
There’s basically no information on the web site about the company, how they operate, who finances them, what their privacy policy is, or even how to contact them. Their “blog” is an anonymous Tumblr site.
They’re in russia so dgaf about this. The insistence on tracking and absence of https when served from inside russia kind of implies all sorts of things. Use archive.org
I will continue to use them because things get taken down from archive.org sometimes, or at any rate far more often than with archive.is. I consider it a bug when anything disappears from an archive for any reason.
It’s apparently self funded by him. I don’t know how he doesn’t get shut down but I don’t know how all the DMCA avoiding pirated streaming sites don’t either, or how sci hub isn’t domain blocked in the US, or why millions of copyrighted books aren’t DMCAed from libgen.
Similar for dnscrypt-proxy: add "forwarding_rules = '/etc/dnscrypt-proxy/forwarding_rules.txt'" to /etc/dnscrypt-proxy/dnscrypt-proxy.toml and then populate the forwarding_rules.txt with lines like "archive.is 8.8.8.8".
> I wrote the following reply to Matthew, praising his team's focus on the big picture
Okay great, but:
> 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.
> massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come
The problem isn't really EDNS. And someone is either lying or very incorrect.
This should be resolvable. The two sides don't want incompatible things. Has there been zero progress since?
>> 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.
Cloudflare makes an exception to this rule for Archive.{today,is,...} domains.
All requests for this domains come from Amazon EC2 in the U.S., not the 180 edges of Cloudflare.
This was on blog.archive.today.
Why? Who knows. But the decision to break up is made by both parties, not just the archive.
There are a lot of emotions in the comments here today.
CloudFlare provides a clear response and it has merit.
Archive.is surely is not 100 reliant on this single mechanism to load share or determine correct routing to cache locations, I agree with the poster - I can't see a reason why they would block this via Cloudflare when so many other mechanisms they should already be deploying to satisfy their requirements across multiple layers in the stack exist. Edit: The position makes or made no sense and smells fishy.
archive.is has some sketchy tracking built into it.
I still use (the discontinued) umatrix with firefox and any archive.is request makes a lot of specific-to-you tracking pixels. like *.pixel.archive.is that drill down to your browser address
It's important to remember, at least for corporate environments, that EDNS Client Subnet is important when working with services such as Exchange Online where the local resolver is what determines your EXO Front Door. If you're using a service like 1.1.1.1, you may be routed to an incorrect Front Door causing increased latency (primarily with search and archive mailboxes which aren't cached).
Quad9 does have a service which provides EDNS Client Subnet support, should you want to leverage it.
Cloudflare DNS does not route efficiently with AWS CloudFront anycast DNS. I tracked down insanely slow `rustup update` downloads to incorrect selection of ideal routes to the AWS resources caused by using CF to resolve the DNS. Switching to a different resolver that works with anycast and EDNS fixed it.
CF saying “we break standard DNS geo routing but work with providers to route things right” isn’t very inspiring.
> Sure, it's annoying that I'll need to use a VPN or change my DNS resolvers to use a pretty slick (and otherwise convenient) website archiver.
You can alternatively look up the IP address using something other than Cloudflare DNS and add entries to your /etc/hosts file for archive.is and archive.today.
I had a similar issue with VoWiFi on my network due to EDNS, and it's rightly pointed out by msilverlock in forum.
# dig vowifi.jio.com @1.1.1.1 A
;; ANSWER SECTION:
vowifi.jio.com. 5 IN A 49.45.63.1
vowifi.jio.com. 5 IN A 49.45.63.2
;; SERVER: 1.1.1.1#53(1.1.1.1)
# dig vowifi.jio.com @8.8.8.8 A
;; ANSWER SECTION:
vowifi.jio.com. 4 IN A 49.44.59.36
vowifi.jio.com. 4 IN A 49.44.59.38
;; SERVER: 8.8.8.8#53(8.8.8.8)
I thought: I ask dns server about domain, they return an IP address. I connect to IP address and they in turn can see mine.
So why does cloud flare need to a) query domain for IP address on my behalf? Can’t they just do it on their own behalf and cache the results?
B) why do they need to hide my IP address information from the domain? Aren’t I going to visit the destination regardless?
I noticed a few days ago that it didn't work for me, but used a site up/down checker that also said it was down. Figured they were having issues and didn't think any more about it. I just added a static entry to my pihole, so it works for me now.
i have no trouble to resolve www.archive.is via 1.1.1.1 at all...
however, i noticed archive.is has a CNAME record pointing to www.archive.is while CNAME RR on apex domains are usually not allowed in DNS... what make this even more interesting, i only see the CNAME RR when querying via 1.1.1.1 and not when querying authoritative servers for archive.is (EDIT: while repeating the query via 1.1.1.1 i also saw both A and CNAME record for archive.is in the response :S)
maybe the initial issue is just gone already? considering this is apparently happening in 2019 that does not seem too unlikely...
Archive.is is unironically one of the most important websites in the world. I hope this mess gets fixed but I am not holding my breath because we are in the same position for years now.
That reads a lot like doxxing; if someone isn't open about their identity, they don't want it out, and doing sleuthing work like this (or linking to it) can be considered doxxing.
If archive.is hosts content that has been removed due to oppressive regimes' policies (including western ones), exposing their identity may put them at risk.
I think the question asked on SE "On which country are the creators and servers of archive.today / archive.is based?" incurs not a 'who is he', but 'should I trust them based on their national allegiance'. A similar idea could be presented of large Twitter misinformation accounts that have influenced the 2016-2020 (and future) elections - they're not open about their identity, but the actions they're doing most people would disagree with, so most would decide that it is morally justifiable to go digging for clues to find the source of the misinformation.
For archive.is, it's lower-stakes, but you might not be able to trust the site as an authoritative source in $x years should (for example) their home government take it over and strategically modify archives for their own purposes.
The operator of archive.is is circumventing copyright law in close to every country on earth, including all the democratic ones. Its unique selling point is that they do not comply with site owners' requests not to archive content or to delete content archived in the past.
While that doesn't exclude them from the protection of law, my conviction is slightly weaker when it comes to arbitrary standards of behaviour people on reddit invented. How many pages to they happily serve that contain private information long deleted from the actual websites? When they mutter under their breath, "information wants to be free" (as they are want to be, at least how I imagine it), does their definition of information include their identity?
(I'm slightly irritated by the "research" in that post, though... I really don't need Wikipedia to believe that -vich is a jewish name. And jewish names of Ukrainian/Russian origin are certainly not specific to that location today. I bet there are more people with that last name in Florida than in all of Eastern Europe combined)
I find this highly implausible, all of the accounts archive.is is "logged into" would have to be put there in a very explicit manner. I'd assume that all of the accounts are fake or appropriated accounts.
For example @volth on Github - as a person - is still around in other places, so I'm guessing that account was stolen and they don't have a way to get it back.
>Everything on archive.is is on archive.org. I would say 99% of stuff.
Given how a LOT of the stuff today is behind paywalls and Archive.today breaks through most of them and Archive.org doesn't, your "99%" figure is way, way off when it comes to popular stuff.
Anyway, I donate to both the Archive.today and Archive.org. They're extremely valuable to me. I feel like Archive.today is in a dire situation when it comes to funding so I donate more than double to them each month.
If you're able, please donate to these sites. They are running on fumes. And take a look at my profile for a list of other orgs to donate to.
(In case you need one) Quad9 DNS is far better imo than CF.
Granted my ISP doesn't block many things already and it's fast, so the only concern for me is privacy, which the stated alternative seems to prioritize more than the others.
amazing how cloudflare has framed this anticompetitve move as a privacy thing.
it doesn't matter if your dns resolver leaks part of your ip address to archive.is's dns servers when you're about to connect to archive.is from your ip address anyway. the only thing dropping the edns client subnet does is prevent services you use from giving you a server that's closer to you when you do the dns lookup. this performance issue, of course, does not affect sites using cloudflare.
Just so we’re on the same page: Cloudflare decided globally not to include client IP in the EDNS data. Then archive.is decided to block Cloudflare’s resolvers from getting accurate records for their site.
To circumvent this, Cloudflare would have to reverse their global stance or make a special exception to satisfy archive.is.
It’s unclear how we could draw “anticompetitive” from this.
Understood, but why? Privacy is not an acceptable answer for the reasons OP stated. If Cloudflare gave a coherent, understandable reason, I'd probably be more on their side.
"Trust us, our network is big enough it will route right" is both not a good answer, nor true.
He didn't mean anticompetitive towards Archive.is, he meant with all content providers in general. By making them all less capable of delivering low-latency content, it makes Cloudfare appear better by comparison. Not sure how likely that would be but I'm pretty sure that was OP's meaning.
Cloudflare (Matthew Prince personally, here on Hacker News few months ago) said that they do reverse that their global stance for Netflix and some other megacorps.
So this is a super-premium feature unavailable to small players.
CloudFlare just changed how DNS behaved and charge corps to make it work as it worked before CloudFlare entered the stage.
EDNS is an optional feature in general. Client subnet is even more optional.
There may not be a whole lot of private information in the client subnet, especially since it seems likely that after querying for an A/AAAA record, a client would then send a packet to (one of) the resulting IP(s) and reveal their address, but it's not required to pass it on, and it it seems better to reduce potentially private information passed on.
Can we not call literally everything "anticompetitive"? archive.is isn't a competitor of Cloudflare. Cloudflare doesn't treat them differently from any other site, they're not doing anything "to keep them down", their DNS product just has a focus that isn't compatible with archive.is' hunger for data.
That you might connect to archive.is directly isn't of any concern. You might also not do that, and they've decided that leaking data about the user isn't what they want to do.
> Cloudflare doesn't treat them differently from any other site
Did we read the same article? Cloudflare is treating them, and anybody else that makes the same choices wrt EDNS, differently from the rest of the Internet.
archive.is doesn't compete with cloudflare, but they (or other websites) might want to spend money on improving their performance. cloudflare's dns resolver being popular makes one non-cloudflare option for improving website performance less appealing.
Archive.is used to geoblock all Finnish IP addresses at one point because of some alleged dispute with the Finnish government. As far as I remember, he got a takedown request from a Finnish government and then had some incident at the Finnish border, saying that they were linked (as in, the company in question could order the Finnish government to harrass him).
Works now though but it gives me doubts about the management of the site.
The people that run the Pirate Bay went to prison for operating that site, despite not hosting any illegal content there themselves. Archive.is faces similar impedance mismatch with what different people and courts believe about intellectual property.
When's the last time you went to prison for something you believe in?
I have long hated Cloudflare, so it's hard to be on their side here. They MitM large parts of the web and often trap you in long or even infinite loops with their horrendous checker that some sites unfortunately use. It's especially bad on less common browsers. In two cases I had to spoof my useragent or it would literally never pass the check, locking me out of several sites.
Even if the block was without reason, I would've thought "fair enough, Cloudflare sucks". It's weird to me how many people willingly use Google or Cloudflare DNS. I would have to be in quite the pinch to rely on either, like a site I need is blocked and I happen to remember their simple IPs, and also I can't use something like an ssh tunnel instead for some reason.
CloudFlare DNS is not the part that gives you the annoying anti bot checks. Those are from website operators who have opted in to the CDN and anti-DDoS services that CloudFlare offers.
Out of curiosity - not defending the behavior - what kind of problems could omitting EDNS cause? What is the steelman case for Archive.is here?
The author says Archive.is's claim that it causes problems is "questionable", but he doesn't mention what those purported problems are or address why they're illegitimate, so it's hard to evaluate whether that's accurate.
Archive.is uses ECS (edns client subnet, which sends the client IP's /24 to the authoritative resolver) for geo-based load balancing. The problem is that all IPs in a /24 are highly likely to belong to the same city for residential connections, so plugging it into a geoip service is likely to show the actual city & state that a request originates from (the entire point of ECS).
https://twitter.com/archiveis/status/1018691421182791680 (screenshot: https://aws1.discourse-cdn.com/cloudflare/original/3X/8/2/82... )
But when the user goes to use the IP address they got back, even more detailed information is going to be given to the endpoint; I can see this maybe being a benefit for TXT records or something?
Hiding ECS from DNS queries seems to mostly just further create imbalances between companies that can afford routing at the IP level over companies that want to do cheaper routing at the DNS level.
(And like, if you attempt to directly mitigate the final IP problem by using a VPN or CG-NAT or something, that same solution will work for the DNS resolver, so I really am seeing no benefit.)
7 replies →
To add, apparently another reason is that he believes using Cloudflare as your recursive resolver could lead to phishing[0]:
> the same entity which answers your DNS queries is able to issue SSL certs for any domain, so using CloudFlare DNS you never know whether you access the original website or a fishing one
Generally this is protected via certificate transparency+CAA records. If CF's CA were to issue a bad certificate, it'd be blocked by the browser and, should it get out, jeopardize the entire company, likely DigiCert as well given they cross-signed Cloudflare's issuing CA.
0: https://blog.archive.today/post/634795612966125568/when-will...
I don't fully understand how archive.is operates. They don't remove copyrighted content (which I like, since it provides a useful service), they must have probably terabytes upon terabytes of data in some datacenter somewhere, yet they never seem to be shut down by the govt or their datacenter/cloud provider. Am I just naive to be surprised by this? How does all this work exactly?
It’s pretty shadowy for sure.
There’s basically no information on the web site about the company, how they operate, who finances them, what their privacy policy is, or even how to contact them. Their “blog” is an anonymous Tumblr site.
It’s easy, you just make yourself unavailable for contact, there’s plenty of providers that don’t care what you do. It’ll take years to get banned.
The internet is global, it’s a choice to apply US law like the dmca. You can also choose not to.
They’re in russia so dgaf about this. The insistence on tracking and absence of https when served from inside russia kind of implies all sorts of things. Use archive.org
I will continue to use them because things get taken down from archive.org sometimes, or at any rate far more often than with archive.is. I consider it a bug when anything disappears from an archive for any reason.
It’s apparently self funded by him. I don’t know how he doesn’t get shut down but I don’t know how all the DMCA avoiding pirated streaming sites don’t either, or how sci hub isn’t domain blocked in the US, or why millions of copyrighted books aren’t DMCAed from libgen.
Fair use applies i think.
Things on archive.org get DMCA'ed all the time
2 replies →
I don't think retaining and publishing complete copies of copyrighted works falls under even the most generous interpretation of fair use.
It should, but I don't think it does in its current form.
There have been at least two past threads about this:
Tell HN: Unexpected errors with Archive.is on Cloudflare 1.1.1.1 DNS - https://news.ycombinator.com/item?id=19828317 - May 2019 (197 comments)
as well as god knows how many comments...
In case you use pihole and want to use cloudflare for everything, but archive.is you can create the following file
cat /etc/dnsmasq.d/02-archive.is.conf server=/archive.is/8.8.8.8 server=/archive.is/8.8.4.4 server=/archive.li/8.8.8.8 server=/archive.li/8.8.4.4 server=/archive.to/8.8.8.8 server=/archive.to/8.8.4.4
Fixed formating, sorry.
There are quite a few different TLDs that the site uses (for resilience I presume). .vn is another, .today may still be in use.
Similar for dnscrypt-proxy: add "forwarding_rules = '/etc/dnscrypt-proxy/forwarding_rules.txt'" to /etc/dnscrypt-proxy/dnscrypt-proxy.toml and then populate the forwarding_rules.txt with lines like "archive.is 8.8.8.8".
I never even thought of configuring my pihole to allow this. Thanks! Much appreciated!!
> I wrote the following reply to Matthew, praising his team's focus on the big picture
Okay great, but:
> 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.
> massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come
The problem isn't really EDNS. And someone is either lying or very incorrect.
This should be resolvable. The two sides don't want incompatible things. Has there been zero progress since?
>> 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.
Cloudflare makes an exception to this rule for Archive.{today,is,...} domains. All requests for this domains come from Amazon EC2 in the U.S., not the 180 edges of Cloudflare. This was on blog.archive.today. Why? Who knows. But the decision to break up is made by both parties, not just the archive.
Source https://blog.archive.today/post/623568857709395968/i-from-th...
There are a lot of emotions in the comments here today. CloudFlare provides a clear response and it has merit. Archive.is surely is not 100 reliant on this single mechanism to load share or determine correct routing to cache locations, I agree with the poster - I can't see a reason why they would block this via Cloudflare when so many other mechanisms they should already be deploying to satisfy their requirements across multiple layers in the stack exist. Edit: The position makes or made no sense and smells fishy.
archive.is has some sketchy tracking built into it.
I still use (the discontinued) umatrix with firefox and any archive.is request makes a lot of specific-to-you tracking pixels. like *.pixel.archive.is that drill down to your browser address
It's important to remember, at least for corporate environments, that EDNS Client Subnet is important when working with services such as Exchange Online where the local resolver is what determines your EXO Front Door. If you're using a service like 1.1.1.1, you may be routed to an incorrect Front Door causing increased latency (primarily with search and archive mailboxes which aren't cached).
Quad9 does have a service which provides EDNS Client Subnet support, should you want to leverage it.
Cloudflare has worked providers to make sure they can efficiently route. If you find case where this isn’t the case please let us know.
Cloudflare DNS does not route efficiently with AWS CloudFront anycast DNS. I tracked down insanely slow `rustup update` downloads to incorrect selection of ideal routes to the AWS resources caused by using CF to resolve the DNS. Switching to a different resolver that works with anycast and EDNS fixed it.
CF saying “we break standard DNS geo routing but work with providers to route things right” isn’t very inspiring.
2 replies →
I have Quad9's DNSCrypt configured with ECS on my Pi-Hole and it returns the IPs for archive.is and archive.today. Just tested it.
> Sure, it's annoying that I'll need to use a VPN or change my DNS resolvers to use a pretty slick (and otherwise convenient) website archiver.
You can alternatively look up the IP address using something other than Cloudflare DNS and add entries to your /etc/hosts file for archive.is and archive.today.
I had a similar issue with VoWiFi on my network due to EDNS, and it's rightly pointed out by msilverlock in forum.
https://community.cloudflare.com/t/vowifi-issues-due-to-poss...
As the article links to and says "privacy versus convenience", and I am happy that CloudFlare chose the former.
That million Firefox users who chose Cloudflare DNS must know that chose "privacy versus convenience" too and be happy with that.
There is so much I do not know about dns.
I thought: I ask dns server about domain, they return an IP address. I connect to IP address and they in turn can see mine.
So why does cloud flare need to a) query domain for IP address on my behalf? Can’t they just do it on their own behalf and cache the results? B) why do they need to hide my IP address information from the domain? Aren’t I going to visit the destination regardless?
some people use the IP from the DNS query to return a server closer to you
that's pretty much it
(2019)
I noticed a few days ago that it didn't work for me, but used a site up/down checker that also said it was down. Figured they were having issues and didn't think any more about it. I just added a static entry to my pihole, so it works for me now.
i have no trouble to resolve www.archive.is via 1.1.1.1 at all...
however, i noticed archive.is has a CNAME record pointing to www.archive.is while CNAME RR on apex domains are usually not allowed in DNS... what make this even more interesting, i only see the CNAME RR when querying via 1.1.1.1 and not when querying authoritative servers for archive.is (EDIT: while repeating the query via 1.1.1.1 i also saw both A and CNAME record for archive.is in the response :S)
maybe the initial issue is just gone already? considering this is apparently happening in 2019 that does not seem too unlikely...
It doesn't. At least I can view it while using 1.1.1.1
Archive.is is unironically one of the most important websites in the world. I hope this mess gets fixed but I am not holding my breath because we are in the same position for years now.
Interesting read on the probable owner of the site : https://webapps.stackexchange.com/a/149405
That reads a lot like doxxing; if someone isn't open about their identity, they don't want it out, and doing sleuthing work like this (or linking to it) can be considered doxxing.
If archive.is hosts content that has been removed due to oppressive regimes' policies (including western ones), exposing their identity may put them at risk.
I think the question asked on SE "On which country are the creators and servers of archive.today / archive.is based?" incurs not a 'who is he', but 'should I trust them based on their national allegiance'. A similar idea could be presented of large Twitter misinformation accounts that have influenced the 2016-2020 (and future) elections - they're not open about their identity, but the actions they're doing most people would disagree with, so most would decide that it is morally justifiable to go digging for clues to find the source of the misinformation.
For archive.is, it's lower-stakes, but you might not be able to trust the site as an authoritative source in $x years should (for example) their home government take it over and strategically modify archives for their own purposes.
The operator of archive.is is circumventing copyright law in close to every country on earth, including all the democratic ones. Its unique selling point is that they do not comply with site owners' requests not to archive content or to delete content archived in the past.
While that doesn't exclude them from the protection of law, my conviction is slightly weaker when it comes to arbitrary standards of behaviour people on reddit invented. How many pages to they happily serve that contain private information long deleted from the actual websites? When they mutter under their breath, "information wants to be free" (as they are want to be, at least how I imagine it), does their definition of information include their identity?
(I'm slightly irritated by the "research" in that post, though... I really don't need Wikipedia to believe that -vich is a jewish name. And jewish names of Ukrainian/Russian origin are certainly not specific to that location today. I bet there are more people with that last name in Florida than in all of Eastern Europe combined)
3 replies →
I find this highly implausible, all of the accounts archive.is is "logged into" would have to be put there in a very explicit manner. I'd assume that all of the accounts are fake or appropriated accounts.
For example @volth on Github - as a person - is still around in other places, so I'm guessing that account was stolen and they don't have a way to get it back.
That would be security by obscurity- something which the creator of such an important website does not have the privilege of relying on.
1 reply →
"Archive.is is unironically one of the most important websites in the world"
Are you sure you're not confusing it with the internet archive https://www.archive.org/
I am not talking about archive.org
Archive.is is faster and does not respect robots.txt. It is recommended by Wikipedia and is widely used by journalists worldwide.
1 reply →
Everything on archive.is is on archive.org. I would say 99% of stuff.
If archive.is goes down we have webcitation.org, etched.page, ghostarchive.org, webrecorder.net, etc....
archive.org obeys the robots.txt exclusion but archive.today doesn't. This means that many websites(like 4chan) cannot be archived with archive.org.
1 reply →
>Everything on archive.is is on archive.org. I would say 99% of stuff.
Given how a LOT of the stuff today is behind paywalls and Archive.today breaks through most of them and Archive.org doesn't, your "99%" figure is way, way off when it comes to popular stuff.
Anyway, I donate to both the Archive.today and Archive.org. They're extremely valuable to me. I feel like Archive.today is in a dire situation when it comes to funding so I donate more than double to them each month.
If you're able, please donate to these sites. They are running on fumes. And take a look at my profile for a list of other orgs to donate to.
1 reply →
Linked in Profile does not exit anymore. But
"Bachelor of Engineering Bachelor at the Humboldt University of Berlin."
This sounds fishy. I am not sure that you can get an Engineering degree at this University.
Currently only B.A. and B.Sc. as per their studying guide.
I don't know whether on the past there was some way to obtain said degree.
Edit: A different Bachelors besides those two are incredibly rare in Germany. For full universities (not universities of applied science) doubly so.
Is “Informatics” a Bachelor of Engineering?
https://www.informatik.hu-berlin.de/de/studium/Master
2 replies →
(In case you need one) Quad9 DNS is far better imo than CF. Granted my ISP doesn't block many things already and it's fast, so the only concern for me is privacy, which the stated alternative seems to prioritize more than the others.
I can't resolve with either 8.8.8.8 or 1.1.1.1.
I switched Chrome to use secure DNS with neither Croogle or CloudBlare (used OpenDNS) and now it works fine. Fuck the megacorps.
OpenDNS is owned by Cisco; it's not exactly a mom-and-pop operation.
Woah, that's a nice domain.
amazing how cloudflare has framed this anticompetitve move as a privacy thing.
it doesn't matter if your dns resolver leaks part of your ip address to archive.is's dns servers when you're about to connect to archive.is from your ip address anyway. the only thing dropping the edns client subnet does is prevent services you use from giving you a server that's closer to you when you do the dns lookup. this performance issue, of course, does not affect sites using cloudflare.
Just so we’re on the same page: Cloudflare decided globally not to include client IP in the EDNS data. Then archive.is decided to block Cloudflare’s resolvers from getting accurate records for their site.
To circumvent this, Cloudflare would have to reverse their global stance or make a special exception to satisfy archive.is.
It’s unclear how we could draw “anticompetitive” from this.
Understood, but why? Privacy is not an acceptable answer for the reasons OP stated. If Cloudflare gave a coherent, understandable reason, I'd probably be more on their side.
"Trust us, our network is big enough it will route right" is both not a good answer, nor true.
5 replies →
He didn't mean anticompetitive towards Archive.is, he meant with all content providers in general. By making them all less capable of delivering low-latency content, it makes Cloudfare appear better by comparison. Not sure how likely that would be but I'm pretty sure that was OP's meaning.
Cloudflare (Matthew Prince personally, here on Hacker News few months ago) said that they do reverse that their global stance for Netflix and some other megacorps.
So this is a super-premium feature unavailable to small players.
CloudFlare just changed how DNS behaved and charge corps to make it work as it worked before CloudFlare entered the stage.
21 replies →
EDNS is an optional feature in general. Client subnet is even more optional.
There may not be a whole lot of private information in the client subnet, especially since it seems likely that after querying for an A/AAAA record, a client would then send a packet to (one of) the resulting IP(s) and reveal their address, but it's not required to pass it on, and it it seems better to reduce potentially private information passed on.
Can we not call literally everything "anticompetitive"? archive.is isn't a competitor of Cloudflare. Cloudflare doesn't treat them differently from any other site, they're not doing anything "to keep them down", their DNS product just has a focus that isn't compatible with archive.is' hunger for data.
That you might connect to archive.is directly isn't of any concern. You might also not do that, and they've decided that leaking data about the user isn't what they want to do.
It's not anticompetitive. It's not evil.
> Cloudflare doesn't treat them differently from any other site
Did we read the same article? Cloudflare is treating them, and anybody else that makes the same choices wrt EDNS, differently from the rest of the Internet.
2 replies →
archive.is doesn't compete with cloudflare, but they (or other websites) might want to spend money on improving their performance. cloudflare's dns resolver being popular makes one non-cloudflare option for improving website performance less appealing.
Archive.is used to geoblock all Finnish IP addresses at one point because of some alleged dispute with the Finnish government. As far as I remember, he got a takedown request from a Finnish government and then had some incident at the Finnish border, saying that they were linked (as in, the company in question could order the Finnish government to harrass him).
Works now though but it gives me doubts about the management of the site.
The people that run the Pirate Bay went to prison for operating that site, despite not hosting any illegal content there themselves. Archive.is faces similar impedance mismatch with what different people and courts believe about intellectual property.
When's the last time you went to prison for something you believe in?
What does the Pirate Bay have to do with anything? Who went to prison here?
2 replies →
Tbc, I haven't, but I'm also not the one throwing shade at the site's management.
I have long hated Cloudflare, so it's hard to be on their side here. They MitM large parts of the web and often trap you in long or even infinite loops with their horrendous checker that some sites unfortunately use. It's especially bad on less common browsers. In two cases I had to spoof my useragent or it would literally never pass the check, locking me out of several sites.
Even if the block was without reason, I would've thought "fair enough, Cloudflare sucks". It's weird to me how many people willingly use Google or Cloudflare DNS. I would have to be in quite the pinch to rely on either, like a site I need is blocked and I happen to remember their simple IPs, and also I can't use something like an ssh tunnel instead for some reason.
CloudFlare DNS is not the part that gives you the annoying anti bot checks. Those are from website operators who have opted in to the CDN and anti-DDoS services that CloudFlare offers.