Forem: Romeo Mihalcea

ISP proxies, AI crawlers, and the slow death of datacenter IPs: 2026 in numbers

Romeo Mihalcea — Tue, 05 May 2026 12:15:39 +0000

TL;DR

Bots passed humans on the open web. IP reputation feeds stopped working for residential traffic. IPv4 prices collapsed. AI crawlers became a measurable tax on public sites. And Europe finally started writing big GDPR checks while only fining 1.3% of complaints. If you ship anything that touches the public web at scale, the IP infrastructure you set up in 2022 is doing more harm than good in 2026.

The headline numbers:

51% of all web traffic in 2024 was automated. Bots beat humans for the first time in a decade. (Imperva 2025 Bad Bot Report)
37% was bad bots specifically, up from 32% in 2023. Sixth straight yearly increase.
2.8% of websites tested in 2025 were fully protected against bots, down from 8.4% the year before. (DataDome 2025 Global Bot Security Report)
78% of residential-IP sessions in a 4-billion-session study evaded conventional IP reputation feeds. (GreyNoise / IPInfo, April 2026)
<$21/IP for large-block IPv4 transfers in May 2025. Roughly a 10-year low. (IPv4.Global)
+187% YoY growth in AI-driven traffic in 2025. (HUMAN Security)
62% → 90% of investment firms using alternative data, in two years. (Lowenstein Sandler)
€1.15B in GDPR fines from EU DPAs in 2025; only 1.3% of complaints actually result in a fine. (EDPB; noyb)

Bots overtook humans in 2024 and the gap keeps widening

If you've shipped a scraper in the last two years you already feel this. The data behind the gut feeling: 51% of web traffic in 2024 was automated, per Imperva. Bad bots specifically were 37%, up from 32%. That 5-point jump is the largest single-year increase in Imperva's twelve-year time series.

The defense side moved the wrong way. DataDome tested over 16,900 sites across 22 industries in 2025 and found only 2.8% were fully protected, down from 8.4% in 2024. 61% of domains failed to detect a single test bot.

That's not a story about bot mitigation getting worse. It's a story about generative AI lowering the cost of writing request-level automation. People who couldn't afford a developer can now prompt one.

The target surface shifted too. 44% of advanced bot traffic now hits APIs instead of HTML pages. Verizon's 2025 DBIR puts the median rate of credential-stuffing activity across SSO providers at 19% of daily auth attempts. Roughly one in five logins at identity-provider scale is machine-driven. That's wild.

Why datacenter IPs stopped working

A joint GreyNoise / IPInfo study published in April 2026 examined 4 billion edge-attack sessions over three months. The findings:

39% of those sessions came from residential IPs.
78% of the residential-IP sessions evaded IP reputation feeds entirely.
89.7% of the malicious residential IPs were active for under a month before rotating out.

Static IP blocklists, the backbone of anti-bot defense for a decade, no longer carry the signal they used to.

Detection now has to come from somewhere else: behavior over time, browser fingerprint, session history, telemetry. The IP alone tells defenders very little.

That sets up a weird market. Residential-class IPs are the dominant workaround, and the underlying economics got cheap fast.

IPv4 prices collapsed

Large-block (/16+) transfer prices fell to under $21 per IP in May 2025, the lowest in roughly a decade per IPv4.Global. 8,062 IPv4 transfers were recorded globally in 2025, near an all-time high in transfer volume. Monthly lease rates sit at roughly $0.40 to $0.50 per IP.

The structural reason: IPv6 finally caught up. Google reports US IPv6 share crossed 50% in February 2025; France hit ~86% by February 2026. New enterprise workloads are migrating to v6, and incumbents are liquidating hoarded v4 blocks. An ISP proxy is, structurally, an IPv4 lease on a reputable consumer-ISP ASN with the right reverse DNS pointer. Those numbers set the floor on unit economics across the sector.

The AI crawler problem nobody had two years ago

This one sneaks up on you if you run any public site with content.

Cloudflare measured AI crawlers at ~8.7% of all HTML request traffic in 2025. Googlebot was 4.5%; the other AI bots together were ~4.2%. User-driven AI crawls (someone hits "research this" in their assistant) grew 15× year over year.

HUMAN Security's 2026 State of AI Traffic benchmark reports AI-driven traffic up 187% YoY, with agentic-browser traffic up 7,851%. Akamai counted 25 billion AI-bot requests to commerce sites in July and August 2025 alone. DoubleVerify attributes 86% of the General Invalid Traffic increase in 2025 to AI crawlers, not classical fraud.

