Why I Had to Build This: The Dangerous Reader Problem
Some people are dangerous when working with technology. Not because they're malicious, but because they refuse to accept their own limitations. Even with crystal-clear instructions, they'll:
- Copy-paste code without understanding it
- Skip crucial steps
- Ignore warnings and prerequisites
- Then blame the blog when things go wrong
My blog has advocated countless times: understand what you're doing, don't just blindly follow instructions hoping for magical fixes. I've written variations of:
⚠️ Before implementing this solution, ensure you understand:
- What the problem actually is
- Why this solution addresses it
- What each line of code does
- The potential consequences
Unfortunately, in many organizations, these words of logic get completely lost in translation. Instead of admitting "I didn't understand the prerequisites" or "I skipped the part about configuration," it's easier to:
- Blame the blog post
- Claim the instructions were wrong
- Leave angry comments - which is why comments on disabled on this blog!
- Never acknowledge their own technical shortcomings
This creates a dangerous situation where people with insufficient technical knowledge attempt complex implementations, fail, then spread misinformation about the "broken" solution. Hence, the need for protection.
🚩 Red flag symptoms involve people or teams continually asking for documentation, knowledge transfer, training - The reality of being technical is learning from your failures not repeating past failures, if you don’t make any failures or think you don’t make any failures, you simply cannot improve.
Developer Tools Problem
I started with a simple full-screen password overlay for my blog. Here's what most developers do:
// Basic overlay - easily defeated
const overlay = document.createElement('div');
overlay.className = 'fullscreen-overlay';
overlay.innerHTML = `
<div class="password-form">
<input type="password" id="pwd" placeholder="Enter password">
<button onclick="checkPassword()">Submit</button>
</div>
`;
document.body.appendChild(overlay);
// Disable F12 and right-click
document.addEventListener('keydown', function(e) {
if (e.key === 'F12') e.preventDefault();
});
The Fatal Flaw: Users can still access Developer Tools through the browser menu (☰ → More Tools → Developer Tools). Once there, they simply:
1. Find: <div class="fullscreen-overlay">
2. Right-click → Delete element
3. Content exposed!
Evolution Stage 1: The Countdown Timer
My first innovation was adding a self-destruct timer:
function showPasswordPrompt() {
// Create overlay with countdown
overlay.innerHTML = `
<div class="fullscreen-content">
<h1>Enter Password</h1>
<input type="password" id="pwd">
<button onclick="checkPassword()">Submit</button>
<div id="countdown-timer">
Redirecting in <span id="countdown-seconds">6</span> seconds...
</div>
</div>
`;
// Auto-redirect after 6 seconds
let secondsLeft = 6;
const countdownInterval = setInterval(() => {
secondsLeft--;
document.getElementById('countdown-seconds').textContent = secondsLeft;
if (secondsLeft <= 0) {
window.location.href = 'https://www.google.com';
}
}, 1000);
}
Problem discovered: The countdown broke when users hit the back button:
// Had to add navigation event handlers
window.addEventListener('pageshow', function(event) {
if (event.persisted || performance.navigation.type === 2) {
// User came back - restart the countdown
showPasswordPrompt();
}
});
Evolution Stage 2: The Attack Window Problem
Six seconds seemed short, but it's actually plenty of time to:
- Press F12 (or use menu)
- Click Elements tab
- Find and delete overlay
- All before redirect
I needed something more custom and harder to bypass.
Evolution Stage 3: The Secret Hot Key
This was my breakthrough - require a secret key held during page load:
let secretKeyPressed = false;
// Capture key state immediately
document.addEventListener('keydown', function(e) {
if (e.key === 'SECRET_KEY') { // Could be any key
secretKeyPressed = true;
}
}, true);
async function initializeProtection() {
const isBlocked = await checkIfBlockedIP();
if (!isBlocked) return;
// No secret key = instant redirect
if (!secretKeyPressed) {
window.location.href = 'https://www.google.com';
return;
}
// Secret key held = show password prompt with countdown
showPasswordPrompt();
}
`
The IP/ASN Targeting System
This only affects specific visitors:
async function checkIfBlockedIP() {
const response = await fetch('https://ipapi.co/json/');
const data = await response.json();
const blockedIPs = ['1.2.3.4', '5.6.7.8']; // Example IPs
const blockedASNs = ['12345', '67890']; // Example ASNs
const visitorASN = data.asn.replace('AS', '');
return blockedIPs.includes(data.ip) ||
blockedASNs.includes(visitorASN);
}Why This Works
The genius is in the combination:
- Instant redirect (no time to open dev tools)
- Secret key requirement (unknown to attackers)
- 101 possible keys (impractical to brute force)
- No visual indication (they don't even see a password prompt)
- Targeted blocking (only affects problem IPs/ASNs)
The Code Psychology
Most security is about making things hard. This makes things invisible:
// Traditional: "Here's a wall, try to climb it"
if (needsPassword) {
showBigPasswordWall(); // Challenge accepted!
}
// My approach: "What wall?"
if (needsPassword && !secretKey) {
window.location = 'google.com'; // Wall? What wall?
}
Conclusion
By combining countdown timers with hot key activation, I transformed a tricky overlay into an invisible barrier. The evolution from "hard to break" to "impossible to find" shows that sometimes the best security isn't a stronger lock—it's hiding the door entirely.
The blocked visitors don't get a puzzle to solve unless the visitor knows what to look for.
This system protects not just my content, but also those dangerous readers from themselves. They can't misuse what they can't access. They can't blame instructions they never see. And most importantly, they can't implement solutions they don't understand and then point fingers when their lack of comprehension leads to failure.