raxi
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
It is very possible that `gyrovague` is not `japatokal` but an impersonator.
Maybe even better: magnolia outperforms archive.is on paywalls
1. Planned obsolescence built into HTTPS: no HTTPS-aware server device from year 1999 would work with 2023 browsers. Just because "too old crypto". Plain HTTP works.
Being on a buy side I am against HTTPS in such devices, but I understand the sell side's position.
Of course, no https, but.. it is not a platform limitation, just an undemanded feature: how would you get a https cert for 192.168.0.1 or a similar intranet address where those device suppose to work? They are just not for cloud datacenters
A 32-bit CPU is very rich
I read that from recent magnolia commits, it falls back to {12,1}ft for some websites (apparently, some techniques cannot be done on client-side, perhaps, they require proxies in particular countries or google network to impersonate googlebot better)
Moreover, many people are in a grey area of the economy, paying no taxes at all: for example software developers making software for the West.
Looking at the ridiculous "sanctions" of recent days, I cannot say who they are directed against. In long run, they benefit Russia, preventing leaking of brains and capital.
I would prefer to work with companies where different nationalities are represented.
90%+ of employees in one country (be it Ukraine, Russia, USA or China) is a geo-risk for clients.
And mind you, Namecheap doesn't ban clients based on their agreement or disagreement with something. It bans pro-Ukrainian dissidents in Russia too.
Racism culture thrives in mono-ethnic companies and this Namecheap case is a good example
Got it.
Even I am Estonian, I move away looking for a more sane company.
So they show that Putin is right, that democracy and liberalism are dead, that Ukrainians are nazi, and rally people around him even more.
That raises a question: how to find a domain registar without a lot of Ukrainian employees ?
According to the recent leak, Epik has them a lot as well.
Could we crowdsource such a list of registrars sorted by nationality of their employees to be prepared to the geo risks?
There is a wellknown paywall-cleaning browser extension and it fails to bypass a lot. Issue list here: https://gitlab.com/magnolia1234/bypass-paywalls-firefox-clea...
Both have the save website and mailing address but there are 2 independent ICANN accreditations.
Likely, it is designed to prevent another sort of attack.
They do. Not at the Facebook scale, but they already started moving in that direction: unfolding issues with many comments requires login on GitHub, searching for code too - it does not prompt you to log in, in just brings 0 results to the unlogged
They indeed are, "for your privacy".
And our topic started exactly out of this:
From: https://webapps.stackexchange.com/questions/135222/why-does-...
``` Official Statement
archive.today had this to say about the issue:
https://twitter.com/archiveis/status/1017902875949793285
2018-07-13T1545: yes, unlike other public DNS services, 1.1.1.1 does not support EDNS Client Subnet
2018-07-15T1958: "Having to do" is not so direct here. Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.
> Or time travel to 2010 and try to respond to DNS queries while no servers are sending ECS.
That is exactly what `archive.{*}` does.
It responses to
[+] requests from IPs with geo-information (as in 2010, and it seems to be the most of requests still)
[+] AND to requests from public global resolvers with EDNS, which supply information to which region the server IP will be forwarded (as in 2015)
[-] But not requests from a public global resolver which conceal the source region (as it does a single privacy minded megacorp in 2019)
> They could've gotten geographical data from 1.1.1.1 to the accuracy of the edge nodes but decided to just outright block 1.1.1.1.
Yes.
But they cannot get back in time to getting information from the edges simple by unblocking.
Since CloudFlare sends queries not from the edges.
So there is a deadlock atm.
From your text it looks like webmasters are sending requests to CloudFlare to get user's IP.
This is totally wrong.
It is CloudFlare wants to see server IP and in the query it has to explain how they will use this info, to which region they will forward my server IP.
That is what EDNS-client-IP for.
If the requester refuses to explain why they need the server IP address for (and their goal cannot be derived from the source IP of the UDP packet, like in the case of local ISP resolvers), they may be denied the privilege of the honor of receiving responses.
It is very simple:
Query(source IP is an ISP in Paris, no EDNS): gimme IP of "website.com"
WebsiteComDNS: IP of the server closest to Paris
Query(source IP is Google, no-EDNS): gimme IP of "website.com"
WebsiteComDNS: Hm, it is likely Google Cloud, or GoogleBot, answer with IP of own server on Google Cloud
Query(source IP is Google, EDNS: I am acting on behave of an user in Paris): gimme IP of "website.com"
WebsiteComDNS: IP of the server closest to Paris
Query(source IP is Cloudflare, no-EDNS): gimme IP of "website.com"
WebsiteComDNS: where the fuck is CloudFlare? Africa? answer with something random
I read it in Mattew Prince sentence above
>
> You also sidestep here into a complaint against “planet wide resolvers”. To a rounding error, nobody is running their own recursive resolvers. Everybody uses either their ISP’s DNS provider or one provided by a large network entity, virtually all of which are companies. This has been the case for decades. So anybody relying on the source IP of the UDP packet is just out of luck, and has always been out of luck.
1. It is not sidestep. It is my main point. EDNS-client-ip has sense only for planetwide resolvers, and it is "optional" only because of it. EDNS-client-ip was designed especially for Google DNS. When you use recursive DNS of your ISP in your city, the source of UDP packet is in your city. When Google zeroes 8 bits of IP, the EDNS-client-ip is still your city. It is needless to know your exact IP to select the best server for you. CloudFlare refuses to disclose even that approximate location, which gives their anycast CDN an advantage.
2. There is no "decades" of "5 years" history. There is only two points on this timeline: the first: launching Google DNS - which introduced ENDS-client-IP to mitigate caused inconvenience to webmasters, the second: launching Cloudflare DNS - you know the story. The rest (Quad9, ...) are negligible. Yandex DNS might be comparable big and, like CloudFlare, it does not send EDNS-client-ip - for no privacy-caring stances (my speculation: just out of lazyness), but it is regional, all requests from there can be safely rounded to Moscow. So we can consider there are only three cases over there: Google, CloudFlare (commonly referred as "planetwide resolvers"), and all the rest are regional businesses, whose very network ownership discloses location.
>
> It’s clear you wish this wasn’t the case, but Cloudflare and Google aren’t really changing the game here,
This is ridiculous. The IP I will know from HTTP logs few miliiseconds later, we are talking about getting origin city from DNS query to answer with IP of the nearest HTTP server.
>
> and they don’t owe you optional features because you really want to see user IP data.
So webmasters do not owe to answer when CloudFlare want to see server IP data, ok?
The divorce of indy webmasters with CloudFlare DNS is very natural, I just wonder why it is no massive.