If you're an SRE, AI crawlers are now a meaningful share of your tail-latency budget, and they aren't all polite about robots.txt. If you're building anything that needs a clean read of the live web at scale (alt data, market intel, training corpora) you're competing for IP infrastructure with everyone running an LLM.

Comparison: datacenter vs rotating residential vs ISP proxies

If you're picking infra in 2026, here's the practical shape of the tradeoff:

Dimension	Datacenter	Rotating residential	ISP (static residential)
ASN type	Hosting (AWS, Hetzner, GCP)	Consumer ISPs via real devices	Consumer ISPs, hosted on servers
IP reputation pass rate	Low. Detected within hours on protected sites.	High. ~78% evade reputation feeds.	High. Same ASN trust as residential.
Session stability	High	Low. IP rotates on device reconnect.	High. Static IPs, server-grade uptime.
Speed	Fast (~ms)	Variable, often slow	Fast (~ms)
Best fit	Internal tools, low-protection targets	Throwaway high-volume scrapes	Long sessions, logged-in flows, ad verification, SERP
Worst fit	Anything with modern bot detection	Cart fills, auth flows, multi-step scrapes	Pure rotation needs

The middle column is where rotating residential pools shine. The right column is where ISP proxies pay for themselves: anything that needs the same IP across a 20-minute logged-in session, or geo-stable for a SERP scrape, or trusted enough to render real ads instead of cloaked decoys.

What teams are actually buying this stuff for

Five workloads dominate the buyer mix in 2026, and the numbers behind each are big enough to matter:

Retail price monitoring. Global e-commerce hit $6.42T in 2025, 20.5% of all retail (eMarketer). McKinsey's classic finding still holds: a 1% price improvement yields about 8.7% operating-profit lift. At that elasticity a continuous competitor scan pays for itself in weeks. Datacenter scrapes against major retailers now get silently poisoned with bad prices instead of blocked, which is worse than blocked.
Ad verification. US digital ad revenue hit $294.6B in 2025 (IAB/PwC). Programmatic was $162.4B of it. The ANA reports $26.8B of programmatic spend leaked to inefficiency in Q2 2025 alone, up 34% in two years. You need real residential IPs in the right geos to see what campaigns actually look like for end users.
Travel fare aggregation. Imperva found 48% of travel-industry traffic in 2024 was bad bots, the highest share of any sector. Skift reports the top four OTAs control 96% of the sector's $58B in revenue. Metasearch teams need stable residential egress just to keep rates fresh.
SEO / SERP rank tracking. SEO software is an $84.9B market in 2025 (Fortune Business Insights), forecast to $154.6B by 2030. Personalized SERPs make rank tracking from scraping farms unreliable; agencies need geo-distributed residential egress.
Alternative data for hedge funds. This one's the sleeper hit. Investment firms using alt data jumped from 62% in 2023 to 90% in 2025 (Lowenstein Sandler). 89% plan to grow budgets. Two-thirds already spend $1M+ per year. Grand View projects the alt-data market at $135.7B by 2030 from $11.65B in 2024, a 63.4% CAGR.

If you've wondered who writes the checks for residential IPs at industrial scale, it isn't marketing teams. It's quants and LLM labs.

The legal track moved more than most teams realize

Two years of case law and regulation worth knowing before you ship a commercial scraper:

US: scraping public data is defensible. Van Buren v. United States (2021) read the CFAA's "without authorization" language narrowly. The Ninth Circuit reaffirmed hiQ Labs v. LinkedIn in 2022; that case eventually settled for $500K plus a permanent injunction and data destruction. Public-data scraping at the appellate level is, post-hiQ, on solid ground.

EU: enforcement scaled, but base rate stays low. National DPAs issued €1,145,760,374 in GDPR fines during 2025 (EDPB). Cumulative fines since 2018 sit above €4.2B across 6,680+ decisions. The counter-signal worth pinning to your wall: only 1.3% of complaints brought to EU DPAs end in a fine, per noyb. Headline totals are real. The base rate per complaint is much lower than the totals imply.

EU Data Act and AI Act. The Data Act applies from 12 September 2025. The AI Act's Article 53 requires general-purpose AI providers to respect Article 4(3) machine-readable opt-outs and publish a "sufficiently detailed summary" of training data, including main scraped domains. Territorial scope follows EU market placement, so EU training-data compliance effectively exports anywhere a model is sold in Europe.

