"Doesn't use analytics = respects your privacy"
Meanwhile, Brave stopped this tracker: https://static.cloudflareinsights.com/beacon.min.js/vef91dfe02fce4ee0ad053f6de4f175db1715022073587 "Doesn't use analytics = respects your privacy"
Meanwhile, Brave stopped this tracker: https://static.cloudflareinsights.com/beacon.min.js/vef91dfe02fce4ee0ad053f6de4f175db1715022073587This reputation profile is then used as part of the heuristic behind CloudFlare Turnstile's "Are you human?" checkbox.
This is why browsers that have NoScript enabled by default for all sites (e.g. Tor Browser), cause Cloudflare-proxied sites to throw endless security interstitials and never let you through, even when you disable NoScript for the protected website. Without reputation-profile data gathered from other sites, Cloudflare just sees a fresh browser profile making its first connection ever to some obscure site that nobody would ever actually visit as the first thing they do on a new computer. And so it thinks your browser is a (not-very-clever) bot.
I don't think it's possible for a site owner to opt out of this reputation-profile data gathering, while still relying on Cloudflare's DDoS protection.
However, I also don't believe that the data Cloudflare gathers via this route is sold to third parties. (Someone please correct me if that's wrong.)
I’m sure the author isn’t aware of it and it’s just an oversight, but still.
Why does a single static html file even need a CDN?
But anything that can be served from a cdn is better off if it fits. From a latency and bandwidth efficiency perspective
Hint: it bloody doesn't.
If this static site is sitting on a CDN or Github Pages or something, then sure, there's no need to mask its IP address.
But if this static site is hosted on a cheap VPS or on a home PC with a residential Internet connection — or generally, anything with a monthly bandwidth usage cap — then any teenager who learns its true IP address (and then checks out that IP address's provenance with a whois(1)) could decide to pay $5 to throw a botnet at it for an hour — just because they know they can take it down by spending enough of its bandwidth, and want to try it, to be able to brag to their friends that they took something down.
(Yes, teenagers today do that. The most DDoS-ed things in the world today are Minecraft servers — because teens like messing with other teens.)
---
Also, half of what makes Cloudflare useful for "DDoS protection" isn't actually its "bot fight" security system, but rather its caching layer combined with its lack of egress costs (at least until you get forced into their Enterprise billing.)
If you are hosting your content on e.g. a public S3 bucket, where you're billed for egress bandwidth, but where S3 also sends sensible long-expiry Cache-Control headers; and you put Cloudflare in front of that S3 bucket (even just Cloudflare's free-tier offering!); then suddenly your S3 bucket will only be serving requests for each resource a few times a day, rather than for every single request. 99.999% of the traffic to your bucket will be a cache hit at the Cloudflare level, and so will be only a conversation between Cloudflare and the customer, not between Cloudflare and S3. So, even in the face of a DDoS, your billing won't explode.
This is probably beyond the author's control, but they shouldn't host it somewhere that can inject scripts outside their control (like Cloudflare) and then claim "privacy".
(The Cloudflare script makes a request to `/cdn-cgi/rum`, with the full page URL in its JSON payload at `timingsV2.name`.)
>Doesn't use a server = no downtimes
Except there is a server, whatever and wherever it is behind notepadtab.com.
I think PWAs might have something like that, but haven't tested it in a normal browser or tried building one.
You're probably asking about HTTPS, in which case: No. The first rule about HTTPS is no caching, because you want to validate that what you see is from the server and you can't prove that with a cache.
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
edit: I tried this and common browser security no longer allows this type of thing. 10 years ago it may have worked.
data:text/html,<body contenteditable oninput="history.replaceState(0,0,'%23'+btoa(document.body.innerHTML))" onload="if(location.hash)document.body.innerHTML=atob(location.hash.substring(1))">#SGVsbG8sIHdvcmxkIQ==Much better than a relying on an HTTP response from someone else's computer.
How can I silence the Firefox security error messages?
Anyway this one works in FF with my settings
https://gist.github.com/joakin/f05fd565e8df77a805e21d2d3469d...
> - Doesn't need cookies = immune to data loss by accident
How is this immune if you have to remember to save it manually? That seems much worse than relying on cookies. Sure you can maybe restore it from the browser history, but if cookies are not considered reliable, then the history even more so. It's easier to delete history than cookies.