I guess one of the interesting things I learnt off this article(1) was that 7% of DNS query types served by 1.1.1.1 are HTTPS and started wondering what HTTPS query type was as I had only heard of A, MX, AAAA, SPF etc...
Apparently that is part of implementing ECH (Encrypted Client Hello) in TLS 1.3 where the DNS hosts the public key of the server to fully encrypt the server name in a HTTPS request. Since Nginx and other popular web servers don't yet support it, I suspect the 7% of requests are mostly Cloudflare itself.
It’s also how browsers detect a website supports HTTP3. Browsers will request it just to check if they should connect to an https:// URL via HTTP3 (though they generally don’t block on it - they fallback to HTTP1/2 if it takes too long).
> It’s also how browsers detect a website supports HTTP3
It's one way, but a H1/H2 connection can also be promoted to H3 via the alt-svc header. The DNS method is slightly better though since it potentially allows a client to utilize H3 immediately from the first request.
Every browser requires H2 connections to be encrypted so I don't think a MITM downgrading to it would reveal anything. Downgrading to H1 might do since encryption is optional there, but the proper way to prevent that is to submit your domains to the HSTS preload list so that browsers will always require encryption, regardless of protocol, no exceptions.
There’s an odd skew in that data which is saying the *third* most popular TLD is ‘.st’ which is… unexpected. The biggest service I can find using that TLD is `play.st` so maybe PlayStation clients are early adopters of DNS-over-HTTPS via 1.1.1.1.
Encrypted DNS has existed for quite a while now through DNS over HTTPS, the missing link was that to connect to a website, you first had to send the server the hostname in plaintext to get the right public key for the site. So someone listening on the wire could not see your DNS requests but would effectively still get the site you connected to anyway.
The new development (encrypted client hello) is you no longer have to send the hostname. So someone listening in the middle would only see you connected to an AWS/etc IP. This will make blocking websites very difficult if they use shared services like cloudflare or cloud VPS hosting.
> blocking websites very difficult if they use shared services like cloudflare or cloud VPS hosting.
I see this as a very good development and a big win for privacy. I have been running my own DNS server for years to prevent passive logging, but could basically do nothing against the SNI leak.
Though I worry that instead western governments will beat the judges to the punch and start asking things like DNS providers or even HTTPS servers to keep logs that can be subpoenaed much like a telecom company keeps a log of each phone call ("metadata"), or else be blocked...
Western governments just send a court order to the hosting provider to shut the site down / revoke their domain name. Site blocking is more of a problem for small counties trying to block sites the rest of the world allows to be hosted.
In terms of privacy, your DNS history probably isn't very interesting. It's almost all going to be requests for the top social media sites. Which governments have full access to the stuff you post there.
In principle, it means you could run multiple sites from the same IP and someone intercepting traffic to that IP (but not the client’s DNS path) couldn’t tell what site each connection was to. It mostly makes sense for CDNs, where the same IP will be used for many sites.
If you don’t use a CDN at all, the destination IP leaks what site you’re trying to connect to (if the domain is well known). If you use a CDN without ECH, you send an unencrypted domain name in the HTTPS negotiation so it’s visible there. ECH+CDN is an attempt to have the best of both worlds: your traffic to the site will not advertise what site you’re connecting to, but the IP can still be shared between a variety of sites.
It’ll be interesting to see how countries with lighter censorship schemes adapt - China etc. of course will just block the connection.
Even for China so-called "overblocking" where to censor a small thing you have to block a much larger thing, is a real concern with these technologies. There's a real trade here, you have to expend effort and destroy potential and in some cases the reward isn't worth it. You can interpret ECH as an effort to move the ratio, maybe China was willing to spend $5000 and annoy a thousand people to block a cartoon site criticising their internal policies, but is it willing to sped $50 000 and annoy a ten thousand people? How about half a million and 100K people ?
That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make the default for a browser in China be to never even try to use ECH as well. Then they'll only annoy people trying to actively circumvent their system. They already do TCP sessionization to extract the SNI domain. Detecting ECH and then just dropping the connection at L3 is functionally equivalent.
In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.
So for example, Firefox since version 119. Or Chrome since 117
Now, for most services ECH doesn't have an encrypted target server. But the important choice in ECH was in this case it just fills that space with noise. An encrypted message also looks like noise. So you can block all the noise, in case it's secrets, or you can let through all the noise (some of which might be secrets) or I suppose you can choose randomly, but you can't do what such regimes want, which is to only forbid secrets, that's not a thing.
We've been here before. When sites starting going to TLS 1.3 lots of HN people said oh, China will just block that, easy. But the choice wasn't "Use TLS 1.3 or keep doing whatever China is happy with instead" the choice was "Use TLS 1.3 or don't connect" and turns out for a lot of the Web China wasn't OK with "don't connect" as their choice, so TLS 1.3 is deployed anyway.
The great firewall was updated to support inspection of TLS 1.3. They didn’t just decide it was whatever and let everything through. It was easier to just update their parsing than to force everyone to turn it off, so they did that instead. Perfect forward secrecy was a thing before TLS 1.3, and they’ve found other methodology to accomplish what they want.
For ECH, China can just require you turn it off. Or distribute their own blessed distribution. It’s the more marginal censorship regimes that will be in an interesting spot. Especially ones where the ISPs are mostly responsible for developing the technical measures.
> The great firewall was updated to support inspection of TLS 1.3.
To actually "inspect" TLS 1.3 you need the keys which are chosen randomly for each session by the parties - so either (1) you have a mathematical breakthrough, (2) you have secured co-operation from one or both parties (in which case they could equally tell you what they said) or (3) in fact you don't have inspection.
As you observe forward secrecy was already possible in TLS 1.2 and China's "Great firewall" didn't magically stop that either. In fact what we see is that China blocks IP outright when it doesn't want you to talk to an address, the protocol doesn't come into that. What we changed wasn't whether China can block connections, but how easy it is to snoop those connections.
> For ECH, China can just require you turn it off
So did they? Remember, I'm not talking about some hypothetical future, this technology is actively in use today and has been for some time.
I don’t understand what your point about TLS 1.3 is. It’s only relevant if you’re doing a downgrade attack (or equivalently, using an active middleware box). TLS 1.3 itself is not vulnerable to this because it (a) doesn’t have non-PFS suites to downgrade to and (b) protects the cipher suites by including them in the key exchange material. But if the server supports TLS 1.2, an active MITM can still downgrade to it if the client doesn’t demand TLS 1.3 specifically (which browsers do not by default). It won’t matter to China until there are lots of TLS 1.3-only websites (which hasn’t happened yet).
China was already leaning on passive DPI and L3 blocking before TLS 1.3 complicated (but as I said, did not preclude) downgrading to PFS ciphers. The reason being that for about the last 10 years, many sites (including default CDN settings) used SSL profiles that only allowed PFS ciphers. For such a server, downgrade attacks are already not useful to the Great Firewall, so adding TLS 1.3 to the mix didn’t change anything.
> So did they? Remember, I'm not talking about some hypothetical future, this technology is actively in use today and has been for some time.
Google Chrome (for example) will now use ECH if the website has the relevant DNS record - but it doesn’t use the anti-censorship mechanism in the spec to make requests to servers that haven’t enabled it look like they may be using ECH. This, combined with the fact that China can just not serve the relevant DNS record by default, means it doesn’t really impact the great firewall.
This is actually a good example of the non-technical side of this: Chrome could send a fake ECH on every request, like the spec suggests. This would perhaps make China block all Chrome traffic to prevent widespread ECH. But then Chrome would lose out on the market share, so Google doesn’t do it. Technical solutions are relevant here, but even the most genius anti-censorship mechanism needs to content with political/corporate realities.
> if the server supports TLS 1.2, an active MITM can still downgrade to it
Nope. That's specifically guarded against, so double good news. 1) You get to learn something new about an important network protocol and 2) I get to tell you a story I enjoy telling
Here's the clever trick which is specified in RFC 8446 (the TLS 1.3 RFC)
In TLS we always have this "Random" field in both Client Hello and Server Hello, it's 32 bytes of random noise. At least, that's what it usually is. When a server implements TLS 1.3 but it receives a connection (in your scenario this is from a middlebox, but it might equally be somebody's long obsolete phone) which asks for TLS 1.2 then when it fills out the Random for this connection the last eight bytes aren't actually random, they spell "DOWNGRD" in ASCII and then a 01 byte. If the client seems to ask for any older version of TLS which is supported then the server writes DOWNGRD and then a 00 byte instead.
As you hopefully realise this signals to a client that a MITM is attempting to downgrade them and so they reject the failed attack. You very likely have never seen your web browser's diagnostic for this scenario, but it's very much a failure not some sort of "Danger, Chinese government is spying on you" interstitial, because we know that warning users of danger they can't fix is pointless. So we just fail, the Chinese government could choose to annoy its citizens with this message but, why bother? Just drop the packets entirely, it's cheaper.
You might wonder, why Random ? Or, can't the MITM just replace this value and carry on anyway ? Or if you've got a bit more insight you might guess that these questions answer each other.
In TLS the Client and Server both need to be sure that each connection is different from any others, if they didn't assure themselves of this they'd be subject to trivial replay attacks. They can't trust each other, so to achieve this both parties inject Random data into the stream early, which means they don't care if the other party really used random numbers or just (stupidly) didn't bother. Shortly after this, during setup, the parties agree on a transcript of their whole conversation so far.
So, if the Random value you saw is different from the Random number your conversation partner expected, that transcript won't match, connection fails, nothing is achieved. But if the Random value isn't changed but somehow we ended up with TLS 1.2 it says DOWNGRD and a TLS 1.3 capable client knows that means it is under attack and rejects the connection, same outcome.
Now, I said there was an anecdote. It's about terrible middle boxes, because of course it is. TLS 1.3 was developed to get past terrible middle boxes and it was mostly successful, however shortly after TLS 1.3 non-draft launch (when the anti-downgrade mechanism was enabled, it would not be OK to have anti-downgrade in a draft protocol for reasons that ought to be obvious) Google began to see a significant number of downgrade failures, connected to particular brands of middlebox.
It turns out that these particular brands of middlebox were so crap that although they were proxying the HTTP connection, they were too cheap to generate their own Random data. So your TLS 1.3 capable browser calls their proxy, the proxy calls the TLS 1.3 capable server, and the proxy tells both parties it only speaks TLS 1.2, but it passes this bogus anti-downgrade "Random" value back as if it had made this itself, thus triggering the alarm.
Obviously on the "Last to change gets the blame" basis Google had customers blaming them for an issue caused ultimately by using a crap middlebox. So they actually added a Chrome feature to "switch off" this feature. Why do I mention this? Well, Chrome added that feature for 12 months. In 2018. So, unless it is still 2019 where you are, they in fact have long since removed that switch and all browsers enforce this rule. That 12 months grace gave vendors the chance to fix the bug or, if they were able to, persuade customers to buy a newer crap middlebox without this particular bug, and it gave customers 12 months to buy somebody else's middlebox or (if they were thus enlightened) stop using a middlebox.
> In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.
I doubt the Chinese government would care about that. They don't depend on the west for their online services any more than we depend on them. All that would happen is that the internet would bifurcate to an even greater degree than it already has.
It's extremely helpful at home in the west as a countermeasure against data monetization and dragnet surveillance. It certainly isn't perfect but at least it reduces the ability of ISPs to collect data on end users as well as forcing the government to formally move against the cloud providers if they want the data. Not that I want the cloud providers having my data to begin with but that's a different rant.
HTTPS is the name of a protocol, which is mostly used to make the World Wide Web work, but we do lots of other things with it, such as DNS-over-HTTPS aka DoH.
However HTTPS is also the name of a type of DNS record, this record contains everything you need to best reach the named HTTPS (protocol) server, and this is the type of record your parent didn't previously know about
In the boring case, say, 20 years ago, when you type https://some.name/stuff/hats.html into a web browser your browser goes "Huh, HTTPS to some.name. OK, I will find out the IPv4 address of some.name, and it makes a DNS query asking A? some.name. The DNS server answers with an IPv4 address, and then as the browser connects securely to that IP address, it asks to talk to some.name, and if the remote host can prove it is some.name, the browser says it wants /stuff/hats.html
Notice we have to tell the remote server who we hope they are - and it so happens eavesdroppers can listen in on this. This means Bad Guys can see that you wanted to visit some.name. They can't see that you wanted to read the document about hats, but they might be able to guess that from context, and wouldn't you rather they didn't know more than they need to?
With the HTTPS record, your web browser asks (over secure DNS if you have it) HTTPS? some.name and, maybe it gets a positive answer. If it does, the answer tells it not only where to try to connect, but also it can choose to provide instructions for a cover name to always use, and how to encrypt the real name, this is part of Encrypted Client Hello (or ECH)
Then the web server tells the server that it wants to talk to the cover name and it provides an encrypted version of some.name. Eavesdroppers can't decrypt that, so if many people share the same endpoints then eavesdropper can't tell which site you were visiting.
Now, if the server only contains documents about hats, this doesn't stop the Secret Hat Police from concluding that everybody connecting to that server is a Hat Pervert and needs to go to Hat Jail. But if you're a bulk host then you force such organisations to choose, they can enforce their rules equally for everything (You wanted to read News about Chickens? Too bad, Hat Jail for you) or they can accept that actually they don't know what people are reading (if this seems crazy, keep in mind that's how US Post worked for many years after Comstock failed, if you get a brown paper package posted to you, well, it's your business what is in there, and your state wasn't allowed to insist on ripping open the packaging to see whether it is pornography or communist propaganda)
Cloudflare provides a very large haystack for this, but even for an nginx server with no CDN, it's still useful to prevent the hostname from being sent in the clear before the TLS connection is negotiated. This still hides the hostname from casual eavesdroppers, who now only know what IP you're connecting to, and would need need out-of-band information to map the IP back to a hostname. And they couldn't ever be 100% sure of that, because they wouldn't know for certain whether there are additional vhosts running on a given server.
I think you might be surprised at how heavily SNI is leveraged at places like GoDaddy, Bluehost, and other similar providers to host sites from hundreds of completely unrelated businesses on the same IP address.
Yes this reads like vacuous AI slop and and the **randomly bolded** text everywhere is a **dead giveaway**. At this point it's becoming a stronger signal than em-dashes.
I don't know that the accuracy afforded by LOC would be enough to pinpoint objects inside a house, though the optional fields may perhaps be used to provide room/rack location.
Lat/lon are in thousandths of a second of arc. If I did my math right, that means the worst-case precision is a hair over 3cm. Altitude is in centimeters, so on a comparable scale.
Looks to me like it is accurate enough to locate even the smallest network-connected devices! Provided someone doesn't invent wifi-connected rice grains, of course.
Not a fan of future products being announced as if they are here but are basically is still in "Internal Research" stages. I'm not sure who this is really helping? except creating unnecessary anticipation which we kinda all know are in this loop lately of "yes it works great, but".
I think the fundamental issue is the uncertainty of achieving AGI with baked in fundamentals of reasoning.
Almost 90% of topline investments appear to be geared around achieving that in the next 2-5 years.
If that doesn’t come to pass soon enough, investors will loose interest.
Interest has been maintained by continuous growth in benchmark results.
Perhaps this pattern can continue for another 6-12 months before fatigue sets in, there are no new math olympiads to claim a gold medal on…
Whats next is to show real results, in true software development, cancer research, robotics.
I am highly doubtful the current model architecture will get there.
AGI is not near. At best, the domains where we send people to years of grad school so that they can do unnatural reasoning tasks in unmanageable knowledge bases, like law and medicine, will become solid application areas for LLMs. Coding, most of all, will become significantly more productive. Thing is, once the backlog of shite code gets re-engineered, the computing demand for a new code creation will not support bubble levels of demand for hardware.
There's also plenty of argument to be made that it's already here. AI can hold forth on pretty much any topic, and it's occasionally even correct. Of course to many (not saying you), the only acceptable bar is perfect factual accuracy, a deep understanding of meanings, and probably even a soul. Which keeps breathing life into the old joke "AI is whatever computers still can't do".
It's still forgetting what it's talking about from minute to minute. I'm honestly getting tired of bullying them into following the directions I've already given them three times.
I think the main problem with AGI as a goal (other than I don't think it's possible with current hardware, maybe it's possible with hypothetical optical transistors) is that I'm not sure AGI would be more useful. AGI would argue with you more. People are not tools for you, they are tools for themselves. LLMs are tools for you. They're just very imperfect because they are extremely stupid. They're a method of forcing a body of training material to conform to your description.
But to add to the general topic: I see a lot of user interfaces to creative tools being replaced not too long from now by realtime stream of consciousness babbling by creatives. Give those creatives a clicker with a green button for happy and a red button for sad, and you might be able to train LLMs to be an excellent assistant and crew on any mushy project.
How many people are creative, though, as compared to people who passively consume? It all goes back to the online ratio of forum posters to forum readers. People who post probably think 3/5 people post, when it's probably more like 1/25 or 1/100, and the vast majority of posts are bad, lazy and hated. Poasting is free.
Are there enough posters to soak up all that compute? How many people can really make a movie, even given a no-limit credit card? Have you noticed that there are a lot of Z-grade movies that are horrible, make no money, and have budgets higher than really magnificent films, budgets that in this day and age give them access to technology that stretches those dollars farther than they ever could e.g. 50 years ago? Is there a glut of unsung screenwriters?
I will give you an example from just two days ago, I asked chatgpt pro to take some rough address data and parse it into street number, street name, street type, city, state, zip fields.
The first iteration produced decent code, but there was an issue some street numbers had alpha characters in it that it didn't treat as street numbers, so I asked it to adjust the logic of code so that even if the first word is alpha or numeric consider it a valid street number.
It updated the code, and gave me both the sample code and sample output.
Sample output was correct, but the code wasn't producing correct output.
It spent more than 5 mins on each of the iterations (significantly less than what a normal developer would, but the normal developer would not come back with broken code).
I can't rely on this kind of behavior and this was a completely green field straight forward input and straight forward output. This is not AGI in my book.
Did I really need to use the /s tag? But a four-year-old is occasionally correct. Are they not intelligent? My cat can't answer math problems, is it a mere automaton? If we can't define what "true" intelligence is, then perhaps a simulation that fools people into calling it "close enough" is actually that, close enough.
> There's also plenty of argument to be made that it's already here
Given you start with that I would say yes the /s is needed.
A 4 year old isn’t statistically predicting the next word to say; its intelligence is very different from an LLM. Calling an LLM “intelligent” seems more marketing than fact based.
I actually meant that first sentence too. One can employ sarcasm to downplay their own arguments as well, which was my intent, as in that it might be possible that AGI might not be a binary definition like "True" AI, and that we're seeing something that's senile and not terribly bright, but still "generally intelligent" in some limited sense.
And now after having to dissect my attempt at lightheartedness, like a frog or a postmodern book club reading, all the fun has gone out. There's a reason I usually stay out of these debates, but I guess I wouldn't have been pointed to that delightful pdf if I hadn't piped up.
When an agent can work independently over an 8 hour day, incorporating new information and balancing multiple conflicting goals—then apply everything it learned in context to start the next day with the benefit of that learning, repeat day after day—then I'll call it AGI.
If you speak with AI researchers, they all seem reasonable in their expectations.
... but I work with non-technical business people across industries and their expectations are NOT reasonable. They expect ChatGPT to do their entire job for $20/month and hire, plan, budget accordingly.
12 months later, when things don't work out, their response to AI goes to the other end of the spectrum -- anger, avoidance, suspicion of new products, etc.
Enough failures and you have slowing revenue growth. I think if companies see lower revenue growth (not even drops!), investors will get very very nervous and we can see a drop in valuations, share prices, etc.
> their expectations are NOT reasonable. They expect ChatGPT to do their entire job for $20/month and hire, plan, budget accordingly.
This is entirely on the AI companies and their boosters. Sam Altman literally says gpt 5 is "like having a team of PhD-level experts in your pocket." All the commercials sell this fantasy.
This is really the biggest red flag, non-technical people's (by extension investors and policymakers) general lack of understanding of the technology and its limitations.
Of course the valuation is going to be insanely inflated if investors think they are investing in literal magic.
In general yes. But here we talk about businessmen who are paid quite a lot of money literally to make decisions like these.
It is kind of like when a cop allows his gun to be stolen. Yes, the criminal is the guilty, but also the cop was the one person supposed to guard against it.
> If you speak with AI researchers, they all seem reasonable in their expectations.
An extraordinary claim for which I would like to see the extraordinary evidence. Because every single interview still available on YT form 3 years ago ...had these researchers putting AGI 3 to 5 years out ...A complete fairy tale as the track to AGI is not even in sight.
If you want to colonize the Solar System the track is clear. If you to have Fusion, the track is clear. AGI track ?
Fair point, and I should be more clear. The AI researchers I speak with don't expect AGI and are more reasonable in trying to build good tech rather than promising the world. My point was that these AI researchers aren't the ones inflating the bubble.
Hyperscalers are only spending less than half of their operating cash flows on AI capex. Full commitment to achieving AGI within a few years would look much different.
The way ads are run these days is almost completely wrong!
- Lies are ok
- Thrusting your product in a users face, doesn't care if the user cares, Just because I like golfing, doesn't mean every new golf ball brand needs to hit me up all the time.
- Product with Money wins, not necessarily the right product
- Most people are oblivious to their psychological drivers, Ad makers have learnt to exploit those to drive sales.
This is one area AI can be very helpful as it improves, I face a problem, I let my agent loose and it finds the right solution and thus right products, provides comparative data for me to choose without the products being thrust in my face everywhere I go (behavioral ads) or also when I don't need it.
A lot of marketing is done badly. These bad ways are the most glaring and people sometimes think that all marketing is like that.
In reality, there is a lot of marketing that is completely unnoticeable. Some people would not even consider those things marketing. That is marketing done well (or at least better).
Unfortunately, when that makes up a trillionth of a percent of all ads, it appears to me as though the overall idea is terrible, with a few who got lucky here and there.
One of the best examples of your second point is that tweet that went something like "I bought a toilet seat and now I'm getting ads for toilet seats everywhere I go". It's annoying and not even productive for the advertiser.
Apparently some of the very best-converting ads are repeat sales. Of course it helps if the product is obviously consumable, but I'm told that this counterintuitive strategy actually works well. Maybe it's because they can track conversions but not product returns, so maybe you're searching for a better one after returning the first purchase.
I would be willing to believe that most toilet seats are bought by people that buy toilet seats as part of their job (builders, plumbers and maintenance). They might buy more in a month than you buy in your life.
Follow up ads might be very productive even if you personally get swept into the professional toilet installer ad pipeline inappropriately.
I seem to get a stream of ads for terrible products on YouTube on my phone (I get completely different ads when watching on an Apple TV) - by this point I'm convinced it is Google punishing me into signing up for YouTube Premium...
It’s insane how many are some random idiot in their car, filming with a phone, trying to act like they’re having a conversation with you before it completely switches to sales mode and they’re (terribly) reading a script. They don’t even put EFFORT into ads anymore it seems.
Then you want to watch a video and it’s 3 pre-roll ads, 90 seconds of video, then another 2-3 ads.
I’ll never feel bad about using Adblock, and I hate the idea of rewarding these companies’ behavior with money.
FWIW, YouTube premium is one of my most worthwhile family subscriptions.
Anytime I use YT on a browser/profile that I'm not logged into, it's so jarring that I immediately fix it.
Edit: I dumped Spotify for YT music. I thought I liked Spotify better, though, so I tried again recently, and it turns out I didn't, so now I get YT and music for not much more than just Spotify. Definitely worth it in that context.
Its not the sandboxing, its the access to user data that apps can request. a mobile OS allows apps to request and be granted all kinds of permissions, and 80% of the world population doesn't really understand what all things are possible for each of the permissions they give to an app. For example being able to export the whole contact list, or read all files in folders (where users may have saved notes with passwords) or real time tracking of gps location with wifi mac address sniffing, listen in on conversations, be able to screenshot other apps, trigger touch events... none of this a sandbox can prevent.
When there are problems reported about an app, there has to be a known party to hold accountable. I agree that a developer path that is complex enough that only people who know all the impacts are able to use to side load random apps they own or from someone they can trust, but the general population has to be protected unless at the individual level they are savvy.
The problem with simple prompts it it gives AI the most leeway to do what it thinks is important, which may work in case of just convert from one language to another (even in those cases it took its own liberties - good or bad).
This won't work when devising a new application from scratch or where you are expecting consistent agentic output to be usable in a predictable situation.
Apparently that is part of implementing ECH (Encrypted Client Hello) in TLS 1.3 where the DNS hosts the public key of the server to fully encrypt the server name in a HTTPS request. Since Nginx and other popular web servers don't yet support it, I suspect the 7% of requests are mostly Cloudflare itself.
(1) https://radar.cloudflare.com/?ref=loworbitsecurity.com#dns-q...