California woke up. The California Privacy Protection Agency's largest fine to date is $1.35M against Tractor Supply in September 2025, on Global Privacy Control non-compliance. The CPPA has telegraphed that GPC compliance is the priority enforcement vector through 2026.

None of this is legal advice. Talk to a lawyer before scaling anything commercial.

FAQ

What's an ISP proxy in plain terms?
A server-hosted IP address that originates from a consumer ISP's ASN (Comcast, Verizon, BT, Deutsche Telekom, etc.) instead of a datacenter ASN (AWS, Hetzner, GCP). Sometimes called a static residential proxy. From a target site's perspective it looks like home broadband, but it runs on server hardware for speed and session stability.

Why not just use rotating residential IPs?
For workflows that need a stable session (logged-in scrapes, multi-step flows, cart fills, ad verification) IP rotation breaks things. ISP proxies give you residential-grade trust without the volatility.

Are datacenter proxies actually dead?
For modern bot-protected targets, in practice yes. They still work for low-protection internal tools, certain APIs, or staging. They will not survive a price-monitoring run against a Tier-1 retailer or a SERP scrape on a tracked term.

How much do ISP proxies cost in 2026?
Underlying IPv4 lease rates are about $0.40 to $0.50 per IP per month, after large-block transfer prices fell under $21 per IP in 2025. Retail pricing has tracked those costs down. Single-digit dollars per IP per month is the realistic range at scale.

Is scraping legal?
Public-data scraping in the US is defensible after Van Buren and the Ninth Circuit's reaffirmation of hiQ. EU collection requires GDPR, EU Data Act (effective 12 Sept 2025), and AI Act compliance for any training-data use. Talk to a lawyer before scaling anything commercial.

How big is the proxy market really?
Mordor Intelligence sizes the residential proxy server software market at $122M in 2025, growing to $148M by 2030 (3.98% CAGR). The downstream markets that consume the IP layer are where the growth is: web scraping at $1.03B → $2.23B by 2031, alternative data at $11.65B → $135.7B by 2030.

What changed in the last 12 months specifically?
Three things. AI crawler traffic became a measurable, named tax on the public web. IPv4 prices collapsed alongside IPv6 finally crossing 50% in major markets. And IP reputation feeds, the load-bearing component of bot defense for a decade, are now functionally defeated for residential traffic.

What I'd tell someone starting fresh in 2026

If you're building automation that touches the public web at scale, your IP layer is no longer set-it-and-forget-it. Datacenter IPs are first-resort blocked, rotating residential pools break logged-in flows, and the IPs that work for serious work are residential-grade with stable sessions. That's the gap ISP proxies fill, and the data behind that gap is the rest of this post.

A few honest closing notes. The Mordor residential-proxy figure ($122M) is software-revenue scope only; broader sizings that bundle bandwidth resale and DaaS spend run an order of magnitude larger. The 51% bot share number from Imperva is measured against sites under their protection (so skewed toward enterprise targets attackers hunt). Cloudflare's ~30% bot share over the full anycast network is not the same denominator. Both numbers are correct at their stated scope. Don't conflate them.

This post was written by the team behind anonymous-proxies.net. We sell ISP proxies among other products. The full long-form analysis with all 50+ data points, every primary-source citation, the mega-table, and the methodology notes lives here:

https://anonymous-proxies.net/posts/isp-proxies-statistics-2026/

