rapawel

The tool only detects a subset of paid Cloudflare users - specifically those with the default ECH settings. If your site shows as undetermined, it likely means you're on a free plan or a paid plan with ECH enabled.

From what I've observed:

- Free plans: ECH is forcefully enabled (sni=encrypted)

- Paid plans: ECH is disabled by default (sni=plaintext), but can be manually enabled

The tool can only definitively distinguish between free plans and paid plans that use the default ECH settings.

There are occasional false positives, but querying different Cloudflare data centers usually resolves this. I've found that switching VPN servers (which routes through different CF edge locations) eventually gives the correct result.

Example website with paid subscription: Substack https://experiments.pawelpokrywka.com/cloudflare-subscriptio...

Thanks for your response. I ran a test but I'm not sure if it's working as expected. I performed a Google search on my mobile device for "inurl:amp.cnn.com." However, when I clicked on a result, the page I saw did not appear to use AMP--it redirected me to edition.cnn.com instead.

I published the repository with source code of the demo. The README contains detailed explanation how the demo works as well as instructions on how to host the demo yourself.

https://github.com/pepawel/stretching-prefetching

Here is the repo. The README contains detailed instructions on how to host the demo yourself. https://github.com/pepawel/stretching-prefetching

I have created a repository containing source code and detailed instructions on how to host the demonstration yourself. https://github.com/pepawel/stretching-prefetching

Thanks! Yep, I’m planning to publish the repo shortly — just doing a quick cleanup first. I’ll update the thread as soon as it’s live.

Thanks for checking it out — and good questions.

You're right: the site is SXG-enabled, and the point of the demo is to show that Google can prefetch and serve it even when you're offline — but only if you search for a specific phrase on Google. Random searches won’t trigger the right preload.

The 4-digit code is intentionally hardcoded — it's not a security check, but a way to make sure the user follows the instructions and gives Google a bit more time to prefetch the content before going offline.

The progress bar also helps with timing — making sure the preload has a chance to complete.

After reading your comment, I added a link to a blog post in the final step of the instructions, in case the demo doesn't work as expected. (If the page is cached from an earlier visit, a refresh helps — it's got a long browser cache.)

Thanks again for digging into it!

Thanks for the detailed feedback — really appreciate it!

You're right that the demo relies on Google Search specifically (not DuckDuckGo), and that should probably be made even clearer in the instructions. I do mention “search Google” in step 3, but I’ll look into making that more explicit up front.

As for airplane mode: the idea is to go offline after Google has had time to prefetch the page. That’s why the instructions say to start with a stable internet connection — and the page does show a warning if you go offline too early. But I totally get how that could still be confusing, especially if it didn’t work the first time.

A tip: once you're on the "You're offline" page, wait at least 3 seconds and observe the dinosaur. Something may happen.

And good point about wanting to know what’s going on. I tried to keep the experience surprising for some users, but I see how having the technical context up front can enhance it for others. I’ll consider adding an “explain first” option in the future.

Thanks again for giving it a go!

Yes, exactly - well put.

The key difference from AMP is that the site signs the content and it’s attributed to their origin, not Google’s. So, while it’s served from Google’s cache, it still counts as the publisher’s page in terms of origin and trust.

Thanks, fair point.

I skipped technical terms like “prefetch” or “SXG” in the title to make it more approachable and spark curiosity — but I get how that could feel misleading.

You're right that prefetching counts as a visit in some sense. The point of the demo was to highlight how unexpected it can feel to load a site while offline, even if you never actively opened it before.

Thanks!

The demo uses 2 html pages - one for instructions, the second one for the actual site that is prefetched. But maybe I will create a repo with it.

HN is a perfect candidate to integrate Signed Exchanges - it's a link aggregator, the type of website SXG authors have in mind while designing this standard.

Really appreciate that! Debugging this was a wild ride, but sharing the journey makes it all worth it. Glad you found it valuable!

Amazing, I always wanted to visualize wifi signals.

Appreciate that! If you're implementing SXG on your landing page and run into any issues, feel free to reach out. Hope it works smoothly!

- 63% of sites receive AI traffic overall - 98% of AI traffic is sent by three chatbots - ChatGPT is the biggest referrer, accounting for 50% of AI traffic - 0.17% of the average website’s traffic comes from AI chatbots - The smallest websites get the greatest % of total traffic from AI

- 93% of employees can work remotely at least one day a week. - 45% of respondents have the option to work fully remote (5days aweek). - Flexibility of place and no commute among the main reasons why people choose remotework. - Remote work leads to a sense of disconnection from co-workers in almost half of employees. - The majority of employees do not feel threatened by the possibility of AI taking over their jobs. - Almost 70% of those who relocated for a job are happywiththeirdecision. - When it comes to new job opportunities, salary and the option to work remotely take the spotlight. - Switzerland continues to hold the top spot as the highest-paying country in Europe for IT professionals. - Most respondents agree that the ideal hiring process consists of only 2 interview stages.

If you missed it, here is the first part, revised and updated: https://blog.pawelpokrywka.com/p/how-i-took-lcp-down-under-3...

The speed of your website is considered good if the value of the Largest Contentful Paint (LCP) metric is below 2500 ms. I’m going to show you how I took it below 350 ms on a dynamic, production website with a lot of images, even on a slow connection.

Kernel update requires a reboot, which means one has to provide a passphrase to unlock the disk. To provide a passphrase a keyboard and physical presence are required. This is inconvenient in headless and remote setups. As a result, people may choose to keep using old kernels, which may lead to security issues.

To address this problem, I created MIT-licesed tool that does the reboot, but asks for the passphrase before, not after. This way entire operation could be performed remotely via ssh.

If you are interested in details, you can read my post about it here: https://blog.pawelpokrywka.com/p/rebooting-linux-with-encryp...

I hope cryptreboot will help people to better secure their systems. If you have questions or feedback, I can answer them here in comments.

I came across an article whose author described the process of creating a smart contract and deploying it to the Ethereum mainnet. He also published the source code.

I started to wonder: Is it possible to use this public information in order to find Ethereum address of this person?

It would be fun to see how much money he holds ;-)