What a VPN Actually Protects You From (A Developer's Threat Model)

Romeo Mihalcea — Tue, 21 Apr 2026 02:22:36 +0000

What a VPN Actually Protects You From (A Developer's Threat Model)

Every "VPN explained" post reads like a sponsored ad. Let's do this properly — at the protocol level, with the actual threats mapped to the actual mitigations.

TL;DR

A VPN mitigates Layer 3/4 threats: passive ISP observation, Wi-Fi sniffing, IP-based geolocation, and some MITM scenarios on unencrypted endpoints. It does nothing against application-layer threats: malware, phishing, logged-in session tracking, browser fingerprinting, or DNS-over-HTTPS leaks if you misconfigure it.

If you're thinking about a VPN as a security tool, map it against your actual threat model before you bother.

What a VPN actually does (at the packet level)

Your client encapsulates IP packets inside an encrypted tunnel (WireGuard uses ChaCha20-Poly1305, OpenVPN uses AES-GCM via TLS). The packets exit at the VPN server, which NATs them to the internet using its own public IP. The return path reverses it.

That's the whole mechanism. Two side effects:

Your ISP sees one flow: you -> vpn_endpoint:51820 UDP (encrypted)
Destination servers see vpn_endpoint_ip as the source

Everything marketers claim about VPNs is downstream of those two facts.

Threat model: what a VPN mitigates

1. Passive ISP observation

Without a VPN, your ISP sees every DNS query and every TLS SNI. Yes, ESNI/ECH is rolling out, but coverage is still patchy — check yourself:

# See what your ISP can observe
tcpdump -i eth0 -A 'port 53 or port 443' | grep -E "Host:|server_name"

With a VPN up, that same capture shows one encrypted flow to your VPN endpoint. Nothing else.

In the US, ISPs have been legally allowed to sell browsing metadata since the 2017 repeal of the FCC broadband privacy rules. Several EU states still mandate metadata retention under national law despite the CJEU striking down blanket retention in Digital Rights Ireland.

2. Hostile LANs

Coffee shop, hotel, conference Wi-Fi. HTTPS covers content but not the SNI, not DNS (unless you're on DoH/DoT), and not the fact that someone on the same subnet can ARP-spoof your gateway.

Quick paranoia test on a shared network:

# Are you on the same subnet as random strangers?
ip -4 addr show
arp -a | wc -l

If that number is more than 2-3, you're on a shared LAN with untrusted peers. VPN on.

3. IP-based attribution

Every request logs your source IP. Combined with the TLS fingerprint (JA3/JA4) and browser fingerprint, it becomes a durable identifier. Swapping the IP breaks the geolocation component and forces adversaries to rely on the weaker signals alone.

4. ISP-level traffic shaping

Some ISPs still throttle based on DPI-identified traffic classes. Tunneled traffic is opaque to the classifier, so it gets the default QoS treatment. Not a privacy win, but a real performance win for some users.

Threat model: what a VPN does NOT mitigate

Threat Vector	VPN helps?	What actually helps
Malware in downloaded binaries	No	Code signing verification, EDR, sandboxing
Phishing / credential theft	No	WebAuthn/passkeys, 2FA, password manager
Cross-site tracking post-login	No	Cookie isolation, container tabs, separate profiles
Browser fingerprinting (Canvas, WebGL, fonts)	Marginal	Firefox `privacy.resistFingerprinting`, Brave, Tor
TLS fingerprinting (JA3/JA4)	No	uTLS, custom client bindings
DNS leaks	Only if configured	Force DNS through tunnel, disable IPv6 or route it too
WebRTC IP leaks	Only if configured	Block WebRTC at browser level
Timing correlation attacks	No	Tor with entry guards
Application-level telemetry	No	Firewall rules, strict egress policies

The leaks you need to test

A VPN that leaks your real IP is worse than no VPN — false sense of security. Check every time you change configs:

# Real IP check
curl -s https://ipinfo.io

# DNS leak check — should show VPN provider resolver, not ISP
dig +short txt ch whoami.cloudflare @1.1.1.1
nslookup -type=txt whoami.ds.akahelp.net

# IPv6 leak (common on WireGuard if you forget ::/0)
curl -s -6 https://ipv6.icanhazip.com || echo "No v6 leak"

# WebRTC — browser-only, use https://browserleaks.com/webrtc

If any of those don't match your VPN endpoint, your config is broken.

WireGuard kill switch, the lazy way

If the tunnel drops, default route falls back to the physical interface — traffic goes out in the clear and you don't notice. Here's a minimal kill switch using the PostUp/PreDown hooks:

[Interface]
PrivateKey = <your_key>
Address = 10.0.0.2/24
DNS = 1.1.1.1

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = <peer_key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

Now if the tunnel goes down, packets get dropped instead of leaking to your ISP.

Protocols worth knowing

Protocol	Crypto	Speed	Detectable?	Notes
WireGuard	ChaCha20-Poly1305, Curve25519	Fastest	Yes (trivially)	Modern default. Tiny codebase (~4k LOC).
OpenVPN (UDP)	AES-GCM over TLS	Slower	Yes	Mature, configurable, heavier.
IKEv2/IPsec	AES, varies	Fast	Yes	Native on iOS/macOS/Windows. Survives network changes well.
Shadowsocks	ChaCha20/AES	Fast	Hard	Designed for censorship circumvention, not privacy.
AmneziaWG	WG + obfuscation	Fast	Hard	WireGuard with traffic shaping to defeat DPI.

If your threat model is "casual privacy on untrusted Wi-Fi," WireGuard is the right answer. If it's "my network actively blocks VPN protocols," you need obfuscation.

FAQ

Does a VPN make you anonymous?
No. It breaks the IP-to-identity link at the network layer. It doesn't touch application-layer identity — cookies, logged-in sessions, fingerprints. Real anonymity is a Tor problem, not a VPN problem. torproject.org is the reference.

Self-hosted VPN on a VPS — good idea?
For privacy from your ISP, sure. For privacy in general, no — you now have a single static IP tied to your payment method on the VPS provider. You've just moved the trust boundary from the ISP to Hetzner or DigitalOcean.

Is the VPN the weak link or the browser?
The browser. Fingerprinting and logged-in session tracking bypass the VPN entirely. Fix the browser first.

Does HTTPS make VPNs redundant?
No. HTTPS protects content but leaks SNI, destination IP, and timing. A VPN covers those. They solve different problems.

WireGuard vs OpenVPN — which should I run?
WireGuard unless you have a specific reason not to. Smaller attack surface, faster, modern crypto. OpenVPN wins on configurability and firewall traversal (TCP/443).

Bottom line

A VPN is a Layer 3 privacy tool with a narrow, real, measurable scope. Map it against your actual threat model, don't buy the "military-grade encryption protects you from hackers" pitch, and always test for leaks after config changes.

Full long-form version on the original site with extra context: https://anonymous-proxies.net/posts/what-does-a-vpn-protect-you-from/

What's your VPN setup? WireGuard? Tailscale? Self-hosted? Drop your config quirks in the comments — especially the kill-switch patterns, I'm collecting.

Create your own WireGuard server in minutes

Romeo Mihalcea — Sat, 21 Nov 2020 16:04:50 +0000

With the rise in privacy concerns over tech giants battling for our data I thought it would be fit to have a small talk about creating your own VPN server. Now I know there are countless of other tutorials out there but there's never enough attention over this subject.

What is WireGuard

WireGuard is the new kid, the much needed tool in the VPN world to bring everything to the next step. It is a small, fast and effective new VPN protocol that stormed everything since its early days. Very quickly it received great reviews for its performance and it is now included in the new Kernels for Linux and Android. I don't recall ever hearing about any other library to be included so fast in the Kernel so that says a lot I guess.

Wireguard is much leaner and faster when compared with other protocols and this makes it the preferred choice for many. How much faster? You can read our Wireguard vs OpenVPN article to see a comparison of the two.

How much does it cost to own my VPN server

Not much at all - with as much as $5 you can get a good VPS that can host a VPN server which handles the traffic for your entire family without breaking a sweat. Creating a server used to be a challenge but now, you can do it in 2 minutes. I suggest having a look at Digitalocean, Linode, Hetzner Cloud and others alike. Plenty of options.

My own server vs a VPN plan

Simply because we cannot trust anybody. Most of the VPN providers have to abide the law which in many cases imposes that logs are kept and offered to gov. institutions for analyzing. We're trying to avoid being processed and analysed at every move so, sending our entire data stream to a VPN provider is nothing more than just adding an extra hop in the same chain.

Having your own VPN server will break this chain and put a stop to the leak of data that we experience with ISPs or VPN providers and the process is simple. You can either let others create a secure VPN server for you or build it yourself following guides like this one.

How to create a WireGuard server

First of all, WireGuard does not have the notion of "servers". Everything is a peer and peers are connected with one another. The config files consist of 2 parts: an [Interface] which addresses the local instructions and multiple [Peer] sections which define remote connections.

What operating system to use?

I recommend Debian, the latest you can find with the selected provider. I will use Debian 10 (Buster) for this tutorial.

The first thing to do is to go ahead and add the Wireguard release channel to your sources list. The sources are like search channels for software and, without them, your operating system cannot find anything:

$ sudo sh -c "echo 'deb http://deb.debian.org/debian/ unstable main' >> /etc/apt/sources.list.d/unstable.list"
$ sudo sh -c "printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' >> /etc/apt/preferences.d/limit-unstable"

Now issue an apt update command to re-fetch the sources and we should be able to install Wireguard with apt install wireguard.

[SERVER] Create your keys

Peers connect via IP addresses but they have to authenticate before a connection can be established. Keys come in pairs (public and private) and each peer must know the other peers beforehand which means writing down to the config file the public key for each peer.

With the install of Wireguard we now have access to the wg and wg-quick commands which allows us to create our keys:

$ (umask 077 && wg genkey > wg-private.key)
$ wg pubkey < wg-private.key > wg-public.key

If you run ls -la you will see the keys have been created. You can also run cat wg-private.key to view the contents of each file.

[SERVER] Create the config file

Now that we have the keys we are almost done setting up the server. We have to create the config file and bring up the VPN interface that will listen on the selected port.

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = server+private+key+here
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

The only thing you have to change here is the eth0 interface name. On some systems it may have a different name. To get yours you can execute this handy command: route | grep '^default' | grep -o '[^ ]*$'

We have created the server config but haven't added any peers yet. That's because we need to generate the keys for the client now so we can add them to our peers list. The server will listen on the private address 10.10.0.1. You may be wondering what is the purpose of the public key because we haven't used it yet. It will be added to the client config in our next steps.

The PostUp and PostDown instructions are executed when the server is started and stopped and they enable IP forwarding so that you can exchange packets with your server. IP forwarding must also be enabled on the server by editing the */etc/sysctl.conf file and adding:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

[CLIENT] Create keys

We also need the client keys so we can add authenticated peers to the server. Repeat the steps from the server in order to generate keys but this time on the local machine. If you're on windows or MacOS you can download the Wireguard gui package and copy the keys from there.

[CLIENT] Create config file

Once you have the keys we can create the local configuration file:

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.2/24
PrivateKey = client+private+key+here
DNS = 10.10.10.1

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = server_ip_address:51820

Our client config is done. It has a local description ([Interface]), it will be allocated the 10.10.10.2 address, that's the next address after the server and it also forwards dns queries to the server.

The [Peer] in this case is the server so, before attempting a connection, we also add a peer to the server that contains our public key otherwise our connection will be refused.

/etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = server+private+key+here

[Peer]
PublicKey = client+public+key+here
AllowedIPs = 10.10.10.2/32

Time to bring up the server: wg-quick up wg0.
To bring it up automatically after restart (at boot): systemctl enable wg-quick@wg0

Connect to the server

With all peers defined and keys ready to be exchanged it is now time to connect to our server. Remember that wireguard is stateless and it will probably report a successful connection even though it is not. You should test your IP address, dns leaks and other stuff to verify the connection was made.

CNAME cloaking or how are we being tracked even with ad-blockers installed

Romeo Mihalcea — Mon, 09 Mar 2020 15:47:24 +0000

For many years we relied on regular ad blockers to clean our screen from ads, trackers and other junk but there's a way that these websites use to bypass our efforts and it works very well.

Regular ad blockers intercept your browser's requests and analyze each one to see if there are matching rules against it. The flaw is in this technique because the extension only has access to the first party (the requested url) without being able to monitor what is taking place once a request does not match any of its rules - at the DNS level for example.

In this post I'm going to explain how one can mask/cloak a tracking domain behind some DNS trickery, bypassing browser based ad-blockers. It takes only a few minutes to buy a new domain and setup a CNAME alias to achieve this masking technique so it is very easy.

A CNAME is a domain that points to another domain, an alias. You can think of it as a permanent redirect but executed at the DNS level. Many tools rely on CNAMEs to serve content and I'm going to pick Netlify as an example here. Our blog is hosted on Netlify. Each deployed website is assigned a unique subdomain in the form of unique-subdomain.netlify.com. In our case it is festive-nobel-876c06.netlify.com and you can try it in your browser to see it works.

If you want to use your own domain (of course you are) for this address (blog.dnsadblock.com) you need to point it to festive-nobel-876c06.netlify.com using a CNAME.

Presuming that festive-nobel-876c06.netlify.com is serving some tracking scripts and it is being blocked by ad blocking extensions I can simply alias a new domain to it and import the script using it:

<script src="https://blog.dnsadblock.com/itrackyou.js"></script>

Since festive-nobel-876c06.netlify.com appears only after the request was allowed (when the DNS is being resolved) it will pass without issues:

$: dig blog.dnsadblock.com

;; ANSWER SECTION:
blog.dnsadblock.com.    103 IN  CNAME   festive-nobel-876c06.netlify.com.
festive-nobel-876c06.netlify.com. 20 IN A   157.230.120.63

So how can we combat these techniques? Are ad-blockers dead? Not really. I know they are trying hard to kill or limit ad-blockers but they are still effective. The solution is to combine multiple tools. Our ad blocking DNS servers are monitoring and testing rules against CNAME aliases as well so this technique won't fly.

If you are curious to see just how much tracking takes place on a regular machine have a look at this screenshot. This is my computer and I'm using dnsadblock only on it. This screenshot only reflects my activity and you can also see periods of inactivity when I'm testing other DNS servers so the numbers could be higher.

Deploy a blazing-fast, feature-rich and free to use website with a blog in under 10 minutes

Romeo Mihalcea — Thu, 03 Jan 2019 02:39:10 +0000

2018 was a great year for me as a developer. I managed to put together an open-source project (still under heavy development) that was sitting on the back of my mind for many years.

I don't know about you but, as a programmer that is comfortable with both the backend and frontend, I'm always testing new ideas, apps and websites. Doing so for years and years I noticed a repetitive task that was getting quite annoying. Each of my projects required a presentation website with a blog where I get to talk about it in more detail.

That means at least one web server with a database attached. It's not hard but takes a lot of time that I would rather spend on something else instead so I stopped and brainstormed my next project that would end this repetitive cycle of costly deployments.

Every good house starts with a strong foundation

My framework of choice was Gatsby. It had most of the things that I would consider to be required:

it has to compile to static files
easy to deploy to a CDN such as Netlify
image optimization in place
vibrant community
hackable because I like to get my hands dirty
extensible via plugins
uses GraphQl to fetch data

    query($slug: String, $tags: [String], $categories: [String]) {
        post: markdownRemark(fields: { slug: { eq: $slug } }) {
            ...postFragment
        }
    }

The result had to be something oriented towards programmers. I hate wysiwyg editors with a passion because there are many constraints and the output never seems to be predictable. I wanted something where I put the power of the framework at reach for both the developer and content editor.

Developers and Publishers express without barriers

Slowly but surely Qards took shape. My goal was to give more power to the writer by using, what I like to call, "smart cards". The content editor should be able to create interactive presentations using widgets that respond to events, to dates, to browser types, regions or any other external factors that can be made available to a frontend engineer. Some of those widgets include:

automatically generated toc (table of contents) (developed)
charts (planned)
accordions (developed)
images (developed)
galleries (developed)
video embeds (developed)
audio playlist (developed)
code blocks (developed)
callouts (developed)
countdowns (developed)
grid lists (planned)
references to other posts (developed)
etc

One other must-have for such a platform was the ability to add custom widgets via an internal plugin system (still under development/planned). The developer creates directives and data requirements which are interpreted by the admin interface (Netlify CMS) where the content publisher is able to create those experiences. That's right, let's navigate from simple posts to "experiences" for our visitors. We're all affected by bounce rates that connect directly with dull interfaces.

Let's get the word out

One month later into the project I had a clear path and an idea that was no longer just a blurry shape. I like to test such things before an official launch by putting it out there on ProductHunt and other similar platforms.

Qards was quickly picked-up and got to 2nd place for that day which was not bad at all for something which was not even in an alpha stage.

The feedback was more than helpful and my mailing list reached 2,000+ in one night so it was a productive experience for me. That's everything I needed to validate my project. I was going to use it anyway but I wasn't sure if I could make something for the general public out of it.

More than just a blog

I may be advertising a blog but Qards is more than that. Being powered by Gatsby, it can be your next big project...with a blog. You simply get the added benefit of not having to worry about content any more.

In summary

In summary I would like to recap everything that Qards is and does so here's a list of all the parts that make this project work:

powered by Gatsby and Netlify CMS, comes with all benefits
free to use and free to deploy to Netlify or other CNDs (free SSL as well)
rich, interactive widgets to keep your readers engaged
more power to the content editors (think of it like Bootstrap for publishers)
compiles to static files
offline support
pluggable
extensible
hackable
free to use and develop with 0 restrictions
- code/content sits on Github or Gitlab
- static files are served by any CDN you can think of
open source
tested (work in progress)
developer oriented
developed in Typescript
blazing fast
appealing default design
themable
deployable and ready to publish in under 10 minutes
markdown content
progressive loading, image optimization and lazy loading of content
un-hackable, always on production deployments
awesome performance index

If I managed to spark your interest please have a look at Some of the supported cards to get a feel of what this project can do for you.

Also, it's still an early phase so AMA and feel free to suggest new things.